Updating applications, introducing new functionality and re rolling previous versions of applications are integral to any company. In order to plan for all of this, you need to develop your own deployment type that suits your organization, or use the patterns of those already in place. In this article, we will look at three of the most well-known types of deployments we may come across when working in IT companies.
Rolling deployment
The first of the deployment types discussed is rolling deployment. It involves the existence of a production environment for a distributed application. It is hosted on multiple servers or instances in the cloud. When a new version of the application is deployed, it is updated on one or more servers. In this way, we do not impact all users and are able to check that everything works properly after the change. If no defects are detected, the new version is uploaded to more servers. In case of errors, network traffic to the server with the new version is shut down.
Rolling deployment works well in organizations where the functionalities being introduced will not be significantly different from those already in place, and in companies with hosting infrastructures large enough that parts of them can be taken offline at any time without affecting performance. Other examples of the use of such deployment in applications are those that are fully only maintained (without adding functionality) and those where the user interface is being updated.
Canary deployment
Canary deployment is something very similar to rolling deployment. It relies on there being at least two environments (two in the example), where one is the environment with the new version and the other with the old one.
Instead of (as in the case of rolling deployment) making servers with newer versions of the application available to users, it is the newer version that is made available to some users. Such a process is called differently depending on the organization (for example, Family & Friends deployment).
Canary deployment itself is useful in case our target group is more tolerant of error cases. Such users could be, for example, company employees. Canary deployment also works well for startups and companies with limited budgets, as deployment does not require any backup hosting infrastructure.
Blue / Green deployment
The third type of deployment we will discuss is Blue / Green deployment. It relies on the fact that there are two insfrastructures. One is called green and the other is called blue. The green structure refers to a production environment that is running and open to traffic from customers. The other is an environment that hosts a new version of an application that is not yet available to the world. This environment is also called a backup or stage environment.
Once the new version (on the blue environment) and the deployment are properly tested, network traffic is redirected to the backup (blue) environment by administrators. At this point, green deployment becomes blue deployment, and blue deployment becomes green deployment.
The negative effect of this approach is that both environments must be identical in terms of resources, which generates additional costs. If the environments were not identical, it is very likely that the performance and unavailability of the application would be affected.
Top comments (0)