Now that we have the ability to configure maintenance window settings in the production environments, what would we use it for?
The wording there is quite interesting – if there is no downtime or service degradation, why would we care?
Well, the answer seem to be two-fold.
On the one hand, from the operations perspective, there should be no service degradation. As in, your users are supposed to be able to keep working in the environment without being impacted by whatever maintenance activities that might be happening in the background.
On the other hand, from the development and deployment perspective, have you ever tried publishing multiple solutions at the same time in the same environment? You might have seen the error below, then:
So, in theory, by having that maintenance window configured, you can, at least, guarantee that your own deployments won’t be happening at the same time when Microsoft might be doing theirs, and, in that sense, your deployments won’t be interrupted because of Microsoft first-party solutions being deployed at the same time.
You could, also, ensure that your business users don’t run into changes in the middle of the day if your organization operates in different time zones. In that case you could configure every production environment for its own maintenance window (can’t do it for sandboxes). Although, it’s not likely that you’d be doing automated testing at the end of the maintenance window, yet the users would still run into those changes the following morning. Does it matter if that happens in the morning or during the day? Maybe.
Not sure what other use cases would be available right away, but, I guess, more are coming in the future.
You can read more on this new setting in the docs: