Developer Operations or “DevOps” is a term used to describe the gap between operations and the development team. In the consulting world, operations could be an internal infrastructure team, the corporate IT department at a client site, or even a third party vendor. The key is that it’s typically a person or team that’s focussed more on the hardware aspect of IT. The role of a DevOps practitioner or team, therefore, is to bridge that gap. They will take code that’s checked into a repository somewhere and get it built, deployed and running for development teams, QA teams, and clients to use.

All projects are different, and depending on the environment, the gap DevOps needs to bridge can be small or large. It depends on the scope that the development and infrastructure teams have under their umbrellas. For example, some development teams will write their own build scripts and check them in with the code, while others deal with raw source only. Some infrastructure teams will build a virtual machine or simply install an OS on bare metal and hand it over to DevOps, while others will build a fully functioning environment and only grant DevOps rights to deploy the application. All of these models can work. For a small project, you may not even have a DevOps team. You might incorporate DevOps tasks into a developer role, etc. On large projects, however, not having a dedicated DevOps team could pose a serious problem…

The Role of DevOps on Large Projects

Large projects are tricky. From a deployment / infrastructure perspective, they often involve multiple environments for Development, Test, Performance Tuning, Live Production, etc. Typically, a large project will have a minimum of three environments for Dev, Test, and Prod. Often, more environments are needed as code is worked on in multiple streams (e.g., release development vs. hotfixes). I’ve worked on projects where we had 20+ environments for a single application and still needed more at times. Complex QA processes or time / scenario sensitive test cases could often mean you have multiple environments per development / test stream. Things can quickly get out of hand. On the development side, the same types of problems exist. Multiple code streams, complex branching strategies, and many other factors need to be carefully planned out and acted upon to keep your source code up-to-date.

Having a dedicated DevOps team can go a long way to plan, manage, and govern some of the issues listed above. The team can be a central command center for initiating builds / deployments, tracking change sets across development streams, etc. They can help to manage data loads so the QA teams are able to execute the tests they need and manage users so there are consistent logins across environments. There are a plethora of things that your DevOps team can do for you – things that need to be done, but may be a secondary or tertiary priority if they were left to the architecture or development team.

Empowering your DevOps team to own the above processes is key because they are so crucial to the successful delivery of your software, yet so often overlooked or taken for granted. Through this ownership, your DevOps team will continue to grow and adapt policies to better meet the needs of all teams involved. Even better, having them involved early in the project can help use their experience to guide decisions on source control, issue tracking, build and deploy tools, etc. With a greater industry focus on Application Lifecycle Management (ALM), many tools exist in the market and finding a suite that will work well together is an important first step in any project. Since a great deal of that solution will be managed or used by the DevOps team, their feedback is crucial in that selection.

So, the next time you start up a new project, make DevOps a forethought, not an afterthought. If necessary, bring in a specialist to help determine what the DevOps gap is likely to be for your project and help plan a path forward so that your DevOps team is resourced properly. If not, you may find that your ability to cut code is great, but you’ll have no way to get it into Production.