If you still rely on big-bang deployments or are ever afraid to break your production environment when you push changes, then it is seriously time to invest in building a strong CI/CD pipeline.
Pushing changes quickly and often is critical:
The best way to mitigate the risks of new releases is to have a strong deployment strategy in place. Continuous deployment automates the deployment process, which lets you deliver new features and improvements to your applications faster than before.
In this blog post, we look at continuous deployment and the main implementation models you need to know: blue-green, rolling, and canary. We also explore how your application can benefit from a native CD pipeline when you deploy on a serverless platform like Koyeb.
Table of contents
When discussing CD, it's important to clarify if you are talking about continuous delivery or continuous deployment. The key difference between the two is how tested code is pushed into production.
There are a few key components required to build a continuous deployment pipeline:
With a continuous deployment pipeline in place, you will be able to iteratively develop your application and share new releases with your users to improve their experience and add functionalities to your application faster than before.
The benefits of continuous deployment are numerous.
Now that we have discussed what is continuous deployment, its components, and benefits, let's discuss the different release models you could implement to achieve continuous deployment as well as their relative advantages and trade-offs.
Once you identify a deployment strategy you want to use for your application, then you can decide how you will implement your CD pipeline. You could choose to build your own CD pipeline with the popular open source technology Spinnaker or you could opt to use the built-in CD pipeline on a cloud service provider like Koyeb.
A blue-green deployment strategy requires two identical production environments: one is known as the blue environment and the other one is the green environment.
The green environment is the live production environment, running the current version of the service while the blue environment is running a replica of the green environment with the new version of the service.
In a blue-green deployment, tests are performed on the blue environment to ensure it is ready to handle production traffic. Once the tests passed successfully, you can promote the new version in production by reconfiguring your load balancers or proxy servers to switch the incoming traffic from the green environment to the blue environment, running the latest version of your application.
After traffic is routed to the blue environment, the green environment stops receiving new requests, but still returns responses for the in-flight requests and requests it already received. The blue environment begins processing the new requests while the health status of this environment is monitored.
If the blue environment becomes unhealthy or fails for whatever reason, then you roll back to the green environment to minimize downtime. On the other hand, if the blue environment remains healthy and available, then the new release is successfully promoted and the old green environment can be destroyed.
Blue-green deployment is the continuous deployment strategy we provide by default on Koyeb. All applications natively benefit from zero-downtime deployments.
The advantages of blue-green deployment include:
The drawbacks of blue-green deployment are:
In a rolling deployment, infrastructure instances of the previous version are slowly replaced with nodes running the new version iteratively, or in other words, in a rolling manner - hence the name. This approach is less drastic than a blue-green deployment because the new version is eased into production.
In a rolling deployment, you will have old and new versions live at the same time until the new version completely replaces the old version. To implement a rolling deployment, you will need to run at least N + 1 instances of your application. The additional node is used to run the new version of your application.
Once the instance of the new version is released, its performance and its error rate are monitored. If the new version passes necessary health checks, then another instance is pushed into production and monitored. This process repeats iteratively until the new version is the only version up and running.
The benefits of a rolling deployment include:
The major drawback of rolling deployments:
A canary deployment is an excellent deployment strategy for testing performance or technology issues. In a canary deployment, the new version is released to a small number of users by deploying the changes to a subset of servers.
Canary deployments should not be confused with A/B testing, which is for testing user experience and engagement across potential new versions.
Not so fun fact, the term refers to the history of coal miners releasing a canary into a new mine to detect odorless toxic gas before entering the mine to work.
To implement a canary deployment, you will first need to determine the following:
Once your canary deployment is released, you will then monitor the test audience's user experiences. Typical metrics people study during a canary release are latency issues, internal error counts, and excessive memory or CPU use.
If these performance metrics are satisfactory, the new version continues to roll out gradually and be monitored until the release is complete, like in a rolling deployment. However, in the case of an issue, you can roll back to the previous and healthy version of your application.
The benefits of canary deployments:
The drawbacks of canary deployments include:
While not a deployment strategy, A/B testing resembles canary deployments except that it tests new versions along criteria for user experience rather than infrastructure performance.
With A/B testing, different versions of the same service run in production to identify the best version along user experience and engagement criteria.
Like canary deployments, A/B deployments can be achieved with the use of a feature flag or by reconfiguring the load-balancer to route a select number of traffic to a production environment running the new version.
Strong observability capabilities are needed to collect and analyze data in order to determine if the new release can be entirely rolled out to production. In case of failure, you can return traffic to the previous version of the application.
The advantages to A/B testing deployments:
There are a few drawbacks to A/B deployments:
There are a number of strategies you can use to continuously deploy your applications. Your uptime requirements, resource capacity, and deployment goals will determine which method is best for your use case.
In any case, building a continuous deployment pipeline requires a significant time and resource investment, and so does performing its on-going maintenance.
The great news is that this infrastructure is included out-of-the-box and from the get-go with the Koyeb Serverless Platform! This means you get all of the benefits of a CD pipeline without any of the headaches.
Each time you perform a git push to your repository, you trigger a new build and deployment for your application on Koyeb. Your changes then go live as soon as the automatic deployment passes all of Koyeb's necessary health checks. In case of deployment failure, Koyeb keeps your latest working deployment active so your application is always up and running.
Your deployment strategy influences your time-to-market. Create and share value with your users faster by opting for a continuous deployment on Koyeb. Try it for free today and make sure to join us on our community platform to stay up-to-date with our latest news.
Koyeb is a developer-friendly serverless platform to deploy any apps globally.Start for free
Deploy 2 services for free and enjoy our predictable pricing as you grow
Get up and running in 5 minutes