I predict that in 2012, DevOps will become the new IT buzzword, joining cloud, web services, Scrum, and many others in the buzzword pantheon. We in the agile community have been bouncing it around a fair bit as of late, and it seems to be gaining steam within the IT community in general.The basic premise behind DevOps is that your development strategy and operations strategy should reflect one another, and you should strive to optimize the whole IT process. This implies that development teams should work closely with your operations staff to smoothly deliver new releases into production, and that your operations staff should work closely with development teams to streamline critical production issues.
Let’s explore DevOps in greater detail using three dimensions critical to DevOps success: process integration, tool integration, and data integration.
Process Integration
There are activities in your development and operations processes that affect transitions between teams, and these activities must reflect the realities of both operations and development. Examples include both the deployment of a solution into a product and the resolution of production problems caused by defects in a solution (which therefore must be fixed and redeployed).
Tool Integration
Tool integration occurs when one tool leverages an interface provided by another. Interfaces may be tool specific, such as an API, or more generic (and scaleable) based on an open standard specification such as Open Services for Lifecycle Collaboration. For example, to enable the release of a solution into production, a deployment tool could access production configuration information maintained in an asset management tool. To enable reporting of a problem with an application, a support management system could register the defect report into the work management tool used by your development teams.
Data Integration
Data integration occurs when tools can work with easily with one another’s data. For instance, on the development side a released solution may include quality results, configuration information, and proof of regulatory compliance. In operations usage, statistics are tracked and configuration and installation details are maintained for the solution. Federation of this information enables consistency and accuracy between the development and operations teams through improved data quality, which in turn reduces overall costs and even potential outages.
Agile Development Strategies for DevOps
DevOps has its roots in agile software development when agilists realized that they needed to work effectively with operations staff in order to release often into production. Because of these roots, there are several agile development strategies that enable effective DevOps throughout the agile delivery lifecycle.
Initial Requirements Envisioning
At the beginning of the project, disciplined agile teams invest time identifying the high-level scope in a lightweight, collaborative manner. This includes satisfying common operations requirements, such as backing up and restoring data sources, instrumenting the solution— which refers to adding functionality to the application to log critical actions— so that it can be monitored in real time by operations staff, or architecting the solution in a modular manner to enable easier deployment.
Initial Architecture Envisioning
Disciplined agile teams also identify a viable architectural strategy reflecting the requirements of their stakeholders and your organization’s overall architectural strategy, hence they need to work closely with your enterprise architects and operations staff. The agile team needs to ensure that it is building (or buying) a solution that works well with the existing operational infrastructure and negotiate with operations staff any infrastructural changes (such as deploying new technologies) early in the project. The team must also ensure that operations-oriented requirements are addressed by the architecture from the very start.
Initial Release Planning
As part of release planning, the disciplined agile team works closely with 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 operations staff and enterprise architects, to understand and work toward a common operational infrastructure for your organization. Second, as implied earlier, operations and support people should be recognized as key stakeholders of the solution being worked on. Third, the team should focus on the overall solution, not just the software. With a solutions focus we recognize that software is clearly important, but we may also do the following: Provide new or upgraded hardware that supports documentation—including operations and support procedures; change the business or operational processes that stakeholders follow; and even help change the organizational structure in which our stakeholders work. Fourth, your process should include an explicit governance strategy. Effective governance strategies motivate and enable development teams to leverage and enhance the existing infrastructure, follow existing organizational conventions, and work closely with enterprise teams—all of which help to streamline operations and support of the delivered solutions.
DevOps is an exciting idea that you’re going to be hearing a lot more about in 2012. Granted, there’s likely going to be a lot of talk and little action within most organizations due to the actual scope of DevOps, but a few years from now, we’ll look back on 2012 as the year when DevOps really started to take off. Now that many organizations have successfully adopted agile strategies to improve their development activities, they will turn to the larger picture of improving their IT strategy as a whole; DevOps is an important aspect of doing exactly that. I wish you and yours a joyful and prosperous New Year.
