In his Behaviorally Speaking series, Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior.
Many organizations struggle with understanding and implementing DevOps. The first question most managers ask is, “What is DevOps and how will it help me?” Organizations often refer to DevOps in several very different ways, and therein lies the confusion. Read on to find out what DevOps really means and what its practices can do for your work processes.
Many organizations struggle with understanding and implementing DevOps. The first question most managers ask is, “What is DevOps and how will it help me?” I have been seeing organizations refer to DevOps in several very different ways, and therein lies the confusion.
DevOps is actually a set of loosely defined principles and practices that help development, QA, and operations organizations communicate and collaborate more effectively. Some organizations have developed a view that DevOps is focused on highly skilled developers who have the access to build, package, and deploy applications directly to controlled environments, including QA, UAT, and production.
Too often this approach does not include the separation of controls that are required in many industries for regulatory and audit requirements. I often refer to this as dysfunctional DevOps, where (often well-meaning) technology resources are trying to bypass IT controls put in place to prevent mistakes in the name of getting things done faster. The truth is that having developers with root access does not generally scale well beyond three guys in a dorm room creating the next Internet startup. Once they achieve their first success and hire another seven engineers, they often start stepping on each other. IT controls don’t slow you down—they help you avoid costly mistakes like the many recent outages at trading firms and large banks.
The second view of DevOps is automating the provisioning of servers and infrastructure, which is obviously a valuable and essential endeavor. I have been scripting the provisioning of servers and their architecture for many years—long before it was popular to call this approach DevOps. My own focus on DevOps has been largely to help development and operations groups operate more effectively. DevOps is really about getting teams with very different perspectives to work more effectively together. Here’s how to approach this effort.
I generally start by conducting an assessment of the existing best practices as compared to industry standards and frameworks. Usually, I ask each participant to tell me what works well and what might be improved. The view I get from the development community is usually quite different from what I hear from the operations team. When I speak with the QA and testing resources, I get another completely different perspective. There are actually many difference resources within software and systems lifecycles, and DevOps is really all about getting your subject matter experts to share information more effectively. For DevOps, this usually comes together in creating the deployment pipeline.
Operations is focused on ensuring that applications are available 24/7 without the risk of a service interruption. The developers are charged with writing code to implement new and exciting features. Blending these two viewpoints is a matter of ensuring that we have the agility to deliver new features early and often without the risk of downtime due to a systems glitch—especially due to a mistake during application deployment or a systems upgrade. The key to successfully implanting better deployment is through automation using the same procedures throughout the entire software and systems lifecycle.
Automating the application deployment requires that even the simplest tasks be scripted and also that the code verifies itself. To do this successfully, you need to start doing the right things from the very beginning of the lifecycle. I have seen many organizations that handled deployments in a very loose and unstructured way for development and integration testing. These same teams try to impose formal procedures for the deployment to production (and sometimes UAT).
Getting deployments right is hard work, and the only way you will be successful is if you start doing deployments to development test environments using the same procedures you intend to use when deploying to production. This approach allows the deployment team more time to understand the technical details and also automate the entire application deployment process. I always tell people that getting the operations folks involved early makes perfect sense because somebody has to do the deployments to development test, integration, and QA environments, and you get much more efficiency by having them be the same folks who will be responsible for deploying to production.
Whoever does the deployment to a particular environment, the main point is to automate each step and make sure your code also verifies itself. My own code always contains just as many lines to test and verify that each step completed successfully as the actual steps of the deployment itself. Your goal here is to detect any problems as soon as possible and enable your deployment pipeline to fail as fast as possible when there is a problem. I usually write these scripts in Ruby, as most deployment frameworks allow you to plug in your Ruby scripts seamlessly.
Effective DevOps requires that you have configuration management best practices, including version control, automated application build, package, and deployment. It also requires that you ensure the effective collaboration of all your stakeholders, including development, operations, QA, testing, and data security.
DevOps is really all about facilitating highly effective cross-functional teams. Obviously, enabling your team members to collaborate and communicate effectively will help your organization achieve success.
Drop me a line and tell me what you believe DevOps is all about and how you are going about implementing DevOps principles and practices!
