- Problem:Traditionally, we deploy a new release by replacing the current one. The old release is stopped, and the new one is brought up in its place.
- The problem with this approach is the downtime occurring from the moment the old release is stopped until the new one is fully operational
- Having monolithic applications introduces additional problems like, for example, the need to wait a considerable amount of time until the application is initialized.
- Solution: variation of the blue-green deployment process. At any time, one of the releases should be running meaning that, during the deployment process, we must deploy a new release in parallel with the old one. The new and the old releases are called blue and green.
- With the blue-green process, not only that we are removing the deployment downtime, but we are also reducing the risk the deployment might introduce.
- If we combine the blue-green process with immutable deployments (through VMs in the past and though Docker containers today), the result is a very powerful, secure and reliable deployment procedure that can be performed much more often.
- If architecture is based on microservices in conjunction with Docker containers, we don’t need two nodes to perform the procedure and can run both releases side by side.
- a canary release is that it's a partial release to a subset of production nodes with sticky sessions turned on.
- Similar to a BlueGreenDeployment, you start by deploying the new version of your software to a subset of your infrastructure, to which no users are routed.