A key goal for any DevOps team is to shorten the software development cycle and provide continuous delivery of high-quality software. Instead of continuing to the next logical goal, continuous deployment, most companies stop here. Developed code reaches the testing phase automatically, then, successful testing triggers a manual acceptance step. Only then is the application deployed into production.
This article describes some plans and practices you need to establish so that your team can deploy applications frequently and reliably using a continuous deployment process.
Continuous delivery versus continuous deployment
Before we explore the world of continuous deployment, it is important to understand where continuous delivery ends. There are also some processes and designs to consider as your team moves towards continuous deployment. It is also important to maintain a DevOps mindset as you take this project on. I will explain what that is later on in the article.
In a continuous delivery process, developers rebuild the codebase with each change to make sure no one breaks the build. User acceptance testing and deployment may be entirely manual steps. In contrast, continuous deployment tries to automate both acceptance testing and deployment, so that builds go through to production automatically and regularly.
Generally, continuous delivery answers the question “does it build and run?” while continuous deployment answers “does it work and is it deployed?”
Prerequisites for continuous deployment
To move your application into continuous deployment, your team will need to adopt technical and personnel process changes. There is no requirement to use a particular tool or process. Instead, use a consistent approach to development and deployment, with automation as a supplement.
Your application’s architecture and the amount of downtime when releasing new versions can affect deployment frequency. The next sections of this article explore some of these to give some background for deciding on continuous deployment options.
A critical part of a continuous delivery pipeline is Agile teams. These teams constantly build and deliver software. The more familiar your teams are with small, quick development cycles, the more successful your continuous deployment practices will be.
It is much easier to automate, test, and deploy small changes frequently than it is to make significant changes every few months. It is also much easier to roll back small changes if something goes wrong.
Make sure your DevOps teams work together on building software from the start. They should collaborate on functionality, bug fixes, building, and security, from design to deployment.
Developing and deploying quality software requires consistent investment from all members of our DevOps teams. Siloed groups, a lack of security, or insufficient testing breaks development continuity and makes deployment difficult. If your teams do not believe continuous deployment is possible, it will not happen.
Automated testing tools should already be a part of your continuous integration and continuous delivery (CI/CD) pipeline to ensure the software you deliver meets quality metrics. Without a comprehensive suite of tests to validate all your application’s existing and new components, your team cannot rely on that software to perform. As you build more functionality into your application, it becomes more critical to make sure that regression testing occurs for all functions.
Stable CI/CD pipelines
Because continuous deployment builds on top of continuous delivery, having a stable CI/CD pipeline to expand from will set your team up for success. If your team cannot reliably and consistently deliver their application, they will not be able to deploy the application reliably and consistently either. Having dedicated CI/CD engineers looking after your pipeline keeps development output consistent. You can learn more from the ebook How to be a CI/CD Engineer.
Your application’s architecture can also play a significant role in deploying continuously, because it affects downtime. For example, a team builds an application using scalable application nodes behind a load balancer. That team can then automate patching a batch of nodes before switching the load balancer from one version to the next.
Adopting a non-destructive approach to your database layer can also reduce the need for manual intervention. Martin Fowler and Pramod Sadalage’s article Evolutionary Database Design reviews more in-depth approaches to databases in an Agile environment.
Starting continuous deployment
Once you have the right components embedded in your environment, your next step is to review your current end-to-end build and delivery process. Look for any processes or actions you can streamline or automate. The goal of continuous deployment is not to skip every manual step. The goal is to automate each step when possible or to simplify it so that it is as quick and painless as possible.
For example, you will still need to review code and merge pull requests manually. You can complete these processes rapidly and frequently to get features and fixes into your applications as soon as possible.
Consider two manual components that we can automate or streamline:
- Acceptance test automation
- Release orchestration
Acceptance test automation
End-user test automation and robotic process automation tools have come a long way over the last few years. Adding some of these tools into your acceptance testing phase can help reduce manual testing.
These tools require that testers are involved in the development process early. These testers can record tests with non-technical staff by employing user stories. Tools like CloudQA enable testers to record end users operating the application. You can then script these actions and add them to your test suite so that both new functionality and regression testing are automatic throughout the acceptance testing phase. You can then move to production with confidence.
Release orchestration enhances your continuous deployment pipeline by verifying that your application is deployed with all critical components in place.
Quickly deploying a new feature to production sounds great, but you still need to make sure that dependencies and documentation exist and that you have updated the data layers to reflect the changes.
Adding release orchestration tools and processes provides a layer of planning and coordination defined by a clear set of business rules. This layer can include automated steps to modify infrastructure and deploy application components. It combines automation with manual actions such as approval requests. Release orchestration makes sure your team has configured production releases correctly.
Automating your deployment using techniques like blue-green deployments can also reduce your environment’s downtime to almost zero.
Optimizing your deployment processes is not a one-off activity. Reviewing how your DevOps teams work should happen on a regular cadence.
You should also have Developer Experience Engineers (DXEs) track, measure, and optimize the way developers work and look for better tools and processes for the development pipeline. To learn more, read Why Developer Experience Engineers (DXEs) are the key to accelerating your business.
Getting your existing continuous delivery pipeline to a high level of maturity will help make sure that your continuous deployment pipeline works consistently. By adding acceptance testing automation and release orchestration to this foundation, you get a continuous deployment pipeline that further streamlines your DevOps team’s development processes and gives your team an opportunity to concentrate on future enhancements.