Deployment Automation
Deployment automation is what enables you to deploy your software to testing and production environments with the push of a button. Automation is essential to reduce the risk of production deployments. It's also essential for providing fast feedback on the quality of your software by allowing teams to do comprehensive testing as soon as possible after changes.
An automated deployment process has the following inputs:
Packages created by the continuous integration (CI) process (these packages should be deployable to any environment, including production).
Scripts to configure the environment, deploy the packages, and perform a deployment test (sometimes known as a smoke test).
Environment-specific configuration information.
We recommend that you store the scripts and configuration information in version control. Your deployment process should download the packages from an artifact repository (for example, Container Registry, Nexus, Artifactory, or your CI tool's built-in repository).
The scripts usually perform the following tasks:
Prepare the target environment, perhaps by installing and configuring any necessary software, or by starting up a virtual host from a pre-prepared image in a cloud provider such as Google Cloud.
Deploy the packages.
Perform any deployment-related tasks such as running database migration scripts.
Perform any required configuration.
Perform a deployment test to make sure that any necessary external services are reachable, and that the system is functioning.
How to Implement Deployment Automation?
When you design your automated deployment process, we recommend that you follow these best practices:
Use the same deployment process for every environment, including production. This rule helps ensure that you test the deployment process many times before you use it to deploy to production.
Allow anyone with the necessary credentials to deploy any version of the artifact to any environment on demand in a fully automated fashion. If you have to create a ticket and wait for someone to prepare an environment, you don't have a fully automated deployment process.
Use the same packages for every environment. This rule means that you should keep environment-specific configuration separate from packages. That way, you know that the packages you are deploying to production are the same ones that you tested.
Make it possible to recreate the state of any environment from information stored in version control. This rule helps ensure that deployments are repeatable and that in the event of a disaster recovery scenario, you can restore the state of production in a deterministic way.
Ideally, you have a tool that you can use autonomously to make deployments, that records which builds are currently in each environment, and that records the output of the deployment process for audit purposes. Many CI tools have such features.
How Deployment Automation helps us?
Save Time - In a DevOps model, part of the mission is to improve efficiency. Standardizing development environments and automating delivery processes support that mission. Manual deployments can be tedious and time-consuming. Typically, there are many specific sets of tasks that must be performed meticulously in a specific order. It's easy, even for someone who has done the same deployment 100 times, to miss a small but critical step. When that happens, the problem may be obvious, or it might take hours to track it down. So if we let computers execute those tasks using a script it saves a lot of time.
Increase Accuracy - Not only does application deployment automation save time, but it also increases accuracy. As mentioned above, a deployment includes a very specific set of tasks that must be executed precisely. If a single step is missed, it could result in problems that don't manifest until later, when they will be very difficult to track down. These kinds of problems are preventable - we already know the steps that need to happen to prevent them, we just need to make sure that they are executed consistently.
Improve Knowledge Transfer & Documentation - With a manual deployment process, it's easy to lose track of the exact set of steps needed to do a new deployment. For example, if a new server is added to a web farm, you need to remember to deploy to the additional server. One approach to this problem would be to document the deployment process and use that as a checklist each time you deploy. However, it's easy to forget to update documentation. It can also be difficult to write with enough accuracy so that if someone other than the author needs to take over the process, they can. Automated application deployments are written in a common language so anyone with training in the deployment tool can understand and modify the process. Your deployment configurations are also self-verifying - the tool should tell you whether your deployment succeeded. The configuration is verified every time you need to deploy.
Allow the Possibility of Auto-Scaling - With the advent of cloud computing, the concept of "auto-scaling" is something that can only be enabled by automating your deployment process. Auto-scaling, in brief, is configuring your application to allocate additional resources when needed. In the past, with physical servers and manual deployments, something like allocating an extra webserver to deal with load would require purchasing new equipment, provisioning it, and then finally deploying the application. That process could take weeks or months. Now, since these cloud machines can be created with code almost instantaneously, it's possible to automate the process of provisioning a new web server. However, the new webserver needs to have instructions on how to set itself up. That's where your automated deployment configuration comes in - give the cloud service a deployment configuration, and let it create resources as necessary.
Common pitfalls in Deployment Automation
Some common pitfalls that prevent wide adoption of deployment automation include the following:
When you automate your deployment process, you face the following pitfalls:
The complexity of the existing process.
Dependencies between services.
Components that are not designed for automation.
Poor collaboration between teams.
Ways to measure Deployment Automation
Measuring deployment automation is straightforward.
Count the number of manual steps in your deployment process. Work to systematically reduce those steps. The number of manual steps increases the deployment time as well as the opportunity for error.
Measure the level (or percentage) of automation in your deployment pipeline. Work to continually increase that level.
Determine the time spent on delays in the deployment pipeline. As you work to reduce these delays, understand where and why code stalls in your deployment pipeline.