Getting Started Scaling DevOps

DevOps has become a popular and largely successful approach to managing application build, package, and deployment. Technology managers are embracing DevOps and expect most software engineers to understand exactly how to operate in a DevOps-centric environment. But DevOps also has its challenges, starting with the fact that many people do not really understand its principles and practices. I have heard colleagues use the term DevOps to refer to anything from developers who deploy their own code to an Ops group that controls all aspects of deployment engineering.

DevOps is actually a set of principles and practices that are effectively used to improve communication and collaboration between development and operations. But how exactly does one implement DevOps, and, more importantly, how do we scale DevOps to meet the needs of a larger enterprise application development? This article will help you get started with scaling DevOps.

Many people think DevOps is just developers who deploy their own code into production. While it is true that DevOps does embrace robust deployment automation, this view of DevOps does not scale beyond three developers in a dorm room. Another misconception is that DevOps requires a specific team, and of course, that would raise the question of where a DevOps team would exist in a large organization.

I have participated in creating a release and deployment management group as described in the ITIL v3 framework, and we chose to make this group heavily aligned with DevOps best practices. But in a large organization, you will likely need to work with existing resources instead of creating a new group called DevOps. So, how do you actually implement DevOps when you are working in a large bank or other firm? The key is to focus on DevOps principles and practices within the context of the organization where you are working.

DevOps centers on improving communication and collaboration between development and operations. But actually, many companies have silos of smart people doing important work who can benefit from DevOps best practices. One technique I often use is to assess the existing practices by interviewing a wide array of teams within the organization. I usually start by asking them what works well, and they usually then volunteer exactly what’s wrong. Armed with understanding the challenges from different perspectives, I then start bringing the team together using online working sessions that resemble a virtual approach to Extreme Programming-style paired programming. This work is always focused on automating the application build, package, and deploy process and embraces a popular technique known as “left-shift.”

Years ago, developers would code and test and then let the operations team know when the applications were ready for production deployment. The left-shift approach involves getting operations involved earlier in the process. When I am in an operations role, I volunteer to do the deploys from the very beginning of the lifecycle, including into what is usually called development integration testing.

The key here is to share information early and often between development and operations and promote a culture where all stakeholders get to contribute to improving existing processes and procedures. The most common approach is to have a code review-like session to go over documentation, procedures, and even automated scripts. Making collaboration and information-sharing a priority is fundamental, but you also need to consider whether your existing application tools and processes are robust enough to scale to an enterprise level. I usually start with considering the version control systems and then move on to build engineering.

Many organizations are very successful with using open source tools for version control, application build (including continuous integration), and deployment automation. But some of these same tools do not really perform successfully when they reach hundreds or even thousands of users. In scaling DevOps, I have found that there are times when enterprise-ready commercial tools can help me implement processes that support multiple locations and a wide variety of technologies. In these situations, I have learned to implement DevOps principles and practices across a wide variety of technologies and teams. Generally, we like to standardize on one set of tools and processes, but my real world experience is that this is not always possible.

For example, when working with C# or .net developers, we found that using familiar tools, including Team Foundation Server, worked much better, while our Java developers were very comfortable working with open source tools. Other teams might prefer to work with robust commercial tools that help manage their entire software and systems lifecycle. Regardless of the tool set selected, we focus on approaching implementation from a DevOps perspective.

In large-scale organizations you also need to consider regulatory and audit requirements, which means you may need to embrace frameworks, including ISACA’s COBIT or ITIL v3, and also industry standards, such as ISO 9001:2008, which establishes the quality management system. Scaling DevOps requires that you consider the entire application lifecycle.

DevOps best practices must focus on improving communication and collaboration. If you want to be successful, you need to take an agile and iterative approach as you deploy and improve your organizational processes. DevOps best practices are proving to be very successful. Organizations that learn to implement and scale DevOps benefit from robust and effective application build, package, and deploy processes, thereby delighting their customers with reliable systems that meet their end-users’ needs and enabling the business to achieve success and profitability.