The Road to Continuous Delivery

Continuous Delivery promises some incredible benefits. Simpler software deployments to multiple environments, standardized quality gates for multiple applications, and flexible change management across business departments are a few of the scintillating gems waiting to be unearthed. However, an advanced software assembly line will not be easily imposed on any organization, and understanding its dependencies is crucial to managing its stakeholders. This introduction describes some of the abstract obstacles an organization may need to overcome when pursuing Continuous Delivery.

Standardized Applications

Continuous Delivery requires that applications be built and deployed rapidly to multiple environments. Unfortunately, many applications are not designed to conform to this type of process. One dependency that enables Continuous Delivery is requiring the applications to be standardized.

A popular standardization used in continuously delivered applications is The Twelve-Factor App. Compiled by Heroku co-founder Adam Wiggins, the Twelve Factors are guidelines that can be used to keep a web application small, stateless, and scalable. The first factor, codebase, is perhaps the most insightful because it draws the line between “black box” vendor applications and internal development. In the codebase factor, all of the code for the application must be stored in version control. Unfortunately, this automatically excludes any application for which one does not have the source code.

Are the Twelve Factors never applicable to a vendor’s “black box” application? Fortunately, having a team that understands the Twelve Factors will improve their decision-making in regards to “off-the-shelf” applications as well. Being able to understand the Twelve Factors and implement them into an application’s architecture provides insight that will help combat technical debt across many areas of the IT department. In addition, understanding the microservice architecture encouraged by the Twelve Factors provides opportunities to supplement existing vendor applications with independently deployable developed applications.

Create and deploy a Twelve-Factor app for yourself to better understand the benefits this architecture can bring to a development team and an organization.

Standardized Infrastructure

Deployment velocity cannot increase until the underlying infrastructure is standardized through continuous improvement and automation. Development teams can utilize the Scrum method of retrospectives to continuously find bottlenecks in their processes and implement small improvements.

For instance, if a team finds itself constantly fighting with discrepancies across development workstations, it may want to pursue using Docker to standardize the development environment. In regards to the Twelve Factors, this would also help to accomplish the principle of Dev-Prod Parity. Another example could be that a team struggles to update the production environment with updated code from version control on a regular basis because of deployment complexities. Using a tool like Jenkins or Go Continuous Delivery could enable the team to break down the deployment process into standardized steps or a pipeline which could be automatically triggered after specific version control events. This improvement would help achieve the Build, Release, Run factor. Continuous improvement cycles like these should perpetuate until deployments can take place in either hours or minutes.

A common fallacy is that the appropriate infrastructure must already be in place before an organization can even start down the road to Continuous Delivery. Rather, especially when using agile project management practices, Continuous Delivery will slowly pull or demand the infrastructure as the team progresses. Companies steeped in waterfall methodologies may find this to be one of the larger challenges primarily when trying to convince co-workers that Continuous Delivery is possible in such a traditional environment. Nevertheless, even the most traditional of managers can be swayed if the business value is identified.

Do not assume that entirely new infrastructure needs to be built in order to practice Continuous Delivery. Start small, and practice continuous improvement.