In his Behaviorally Speaking series, Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior.
DevOps puts the focus on automated application lifecycle management supporting development, test, integration, quality assurance (QA), user acceptance testing (UAT), and production. But how do you develop DevOps, and how do you know when you have achieved success?
DevOps puts the focus on developing the same build, package, and release procedures to support deployment throughout the entire application lifecycle. This is a big change for many companies, where developers traditionally did their own deployments and operations joined the party late in the process—usually when the application was being prepared to be promoted to production. In fact, I have seen organizations that put a tremendous amount of work into their production deployments but failed miserably, simply because they started too late in the development lifecycle. DevOps puts the focus on automated application lifecycle management supporting development, test, integration, quality assurance (QA), user acceptance testing (UAT), and production. But, how do you develop DevOps, and how do you know when you have achieved success?
DevOps is not new. Like many other agile and lean practices, DevOps makes use of principles that have been around for a long time. But, also like agile and lean, DevOps clarifies and highlights industry best practices in a compelling way. Traditionally, developers have demanded free reign on being able to build, package, and deploy their own work. As a group, developers are known to be smart and hard working. However, seasoned professionals know that many IT problems and systems outages result from smart people accidentally missing an essential step. In order to create repeatable processes and ensure uninterrupted services, you need to create simple and reliable procedures. DevOps teaches us that we need to begin this journey early in the process. Instead of just automating the build and deployment to QA, UAT, and production, we start at the beginning of the lifecycle and automate all of the processes starting with development and continuing with QA, UAT and finally production.
Industry expert Martin Fowler made continuous integration popular by strongly advocating deploying to a test environment, even for a development build. Creating seamless, reliable, fully automated deployment procedures is not an easy task. There are many dependencies that often are difficult to understand, much less automate. Developers spend their time learning new technologies and building their technical knowledge, skills, and abilities. DevOps encourages improved communication between development, QA, and operations by focusing on the entire lifecycle. The most important part of this effort is to transfer knowledge earlier in the process. You are able to reduce risk by creating a learning organization. DevOps helps to improve both QA and operations' focus by enabling them to be involved early in the development cycle and by creating automated procedures to reliably build, package, and deploy the application. If you want to be successful, then you should also be agile.
DevOps was made popular by a number of agile technology experts, including those involved with what has become known as agile systems administration and agile operations. It is essential to remember that the journey to DevOps must abide by agile principles. This means that the creation of your automated build, package, and deployment procedures should be handled in an agile, iterative way.
Usually, I get called in to deal with a failed application build-and-release process. I often begin by performing many tasks including compiling code and packaging releasesmanually. Over time, I am able to automate each of the tasks, but this is an iterative effort with many decisions made at the last responsible moment. Source code management is also an essential starting point, because every other configuration management function depends it for success. For example, you can only automate a build-and-release effort if you are absolutely certain as to the exact versions.
Developers need to be trained to successfully use version control tools that secure the source code and reliably create milestones, including version labels or tags. DevOps also needs to focus on the seminal competency of excellent source code management. In other words, every function of DevOps depends upon effective source code management for success. Once your code is under version control, you should then work on an automated application build in which each configuration item is embedding a unique and immutable version ID. Release packages are created with embedded manifests containing a complete list of every included configuration item, whether it is a derived binary, text-based configuration file, or a Word document containing essential release notes. Good release management means that you can identify all of the code that is about to be deployed and also provide a procedure (known as a physical configuration audit) to verify that the correct code was, in fact, deployed. It is equally essential to provide a mechanism to ensure that unauthorized individuals have not modified a release package. Testing is also fundamental.
Deming noted that you should build in quality from the beginning. Effective DevOps embraces QA and testing best practices. This is true both for the application itself and also for the automated DevOps procedures that are being developed as part of this effort. In other words, as a DevOps engineer you write code to automate every function and you need to regard this work as a project too. In effect, we need to practice the procedures that we recommend for others as part of our own internal DevOps procedures development effort. This is also a paradigm shift. Developing DevOps is its own agile development effort and should be treated with the same rigor as any other project with the goal of having a fully automated application deployment effort.
The focus on developing these procedures from the beginning of the lifecycle and taking an agile iterative approach as they are developed are what make these practices “DevOps.” There is also an essential effort to share knowledge equally between development, QA, and operations. Development often knows the technology best, but operations understands the real-world challenges that will result in developers being roused from their slumber in the middle of the night. QA helps by developing the procedures to ensure that bugs are not found a second time in any release. DevOps is all about the synergy of productivity and quality with the real-world focus on sharing knowledge and building competencies.
User Comments
Well explained Bob. I agree with every single point.
I would like to add that organizations should try to keep their devops processes simple. If you create a framework, that does not make the developer's job easier, because they have to learn the framework, and that means you need to be around to explain it. Stay with vanilla tools that people can Google. And keep the list of tools short: there are too many tools out there and it creates too much for developers to learn when they should be focusing on their application.
Simplicity is indeed an art form in a an arena where complexity may be unavoidable.
Good points Cliff!