DevOps Principles and Practices
By Bob Aiello
DevOps is a set of principles and practices which help to improve communication and collaboration. DevOps is not just between development and operations, but in fact can be practiced between any two organizational structures which need to improve how they interact with one other. My new book on Agile ALM and DevOps explains how to use DevOps principles and practices to improve communication and collaboration between each of the groups interacting to deliver software and systems to end users. In practice, DevOps principles and practices help to operationalize the DevOps approach by explaining how to improve the existing application lifecycle management (ALM) practices, including application build, package and deployment procedures, change management and much more. The journey to DevOps should begin with effective communication and collaboration.
Effective communication and collaboration
Effective communication requires that the involved parties be included in discussions that impact how DevOps practices will be implemented. Too often, key stakeholders are not included in meetings which impact them in significant ways. Effective communication might include working sessions to review working documents or working sessions intended to develop procedures related to application build, package and deployment. I am usually sharing my screen during these sessions and asking my colleagues to partner with me to fully automate all of the procedures required for reliable and security application and systems deployment.
Systems thinking
Systems thinking refers to considering the entire software and systems lifecycle from beginning to end. Very often, solutions only address a limited scope of the system. Many technology professionals are specialists and only have a narrow understanding of how the rest of the system works. For example, developers may come up with optimal methods for deploying to development machines without considering that it is in the best interests of the organization to have a consistent process across the entire software and systems lifecycle. In the same way, the interests of each of the stakeholders including development, operations, QA, testing and security all need to be considered. Systems thinking can and should eliminate the narrow perspective-taking often the favored by organizational silos. You do not have to change your organizational structure in order to eliminate the negative impact of silos.
Ops using the same practices as development – “left-shift”
Deployment procedures should be consistent across all environments from the initial development test environments through to UAT and Production. The practice of “left-shift” involves getting operations involved in the very beginning of the software and systems lifecycle so that operations professionals can understand the required procedures and help create automated procedures essential for a repeatable process.
Feedback and experimentation
Feedback loops are a fundamental approach in DevOps that facilitate experimentation and continuous process improvement. Agile-oriented retrospectives and collaborative communication between stakeholders help to communicate what works well and address areas that require improvement. Teams should be able to experiment and try different approaches to identify and implement effective best practices.
Sustainable pace – effective culture
Many teams take a defeatist attitude and assume that deployments will always be weekend-consuming activities that require everyone to work very long hours. DevOps transforms the deployment process into a routine event that is highly regarded, but executed with minimized risk and potential impact to the
firm. DevOps spends a lot more time upfront automating the entire application build, package and deployment process. Initially, it may even seem like the
deployment is taking longer than expected because automated scripts are being written to create the automated deployment pipeline. However, automating from the beginning has proven repeatedly to be a very wise investment.
Automation and tools
Robust automation is a key feature of any DevOps implementation and selecting the right tools is an essential first step. While process is more important than tools, in DevOps, tools are definitely a first class citizen. Robust toolsets often require support as well as skilled engineers who know how to use them effectively. The right organizational structure can help to make tools more effective, especially in terms of providing the right support structure to manage their usage on a day-to-day basis.
Organizational structure where collaboration is compelling
DevOps is not specifically a group, although most organizations find that it is helpful to establish a dedicated DevOps team to implement and support DevOps principles and practices. For organizations that utilize the ITIL v3 framework, the Release and Deployment Management (RDM) team is often the right group to take responsibility for establishing DevOps best practices throughout the organization.
Agile and DevOps
Many DevOps practices existed way before agile became popular. But agile dramatically demonstrates the value of DevOps by requiring support for a frequent release cadence. Agile principles also are inherent in DevOps principles. Equally important is understanding the perspectives of each of the stakeholders especially when their approaches and goals are not completely in alignment.
Ops and Dev and the Clash of Perspectives
Development is focused on creating and implementing new features as often as possible. Their world is often characterized as being the “Wild,
Wild West” because almost anything goes and developers are frequently not as disciplined as they need to be. The operations team has a very different
perspective and is generally focused on ensuring that releases are both reliable and repeatabl. The push to deliver changes quickly versus the desire to
maintain uninterrupted services often creates a clash of priorities between development and operations. DevOps aims to address both goals and ensure that
changes can be delivered as often as desired with completely reliable systems and services.
DevOps and the ALM
DevOps should be understood within the broad scope of Application Lifecycle Management (ALM). Just as DevOps engages in broad systems thinking,
DevOps also includes all stakeholders within the software and systems lifecycle.
Getting Started with DevOps
DevOps should always begin by assessing the existing practices to build, package and deploy the application. Manual procedures should be documented into a checklist and then the manual steps should be automated – usually using scripts (e.g. Ruby, Shell, Python etc). Getting operations involved from the beginning of the deployment lifecycles across all environments (development, test through production, inclusive) is essential. The same procedures should be used across all environments with any necessary discrepancies documented, reviewed and understood by all participants. Release coordination and change control are essential functions that help to ensure that all tasks are understood and tracked as needed. Technical risk should also be reviewed and discussed with plans created to mitigate risks that cannot be avoided. Getting started with DevOps requires an iterative approach that is a learning experience for all participants. Goals should be established early so that everyone understands exactly what the team is working towards achieving. DevOps requires complete certainty that the correct code has been baselined in the version control repository, built correctly and packaged with identifiers to ensure that the configuration item is fully traceable and identifiable. Cryptographic hashes should be created to ensure that we can definitively and uniquely identify each CI, making it child’s play to track if the wrong configuration items have been selected.
Securing the Trusted Application Base
Ultimately, we want to create a secure trusted application base. The secure trusted application base enables us to programmatically verify that the correct code has been deployed and also proactively identify any unauthorized changes. This approach will facilitate an accurate and programmatically-updated configuration management database (CMDB) by ensuring that code can be easily discovered through automated procedures. This is the only reasonable way to gurantee an updated and accurate CMDB.
DevOps Process Improvement
Successfully implementing DevOps requires an iterative approach. Frequent retrospectives (some people call them post-mortems) should be held to discuss what went well and what can be improved. The DevOps transformation itself is an agile iterative development effort that needs to involve all of the stakeholders responsible for the successful application build, package, and deployment.
Make sure that you drop me a link and tell me about your DevOps best practices!
Bob
[…] principles above come from early work like The Phoenix Project, The Goal, and Continuous Delivery; others come from more formalized research such as ISO and IEEE working groups on DevOps that I’ve […]
Well no Paul – the principles and practices were from my earlier writings and most definitely were not inspired by the Phoenix project although perhaps thoughts from Jez’s work on Continuous Delivery. I coauthored the ISO/IEEE documents you refer to and actually they used my earlier articles going back to my books on CM Best Practices, Agile ALM & DevOps – Bob