What is Deployment in simple words?
Deployment is a process that enables you to retrieve you to enable codes from version control so that they can be made readily available to the public and they can use the application in ready to use in an automated fashion.
Deployment is the mechanism through which applications, modules, updates, and patches are delivered from developers to users. The methods used by developers to build, test, and deploy new code will impact how fast a product can respond to changes in customer preferences or requirements and the quality of each shift.
What is the use of Deployment?
Deployment automation enables you to deploy your software to the testing and production environment with the push of a button. Automation is essential to reduce the risk of the production environment.
There are six types of deployment.
- In-Place Deployment.
- Blue/Green Deployments.
- Canary Deployments.
- Ramped Deployments.
- Shadow Deployments.
- A/B Testing Deployment.
What is Deployment Strategy in Application Deployment?
A deployment strategy is any technique employed by DevOps teams to successfully launch a new version of the software solution they provide. These techniques cover how network traffic in a production environment is transitioned from the old version to the new version. Based on the firm’s specialty, a deployment strategy can influence downtime and the company’s operational cost.
When it comes to deploying new resources and code versions into your production environment, automation with minimal service interruption is ideal. A deployment strategy is important because it reduces manual configuration and tremendously improves serviceability, as well as reducing the amount of downtime during a deployment.
-
In-Place Deployments:
An in-place deployment is a deployment strategy that updates the application version without replacing any infrastructure components. In an in-place deployment, the previous version of the application on each compute resource is stopped, the latest application is installed, and the new version of the application is started and validated. This allows application deployments to proceed with minimal disturbance to the underlying infrastructure.
You can deploy your application without creating new infrastructure, however, the availability of your application can be affected during this deployment. This approach also minimizes infrastructure costs and management overhead associated with creating new resources. You can use a load balancer so that each instance is deregistered during its deployment and then restored to service after the deployment is complete. In-place deployments can be done all at once, assuming a service outage, or done as a rolling update.
As stated before, in-place deployment does not spin up a new infrastructure resource. It takes the current infrastructure and shuts down the application running on it before installing new code.
The next step of the process deploys new code onto the infrastructure and then starts the application again.
The deployment then repeats the process in Step 1 but on the next resource running Version 1 of the application.
Finally, once the new version of the application has been deployed onto every infrastructure resource, the deployment is complete.
This deployment strategy is cheaper because no new infrastructure is provisioned; however, there is a disadvantage to implementing this strategy. The con is that it will stop the application from running on your infrastructure while deploying your newest code. If there are insufficient resources to handle the downtime, you could see a minor outage in your application.
There are ways to mitigate downtime. One example is by staggering the deployment so that there are enough infrastructure resources to handle demand.
The second disadvantage to using the in-place deployment strategy is that it is slower to roll back because it changes if a failure arises. This is because the infrastructure has to be reverted, unlike redirecting traffic to the previous version’s load balancer in blue/green.
2. Blue/Green Deployment:
The blue/green deployment strategy creates two independent infrastructure environments. The blue environment contains the previous code or configuration, while the green environment contains the newest code or configuration. Traffic is then shifted to the newest environment (green) and diverted away from the previous environment (blue) by redirecting the DNS record to Green’s load balancer using Route 53.
Since both environments have their own networks, the blue/green strategy has the benefit of being able to quickly and seamlessly roll back a deployment if failure is encountered. A downside of implementing blue/green is the uptick in cost due to running two infrastructure environments simultaneously.
In the first stage, traffic is directed towards the blue environment.
Then, after making a change in DNS, traffic is redirected to the green environment’s load balancer, which will serve the newest version of the application.
The major advantage of this strategy is that it allows a quick update or rollout of a new application version. However, its main disadvantage is that it is costly because you must run both the new and old versions concurrently. Engineers mostly use this method in mobile app development and deployment.
3. Canary Deployment:
In canary deployment, the deployment team sets up the new version and then gradually shifts the production traffic from the older version to the newer version. For example, at a point in time during the deployment process, the older version might retain 90% of all traffic for the software while the newer version hosts 10% of the traffic. This deployment technique helps the DevOps engineers test the stability of the new version. It uses live traffic from a subset of the end-users at different levels that vary as production occurs.
Canary deployment enables better performance monitoring. It also aids in a faster and better rollback of the software if the new version fails. However, it has a slow nature and a more time-consuming deployment cycle.
4. Ramped Deployment:
The ramped deployment strategy gradually changes the older version to the new version. Unlike canary deployment, the ramped deployment strategy makes its switch by replacing instances of the old application version with the instances from the new application version one instance at a time. You can also call this method the rolling upgrade deployment strategy.
When developers replace all instances of the older version, they shut down the older version. The new version then controls the whole production traffic.
This strategy gives zero downtime and also enables performance monitoring. Nevertheless, the rollback duration is long in case there is an unexpected event. This is because the downgrading process to the initial version follows the same cycle, one instance at a time.
5. Shadow Deployment:
In this deployment strategy, developers deploy the new version alongside the old version. However, users can’t access the new version immediately. Just as the name suggests, the latest version hides in the shadows. Developers send a fork or copy of the requests the old version receives to the shadow version to test how the new version will handle the requests when live.
This technique is very complex, and as such, the DevOps engineer should be careful so that the forked traffic does not create a duplicate live request since two versions of the same system are running. Shadow deployment lets engineers monitor system performance and conduct stability tests. But it’s expensive and complex to set up and can create serious issues.
6. A/B Testing Deployment:
In A/B testing deployment, developers deploy the new version alongside the older version. However, the new version is only available to a subset of users. These users are selected based on specific conditions and parameters the engineers choose. These parameters can be the user’s location, type of device, UI language, and operating system.
This method measures the effectiveness of the application’s new functionality. After gathering statistics from performance monitoring, developers roll out the version that yielded the best results to all users. Real-time statistical data can help developers make important and favored decisions about their software. However, A/B testing is very complex to set up. It also requires a highly intelligent (and pricey) load balancer.
