 Devops is hot. Many organizations are working to understand and implement the processes and tools required to streamline delivery from development to operations. What’s new about these practices and why are they important? Devops takes much of its focus from Agile development and has the potential to change the way that technology teams work together in many significant ways. ITIL has also resulted in significant improvements in how IT operations handles release management, service asset and change management (SACM). All of this is good news for development teams who want to rapidly build, package and deploy applications. Read on if you would like to understand how to implement Devops Best Practices.
What is Devops?
I have seen a number of conflicting definitions of DevOps with most focusing on streamlining the iterative lifecycle that has become synonymous with Agile development. Some experts focus on the role of development with QA (and testing) all the way through the lifecycle to the operations team managing production. Others take an even broader focus on including all stakeholders that is indicative of the cross functional (self-managing) team. The focus of Devops is on having an operations team with strong technical (development) skills and excellent communication with the entire technology team including development.
Is Devops Really New?
Much of Agile and Lean have their origins in earlier teachings, especially those of W. Edwards Deming, known by most as the father of Quality Management. One of the core principles of Devops is that the operations team should have strong development skills and that is certainly not new. I have worked in operations support functions, sometimes termed “Production Support” or “Sustaining.” Most of us were developers on one project and operations support on other projects. Our technical skills were strong and all of us had hands-on experience. But that is not always the case. I have seen operations teams who had very limited technical skills and were often playing “catch-up” with the developers. Devops puts the focus on strong technical skills, where they belong.
Cross Functional Teams
The use of cross functional (self-managing) teams is very popular in Agile development. With this approach, there is a focus on each member of the team having diverse and flexible skills along with sharing roles and responsibilities. Dean Leffingwell mentions that operations “wants to be more involved towards the end of the project” (Agile Software Requirements, p. 132). Jez Humble and David Farley explain that, “Devops … is focused on … encouraging greater collaboration between everyone involved in software delivery in order to release valuable software faster and more reliably” (Continuous Delivery, p. 28). I believe that all stakeholders need to be aware of the status of the project as well the technical architecture to a level that fits their own job requirements. We also need to automate the entire delivery pipeline.
Automation is Fundamental
The focus of this entire effort must be on creating reliable automation to build, package and deploy applications in a rapid iterative way. Continuous Integration and Continuous Deployment both place a heavy focus on automated processes to implement what Jez Humble refers to as the deployment pipeline and is a central pattern in his book. There are other reasons why automation is so important and that has a lot to do with the ergonomics of release management.
Ergonomics and Quality
Engineers who design the cockpit of a plane always focus on arranging the instrumentation in a way that makes pilot error far less likely. We need to implement many of these same principles when we engineer release management automation. It has been my experience that technology professionals often fail to consider the best ways to bullet proof their code so that mistakes are almost impossible. In my own book on Configuration Management Best Practices (http://cmbestpractices.com), I call this “Bob-proofing” a build in a whimsical reference to making it impossible for anyway to make a mistake during the release and deployment stages. As a consultant, I often get called in to help with fixing and improving release management practices (usually after a really bad mistake caused a memorable problem). Good release management practices especially scripted automation, result in significant improvements in both productivity and quality.
What About Compliance?
Many organizations require a “separation of duties”.for compliance with section 404 of the Sarbanes Oxley Act of 2002. There are similar requirements for PCI Compliance (usually associated with merchants who accept credit cards) and also many SAS-70 audits. This means that the developers are prohibited from being the person to deploy the application and support it in production. In practice, I have implemented a number of creative approaches to handling this situation and they all rely upon automated build, package and deployment. I have also gotten pretty creative when staffing resources were limited, resulting in what I have termed, the Virtual Release Manager.
The Virtual Release Manager
I have often had the task of automating the build, package and release of applications. I always implement this using a separate “build meister” account (with a few admin tricks so that I know the real identity of the user at all times). My automation provides an independent build, usually from a separate user account on a separate computer with full logging (to provide traceability). With this approach, I have played buildmeister for many different teams. At times, I have had to turn over the release management to the very people who were having trouble with this process before. The auditors accepted this arrangement only because the developers used a separate account and I would review the logs which documented every step of the build, package and deploy. These tools provided us with an approach that was essentially a Virtual Release Manager. Just to be clear, there are many environments where there just has to be a separate (and independent) release management function performing independent builds and enforcing separation of duties. This may be a challenge for some Devops efforts and you will need to align your processes with the requirements of your organization to establish proper IT controls in compliance with industry regulations.
Connecting ITIL With Development
ITIL provides a comprehensive framework for establishing IT Service Management (ITSM), including operations. ITIL has a strong focus on Configuration Management including Service Asset and Change Management (SACM), Release Management and also describes essential tools including the Configuration Management Database (CMDB), Federated CMDB, Configuration Management System (CMS), Definitive Media Library (DML) and Version Control (VCS). ITIL provides considerable guidance that is of value to Devops helping to align IT Service management with Agile development practices.
Conclusion
Devops is hot because it provides an essential focus that can improve productivity and quality. Establishing Devops helps to align the development team with the operations team in many essential ways. This is good news for developers who need to understand how the application will behave in Production (and be perceived by the customer base). The operations team also benefits from better communication and improved knowledge that is essential for knowing how to support a complex application. Many organizations will need to implement Devops in a way that is in alignment with their own culture, business and technical requirements. You need to stay abreast of Devops Best Practices to know how to successfully implement and support your own continuous integration and deployment efforts. Make sure that you drop me a line and share your own experiences with implementing Devops including both challenges and best practices!
About the Author Bob Aiello is a Consultant, Editor-in-Chief for CM Crossroads and the author of CM Best Practices: Practical Methods that Work in the Real World, Addison-Wesley Professional ( http://cmbestpractices.com). Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob has served as the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at bob.aiello@ieee.org, link with him at http://www.linkedin.com/in/bobaiello or visit his corporate website http://yellowspiderinc.com
Trackback(0)
Comments 
Write comment
 |
Behaviorally Speaking 
TrackBack URI for this entry
Subscribe to this comment's feed
