This blog post is about timing considerations for the deployment of Changes into the IT infrastructure, specifically the batching together of Releases into a 'Release Window' (defined below) on the one hand, and the continuous deployment of Releases into the IT infrastructure on the other.
Deployment during a Release Window
A Release Window is an agreed time frame for deploying Releases into an IT environment (for example, each Thursday, or once every two weeks). Depending on the business demands of each company, Release Windows may be scheduled weekly, fortnightly, monthly, etc.
Typically, when Releases are scheduled, they are batched together and deployed simultaneously. This batching of Releases offers the opportunity to reduce downtime (for maintenance) to critical IT systems and is one of the principal benefits of this approach.
This comes at the expense of the time taken to deploy a particular Change, as you await the arrival of the next Release Window. Of course, Emergency Releases are not typically subject to a Release Window approach, but are instead deployed expediently.
Another advantage, it can be argued, is that it limits change into the IT infrastructure to specific times and therefore promotes stability.
In a Continuous Release environment each Release is deployed when it is ready to be deployed, and a suitable Release time/date is agreed.
Continuous Release allows for quicker deployment into the business environment since there is typically less wait time between a Release being ready for deployment and the actual deployment into the IT infrastructure. It could be argued it takes slightly less planning and management on the IT side.
However, there is potential for greater instability of the IT infrastructure, as well as more strain on gathering all resources necessary for each Release, due to more frequent deployment activities. Ultimately, Continuous Release may act as a trigger for greater unforeseen disruptions to the IT infrastructure and the business activities as a whole.