Practice 7: Continuous Deployment
Continuous deployment extends the practice of continuous integration. With continuous deployment, when your integration is successful in one sandbox, your changes are automatically promoted to the next sandbox, and integration is automatically started there. This automatic promotion continues until the point where any changes must be verified by a person, typically at the transition point between development and operations.
White PapersMore >>
- Strategy: 3 Steps to a Hands-Free Cloud
- Strategy: Smartphone Smackdown: Galaxy Note II vs. Lumia 920 vs. iPhone 5
Continuous deployment enables development teams to reduce the time between a new feature being identified and being deployed into production. It enables the business to be more responsive. However, continuous deployment increases operational risk by increasing the potential for defects to be introduced into production when development teams aren't sufficiently disciplined. Successful continuous deployment in an enterprise environment requires all the practices described earlier.
Practice 8: Production Support
In enterprise environments, most application development teams are working on new releases of a solution that already exists in production. Not only will they be working on the new release, they will also have the responsibility of addressing serious production problems. The development team will often be referred to as "level three support" for the application because they will be the third (and last) team to be involved with fixing critical production problems. Although the need to do level three production support is common, with the exception of Kanban and Disciplined Agile Delivery (DAD), many agile methods only address this effort in passing. An important side effect of this practice is that it gives developers an appreciation of the kinds of things that occur in production, providing them with learning opportunities to improve the way that they design solutions in the first place.
Practice 9: Application Monitoring
As the name suggests, this is the operational practice of monitoring running solutions and applications once they are in production. Technology infrastructure platforms such as operating systems, application servers, and communication services often provide monitoring capabilities that can be leveraged by monitoring tools (such as Microsoft Management Console, IBM Tivoli Monitoring, and jManage). However, for monitoring application-specific functionality, such as what user interface (UI) features are being used by given types of users, instrumentation that is compliant with your organization's monitoring infrastructure will need to be built into the applications. Development teams need to be aware of this operational requirement or, better yet, have access to a framework that makes it straightforward to provide such instrumentation.
Practice 10: Automated Dashboards
The practice of using automated dashboards is business intelligence (BI) for IT. There are two aspects to this, development intelligence and operational intelligence. Development intelligence requires the use of development tools that are instrumented to generate metrics; for example your configuration management (CM) tools already record who checked in what and when they did it. Continuous integration tools could similarly record when a build occurred, how many tests ran, how long the tests ran, whether the build was successful, how many tests we successful, and so on. This sort of raw data can then be analyzed and displayed in automated dashboards. Operational intelligence is an aspect of application monitoring discussed previously. With automated dashboards, an organization's overall metrics overhead can be dramatically reduced (although not completely eliminated because not everything can be automated). Automated dashboards provide real-time insight to an organization's governance teams.
DevOps Is Really About Culture
After describing these critical practices which support DevOps, I feel the need to emphasize that the primary critical success factor is to build a collaborative and respectful culture across your entire IT organization. My experience is that people, and the way that they work together, are the primary determinant of success when it comes to adopting an effective DevOps strategy. Unfortunately, it is considerably more difficult to bring about cultural change in an organization than it is to adopt a handful of new practices. More on this in future articles.
What Exactly is DevOps? explores why DevOps is important for developers.
Getting DevOps Right: The Lay of the Land describes some of the challenges associated with adopting DevOps strategies.
Disciplined Agile Change Management discusses change management options.
Disciplined Agile Delivery features more information about the DAD process framework.
Scott Ambler is a long-time contributor to Dr. Dobb's and is the co-author of Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. You can follow him on Twitter.