9 Practices to Launch Continuous Delivery in Your Organization
The following content is a shortened excerpt from the white paper, The Tools For Continuous Delivery. Download the complete paper to learn more about the benefits of continuous delivery, and the tools to launch it in your organization.
Continuous delivery involves a number of tools, processes and practices that in turn enable more frequent software releases, with fewer errors — just what every business needs. Here's a list of foundational processes and practices you need to have in place in order to launch continuous delivery successfully.
1. Monitor everything.
Collect and analyze data on your production and test environments. You need to know where your baseline performance is, so you can see where to make improvements, and gauge whether you have actually made them. Monitoring tools also offer alerts and reporting.
2. Put all production artifacts into version control.
You need a version control system to keep a record of every version of every feature, add-on or other change to the code base. Infrastructure configurations and changes must also be checked into version control.
3. Developers must continually integrate new changes into the code base.
You need a continuous integration tool so you can integrate all changes, and trigger automated tests on every build. You also need reports to tell you which builds pass and which fail.
4. Automated tests.
These should be triggered by code check-in, so you don’t pass faulty code to the next stage. Remember that you can build tests for many things: performance, scalability, security, internal policy compliance, and more.
5. Automate the configuration of development, test, QA and production servers.
You need a single process for creating all environments so you can make production-like environments available early in the development process.
6. Code review.
Many organizations have change review boards. The 2014 State of DevOps survey found that organizations practicing peer code review were able to release code more quickly than those that required deployment approval from a change review board — without any increase in failed deployments.
7. Release smaller changes.
Bigger releases have more bugs, and they can be harder to sort out and fix, because there’s so much more to check. CSG Systems International, an outsourced billing and customer care company, reduced release size by 50 percent and saw a steep decline in disruptions due to releases, and in disruptions in general. (If you’re interested in learning more about how CSG applied DevOps principles in a large enterprise environment, you can watch a talk by Scott Prugh, CSG’s chief architect and vice president of software development, at the DevOps Enterprise Summit.)
8. Institute blameless postmortems.
If you want continuous improvement (and you should), you need a culture that encourages and supports people when they surface bad news, and that views open discussion of failures as the path to improvement. Sam Eaton, director of engineering operations at Yelp, tells the story of how his ops team at Future PL moved from a culture of blame to a culture of learning together by notifying colleagues quickly about failures, and bringing “failcake.” People appreciated being told up front what had happened, and the cake sweetened the deal.
9. Use dashboards to promote communication.
Use dashboards for communicating the state of your infrastructure, number and types of incidents and other information to your colleagues, both in IT and outside.
Aliza Earnshaw is managing editor at Puppet Labs.