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.