Sergey Nivens - Fotolia
DevOps organizations constantly toss around the word continuous, making it synonymous with fast code delivery to production environments.
Continuous deployment, when code updates go straight to production, is the ultimate goal of many organizations, but few get there. It's hard, with plenty of factors to prevent adoption. One sticking point for organizations is continuous deployment tools.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
While deployment occurs at the end of a pipeline, continuous deployment requires tooling choices from the left -- such as version control -- through the deployment acceptance end, and all the build and test services in between.
Services that require a continuous deployment tool selection can be grouped into three distinct categories:
- version control;
- build automation with testing; and
- deployment with testing.
Tools can fall into one or more of these categories, but to practice continuous deployment, an organization must have all three.
Track code versions
Version control is not only a requirement for continuous deployment; it's necessary for almost every software project. Version control tools enable developers to check in or commit changes. These changes are then tracked over time, which prevents file name structures, such as feature.bak and feature2.bak2. The full version history is attached to every file, which enables a developer to view or revert to a specific state of the code at any particular time.
Version control branching features enable developers to create copies of an entire code base and work from that. Creating a branch enables the developer to change as much of the code base as she'd like without worrying about affecting other branches. When she's done, she can merge those changes back to the original source, recreating a single branch.
There are different varieties of version control tools. Git and its social counterpart, GitHub, are among the most popular. Git is a local version control system wherein developers create a repository, sometimes called a repo, on their local computer to check code into. Git offers all of the typical version control tool features, such as the ability to check in code, create branches and merge code. Git is also called a distributed version control system because Git repos exist solely on a developer's local computer. However, this distributed nature presents developers with a collaboration issue. Keeping all Git repositories in sync is a pain, so GitHub links these Git repositories together.
GitHub also offers additional services, such as pull requests to contribute code, bug and feature tracking and documentation storage. GitHub popularized Git and made it easy for a newcomer to get started with Git repositories.
Automate code builds
Once code is checked into version control, it must be built. Building entails any necessary actions to wrap up code and artifacts into a consumable piece of software for the end user. Build tool tasks can consist of code compilation, packaging and merging various libraries together.
Build automation tools define the steps to create a build. Every tool performs this task a little bit differently.
Any reputable build automation tool includes a testing feature. Testing methodologies, such as unit testing, are typically done in this stage. Unit tests ensure recent changes haven't introduced bugs. Unit tests, if built properly, execute the code in a lot of different contexts and consider each way the code could be executed. This automated testing is important in continuous deployment models, where code updates go immediately into live production without human intervention. In the case of continuous delivery, code makes a stop at operations for evaluation prior to release.
The optimal build automation tool depends on the type of project. MSBuild is popular for projects on the Microsoft stack, and Team Foundation Server and Visual Studio Team Services (VSTS) offer some popular continuous integration features as well. For open source projects, Jenkins, TravisCI and TeamCity are popular.
Deploy strong code
Deployment is the final and most critical phase in continuous deployment pipelines. At this stage, a tool takes build output and then delivers it to production servers or updates a production environment in the cloud.
Continuous deployment tools, such as Jenkins, VSTS, Octopus Deploy and AWS CodeDeploy, deploy the code to production via scripts and immediately perform integration and acceptance tests. Since this is a critical moment, all code deployment tools support testing procedures. Deployment tools enable the build/release engineer or developer to personally deploy code to production and immediately run a suite of tests to ensure it's working as desired. These tests confirm the code is functional, which is sometimes hard to define.
Deployment and configuration are handled by IT automation and configuration management tools, such as Puppet and Ansible. Integration and acceptance tests run upon deployment. Monitoring tools, such as those from AppDynamics and Splunk, track and report any changes in application and/or infrastructure performance due to the new code and can trigger IT incident response management tools, such as PagerDuty. Monitoring and incident response for continuous deployment setups should be as close to real time as possible to shorten recovery time.
If something goes wrong, a good continuous deployment tool should have a rollback feature to undo all changes and return to the former state.
No risk, no reward?
Continuous deployment is the fastest way to deliver software into production but is also, some may argue, the riskiest. Continuous deployment tools eliminate much of this risk through incorporated testing support at all points of the continuous deployment process. Some send automated approval notifications to required parties. However, automated approval request notifications begin to stray away from a true continuous deployment pipeline.
Some organizations prefer to use a collection of tools to manage different aspects of the pipeline, while others prefer to use one tool for the entire pipeline. When making tool choices, consider the full pipeline, the organization's culture, the people and the tolerance for failure.