Automated Deployment Of CI/CD

DevOps Services QA

October 27, 2020

Introduction

Automated Deployment enables an organization to deploy software releases with a single command or simply by clicking on a control panel. Automation is essential to streamline the deployments in the production environment and reduce the associated risks. Web application deployment needs some well-defined steps to be followed so that the software changes are shipped from the development environment to the staging/ production environment. It is done so that the updated software (which includes new features and corrections) is available for the end-users.

Automated deployment reduces the human effort and avoids any manual intervention required to deploy code to the various environments like DEV(Development), QA (Quality Assurance), UAT(User Acceptance Testing), and PROD(Production). Automated deployment is closely linked to CI/CD (Continuous Integration & Continuous Delivery). CI/CD is one of the current industry best practices to deliver applications to customers more frequently and reliably by introducing automation into the stages of application development.

Automated Deployment Characteristics

Some of the salient features of automated deployment are:

Deployment can be triggered by clicking on a button or running a single command from CLI
There is little or no human intervention from the start to the end
Better visibility, i.e. it shows the deployment progress as it happens
It should be atomic, which means either all the steps are completed, or nothing happens
Uninstallation of previous release or rollback of failed deployment should be easy and quick
Smoke testing should be done after automated deployment to ensure nothing is broken
It consists of pre-defined steps and a series of workflows. The next step should not be initiated until the previous steps successful
It should be transparent with clear indications/notifications to the team about the success or failure of each step

The Problem We Intend To Solve

As part of the deployment of a new software release, the following tasks are routinely followed:

Manually download software build from the build server to the target platform.
Manually deploy the build in the appropriate location/ container (on staging or production server).
Manual smoke testing to verify the key functionalities are working fine.

After providing so much manual effort if smoke testing fails then a new build is required and the complete cycle is repeated. This requires a lot of manual effort again, which can be avoided.

The key shortcomings of the current process are the lack of the following:

Automation deployment
Automation sanity testing
Automation smoke testing

Software development teams should not worry about how code is going into production. They should only focus on the business requirements, design, implementation, unit tests, integration tests, and regression tests. So, by excluding manual tasks and including automated tasks we can reduce a lot of additional efforts.

Automated Deployment as a Solution

To achieve automated deployment, we have used Ansible which is an automation configuration tool. We keep Ansible as a controller entity that is used to interact with the required servers and executes the required shell script on managed nodes to achieve the desired result.

The framework which helps in executing the workflow is as shown below:

automated-deployment-flow-diagram

We have written plays so that Ansible can support N>0 servers at any tier.

Ansible verifies the reachability and memory usage of each server before continuing with deployment.
Ansible integration with collaboration tools helps to notify the team about continuous progress.
For each environment inventory files are there i.e. DEV, QA, UAT, and PROD.
In automation deployment, Ansible uses to run smoke testing before deployment of the build.
Ansible uses FTP so that release can be downloaded and deployed to DEV and QA env.
Ansible interacts with Artifactory to download/ deploy release on UAT and PROD env.
To ensure the integrity of the build, Ansible uses to evaluate some of the builds.
Ansible interacts with a load balancer to stop traffic.
Ansible interacts with the database server via the application server to upgrade the database.
Ansible interacts with the application server to download and deploy build.
Ansible does a predefined number of retries and waits for services to come up on the application server.
Ansible stops immediately if anything goes wrong and triggers rollback followed by verification of services.
Ansible interacts with selenium to trigger smoke testing after build deployment on various environments.

Key Components of Automated Deployment Framework

The diagram below illustrates the key components of the automated deployment:

automated-deployment-key-components

Deployment tool: Ansible is used as a deployment tool and plays the role of a controller. It decides which steps to execute next, based on the outcome of the previous step. It interacts with various servers to execute predefined steps which are part of Automated deployment.
Bash script: Ansible interacts with various servers and runs a script on the server to accomplish various tasks.
FTP / Artifactory: The location from where Ansible downloads the software release. Based on our needs according to the environment, we can choose any location.
Notification: Automated Deployment framework notifies team in the various slack channel to show deployment progress.
Pre-validation: The framework verifies the services running on the environment before initiating deployment.
Health check: The framework verifies the health of the server with which it will interact. If health is not good, then it does not proceed with deployment and notifies the team about the same via a slack channel.
Post-validation: After upgrading services, the framework verifies services to ensure the software release has been successfully upgraded.
Rollback: The framework has the capability to trigger rollback and restore services if any step fails.
Selenium: The deployment framework verifies services in pre- and post-validation by initiating selenium scripts.
Server reachability: Before initiating deployment, it verifies if all servers are reachable to avoid any risk during deployment.

Benefits

The automation of the deployment has helped us achieve the following direct benefits in some of our customer’s projects:

Planned downtime in production for new build deployments is reduced from 3 hours to 1 hour.
No manual testing required after software release up-gradation.
Parallel deployment can be initiated for multiple sites.

References: