Many organizations struggle with understanding and implementing DevOps. The first question that 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 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 such as 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 – really 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. Generally, I ask each participant to tell me what works well and what might be improved. The view that I get from the development community is usually quite different than 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 lifecycle 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 by 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 out downtime due to a systems glitch – especially due to a mistake during application deployment or 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 most 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 which 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 that you will be successful is if you start doing deployments to development test environments using the same procedures that 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 the deployments to development test, integration and QA environments and you get much more efficiency by having this resource being 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 that 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 plugin 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 of your stakeholders including development, operations, QA, testing and also 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. Make sure that you 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!