kalafoto - Fotolia
The term continuous is rampant in organizations that practice DevOps. DevOps' goal is to continuously introduce positive and expected code changes into test environments and subsequently into production.
Continuous delivery (CD) sets up a scenario for a human to deploy to production at any time. Organizations that practice continuous delivery, not to be confused with continuous deployment, automate most of the software deployment process but rely on a manual process to deploy changes to production environments.
Continuous delivery principles lead to more frequent, reliable and predictable software deployments. This approach ultimately reduces the cost, time and risk of making changes to critical production environments.
To achieve a CD software deployment model, organizations should understand and adopt these fundamental continuous delivery principles.
Understand the problem CD solves
Step back, and decide what pain a team can alleviate through CD. Continuous delivery principles address issues and processes that continuous integration (CI) does not -- does your organization need one, the other or both? The decision comes down to specifics: Reliance on a team of admins for manual software deployment could cause problems -- for example, if a standardized procedure isn't in place to provision tests, or teams are having a hard time with a versioning system. In this situation, continuous delivery removes the bottleneck and enforces common standards.
Hire or train CD subject matter experts
The concept of automating steps in the software deployment process can be a culture shock to individuals that don't trust a new approach to deliver vital software. For a CD initiative to succeed, every team member must be adequately briefed on common continuous delivery best practices and trained on how the CD system works.
There cannot be a dedicated team just for continuous delivery: Organizations often have subject matter experts on CD, but continuous delivery principles must be part of how developers as a whole conduct business. These concepts must be engrained in each team and simply become the modus operandi.
Start slowly and small
Every organization's culture is different. Not everyone trusts CD or understands its purpose. Start implementation with pipelines for lower-priority projects, and hold regular stand-up meetings to accurately demonstrate the value of CD.
Continuous delivery principles don't demand an all-or-nothing approach. A single CD pipeline for every developer on every project is a pipe dream -- organizations set up multiple pipelines, designed to accommodate the needs for an entire product or tailored based on specific product features or projects.
Get upper management's support
Upper management should advocate for continuous delivery principles and enforce best practices. Once an organization has set up strong CD pipelines and reaps the benefits, resist any efforts to succumb to older, less automated deployment models just because of team conflicts or a lack of oversight. If a group must work closely together but cannot agree on continuous delivery practices, it's critical that upper management understands CD and its importance to software delivery, pushing the continuous agenda forward and encouraging adoption.
Understand regulatory issues
Regulation is rarely considered a driver of innovation, so before your team adopts continuous delivery practices, understand any regulatory requirements the organization is under. No one wants to put together a CI/CD pipeline then have the legal department shut it down.
An auditor needs to be informed about and understand, for example, the automated testing procedure in a continuous delivery pipeline. And the simple fact that it's repeatable does not mean a process adheres to the regulatory rules. In some organizations, code developers cannot authorize the product to go live in production, so no matter how seamlessly CD works, they will never achieve continuous deployment.
Sync up environments
One of the most common issues that erodes trust in continuous delivery's call for automation is setup differences among test, quality assurance and production. A perfectly honed CD pipeline that delivers reliable software to test at astonishing speeds means nothing if the production environment looks entirely different from dev and test. Abstraction technologies, such as containers, help cut down on works-on-my-machine syndrome but will never entirely alleviate the problem. Follow the continuous delivery principle that dev, test, staging and production should all be as similar as possible.
Continuous delivery best practices only work if this principle is in place: Never let changes go straight to production outside of the pipeline. This bad practice enables teams to deploy untested changes and also leads the production and test environments to become out of sync. Be sure that everyone knows that the only way to deploy to production is through the CD pipeline.
Continuous delivery is a significant undertaking -- especially in large enterprises -- but it is achievable. Follow the principles outlined above, and stick to them -- even through tough transition periods. Organizations will ultimately produce more reliable software, with fewer bugs, in a more predictable way and at a more rapid pace with continuous delivery best practices than those that still cling onto less automated software delivery models.