Executing Deployment and Release Strategies

Software application development is an arduous process involving a lot of forward and backward movements. When a website is built from scratch or is revamped after a long time, a process of strategies is put into play. From the new additions to the changes that are implemented on the website, the most crucial part is the deployment and release of those changes. 

There are important decisions that can weigh down a pivotal impact on the end-user of the application. Given the importance, in this post, we are going to talk about deployment and release strategies.

Meaning and Difference

Deploy 

The process of getting software applications run smoothly in a given environment is termed as the act of deployment. Without involving the release, deployment includes installation, configuration, testing, and making necessary changes of features in a specified environment. 

Release 

When the software is ready to be pushed to production it is called release. The process entails making the software open to the users or a subset of users, like only 5% of the user base.

Advantages of Deploy and Release Separation

With the minimal differences in the approach, it might sound difficult to separate the two. But the ideal scenario is to keep them isolated for minimizing the technical risk of changes in code. It also allows for faster feedback from the user pool. 

There are many release strategies that aid the separation of deploys and releases that help development teams to release more frequently. We will be discussing them later in the article. 

Let’s start with Deployment...

Common Deployment strategies

Before you get your hands dirty in the deployment business, consider the pre-deployment factors like the infrastructure, test environments and the nitty gritties of downtime involved.

When the software needs to change or be upgraded, the development teams aim to achieve those changes without downtime. In order to achieve that, deployment strategies are put into place like:  

No Deployment Strategy

A cheap but dangerous method, the No deployment strategy is simply nothing but skipping a few steps. If your site is getting traffic then live site production changes might hamper your traffic. On the other hand, the process of coding involves a lot of to and fro of breaking and fixing the site. If you aren’t responsible and proficient enough with the backups, the No Deployment Strategy can backfire.  

Copy the New Site into Production

When we switched from Drupal 7 to Drupal 8, the strategy to copy the entire new site to the production server was an apt one. However, as a common strategy among many, the process of copying the site to production is a risky one. If you are making minor changes like theme refreshes or daily maintenance, there are chances that you might lose your data and leads.

Compile First, Deploy Later

There are various third-party vendors who offer static site generators for a simplified process of building an offline site securely. This strategy helps your site from being attacked by the internet due to the bugs. Once the static site is compiled properly you can copy the resulting code to the web host for live production. 

Dev/Stage/Production pipeline

As a standard process of deployment, this strategy involves three copies of the site:

• Dev Copy- where the development work takes place
• Stage/Test Copy- To test the deployment process before rolling out to production
• Live Copy: The production to live for the public

This pipeline is often adopted by e-commerce businesses for the ease and management of collected data like forms, comments, reviews, and other related details.  

Blue/Green Deployment

The most essential strategy that minimizes the maintenance gap and provides a solid roll-back for the changes is, Blue/Green. This deployment strategy helps in cutting the costs of downtime. 

As the name suggests, it creates two different production environments marked as ‘Blue’ which is in standby and ‘Green’ which is Live. 

All the changes are deployed to the offline environment and are promoted to the live one. This gives you the advantage to switch between the two as per the requirements and the maintenance cycle of the site. 

Deployment Best Practices

A modern approach to deployment can be undertaken with these best practices in review: 

• Make a checklist/pipeline of things to do before and after deployment to ensure the safety of data 
• The process of continuous integration can be adopted to ensure that every change is tested before its sent for deployment and there are no errors along the path. 
• Similarly, adopt Continuous Delivery (CD).
• You can invest in standard operating environments (SOEs) that help ensure the consistency in the environment 
• Automate the build with tools that can simplify the process of tearing down an entire infrastructure stack and rebuild it from scratch.
• Have a systematic process for creating alerts that can warn teams about the changes or notify about the issues in real-time.

Support Strategies

Rolling Strategy

In the process of rolling deployment, the instances of the previous version of an application are slowly replaced with the new version. The rolling deployment typically waits for new pods to become ready before the old components can scale down. This strategy can be put to action when: 

• You want to have no downtime for the update
• Your application has old and new code running at the same time 

Canary Deployments

The basic concept of canary deployments is to release the changes to only a subset of users and test them. This gives a fair idea of how the changes will perform and can be rolled back if the tests fail.  

Recreate

This strategy can be utilized when you do not want to run new and old versions of your application code simultaneously. It can also be executed while the RWO volume is not supported in sharing multiple replicas. 

The most common usage of the Recreate strategy is when running migrations or data transformations becomes necessary before the new code starts. 

Being a dummy deployment, the technique consists of closing down version X then deploying version Y only after version X is turned off.

Ramped

The ramping of changes one after another as a slow process of deployment is called the ramped strategy. The instances are replaced in the application one after the other in a flowing process. Only when the service is ready to accept the live traffic, the instances are added while removing the other from the pool.  

A/B testing

This technique is developed on the basis of statistics and consists of rolling out new functionality to a subset of users under specific conditions. It is implemented for test conversions of certain features where the full control over the traffic distribution is maintained and several versions run in parallel.

Shadow

This is a complex strategy involving forking version A and sending the requests to version B while version B is releasing alongside version A. 

It requires a special setup and requirements and recommended for the rollout of new features that are triggered when stability and performance meet the said requirements. 

Which deployment strategy is best?

No one strategy can be termed as best for all the outlines that can occur in the deployment cycles. A strategy is best when it fits the best in that given situation and works out well for the production server. 

A site can be deployment and released using various approaches from taking the entire site together or breaking it into pieces. It is totally on you which one feels more comfortable and simplifies your tasks. 

Types of Release Methods

Release methods are comparatively straightforward and sorted. They can be classified into two categories: 

Environment Based Releases

It is the Canary release that involves releasing the new code to a limited section of users and only later releasing it to the rest of the user base. This way, it empowers you with the ability to test software change with real users and gives valuable stats in terms of inputs for the complete release of those changes. The automation rollback is an added advantage of the Canary releases when the changes fail to meet the technical or user metrics. As each change is monitored, the performance is measured using metrics pertaining to the response of the users. These results are further utilized by the dev team.  

Application Based Releases

Application-based releases use feature toggles as a popular way of implementation. It controls the application code to allow progressive exposure of new features to users. It enables features for certain users and development teams to deploy them to production without actually releasing any changes. Feature toggles aid continuous deployment and is used to disable non-essential features during times of high load, or while a feature is failing.

Over to you 

Every version of change and new features are different. They require a unique system to handle and execute in the process of software application development. While the recreate strategy might be best for one, the canary deployment can be a good choice for another. Therefore, it is wise to weigh the situation of your application and then take a decision. 

Connect with us on our social media channels: Facebook, LinkedIn, and Twitter.