This is part of the Patterns of Enterprise Deployment series.
You have several interdependent applications. They are typically client-server. You shut down all of the services and make them unavailable then deploy all the updates in the MaintenanceWindow. When the applications are able to run again, all the versions of applications are updated. For instance, in a 2-tier client-server application, you need to make the changes to the database schema and the application at the same time. In order to prevent users entering bad data yuo take the database server offline and perform the schema changes. Then ensure that all clients are updated before you re-enable the database.
This kind of change is high-risk; you should ensure that you CommunicateChanges and ensure that you have a RollbackPlan.
Medium; this is very simple, but the risk can make it harder than it looks.
- simple to understand.
- few, if any, changes are required to the application to make it more deployable
- downtime is essential, and may be quite long if the deployment doesn’t go to plan
- if there are instance of the one of the application that are missed then there may be trouble; if you have used a VersionedContract or a BackwardsCompatibleContract then things may be OK. Worst case is that the contract is compatible from technical point of view but the meaning of the fields in the contract has drifted.
- The users are tolerant of downtime
- you don’t have time or inclination to implement a graceful deployment strategy
- there are only a few applications to update
- the deployment process is repeatable; preferably an AutomatedDeployment or a DeployFromSourceControl
- if changes are very rare; for instance a new office requires a server move or a major piece of middleware is being upgraded. For instance, a change of SQL server version.
- If the opposite is true! high-availability, poorly controlled deployments with many interlocking applications will be too much work to do this more than once!
- there is more than one change happening; for instance, a new office and a new version of SQL server.
Working in a small company where users are always clamoring for features and are sophisticated enough to survive bugs, you see this a lot! If the pressure is on to deploy then you simply take the server out and the users have to accept the downtime. The problems come if there are several teams working on different parts of the application stack. Then every team deploys and – as far as the user is concerned – takes out ‘the system’ in entireity. You can’t do this too often and expect people to be tolerant for long. If this is the case, the you need a WeeklyMaintenanceWindow.