2012: The Year of DevOps

its operations group to identify potential release windows, any release blackout periods to avoid, and the need for operations-oriented milestone reviews, such as production readiness reviews, later in the lifecycle, if appropriate.

Active Stakeholder Participation
Disciplined agile teams work closely with their stakeholders, including both operations and support staff, all the way through the lifecycle to ensure that their evolving needs are understood.  

Continuous Integration
Continuous integration (CI) is a common technical agile practice where the solution is built or compiled, regression tested, and maybe even run through code analysis tools. CI promotes greater solution quality by reducing the feedback cycle, which in turn enables easier releases into production.

Independent Testing
For enterprise-class development, or at scale, a disciplined agile team will find it needs to support its whole team testing efforts with an independent test team running in parallel to the development team. This is particularly true when the domain or technology is very complex or in regulatory environments. These testing issues often include validation of non-functional requirements—such as security, performance, and availability concerns—and system integration with the production environment. All of these issues are of clear importance for operations departments as they affect the running characteristics of the solution once in production.  

Continuous Deployment
Continuous deployment is when you automate the promotion of your working solution between environments. By automating and running as much of the deployment effort as possible, the development team increases the chance of a successful deployment, thereby reducing the risk of a troubled deployment to the operations environment. Note that deployment into production is generally not automatic, as this is an important decision to be made by your operations or release manager.

Continuous Documentation
With this practice, deliverable documentation—including operations and support documentation—is evolved throughout the lifecycle in concert with the development of new functionality.

Production Release Planning
This is the subset of your release planning efforts that focuses on the activities required to deploy into production.  This potentially includes choosing a release window, planning for training and education, planning for parallel system runs, planning for hardware upgrades, planning for infrastructure software upgrades, and many other activities.

Production Readiness Reviews
There should be at least one review, performed by the person responsible for your operations environment, before you deploy the solution into production. The more critical the system, the more product readiness reviews may be required.  During production readiness reviews, one or more operations people will assess whether or not the development team has done the work required to ensure that their solution can be safely deployed. Here are some of the questions the review asks for: Have installation scripts been tested?  Can the new release be safely backed out if something goes wrong?  Has the solution been adequately tested for production system integration issues?  Is the supporting documentation sufficient and up to date?  Will development team members be available if the installation goes poorly?

End-of-lifecycle Testing
There is always testing to do once construction has ended. Minimally, you will need to run your fully automated regression test suite against your baselined code once construction ends. There may also be manual acceptance reviews or testing to be performed, and any appropriate fixing and retesting required to ensure that the solution is truly ready for production.

In Conclusion
There’s more to DevOps than simply adopting some good practices. Your process must also embrace several supporting philosophies. The Disciplined Agile Delivery, process framework not only adopts the practices listed above but it also promotes several philosophies that enable DevOps. The first is that delivery teams should be enterprise aware: They should work with people, such as