Aligning the Dev and Ops Teams
DevOps as a philosophy has had as its centerpiece the principle that Dev and Ops teams need to align better. This is a people and organizational principle, not a process centric principle. To me this is more important when adopting DevOps than any other capability or tool. My last post focused on the need to better align Dev and Ops and the challenges that such organizational change would address. This post discusses key guiding principles on which this Dev-Ops alignment should be based. They are designed to improve collaboration between these organizations and to break down the proverbial ‘wall’; to end the water-SCRUM-fall, when it comes to the relationship between the Dev and Ops teams.
These guiding principles are:
1. Shift Left:
Organizationally the goals of DevOps are to bring Dev and Ops closer. Not just at deployment time, as they may do already, but all through the development cycle. It requires Ops to allow Developers to take more responsibility of the operational characteristics of the applications they are building. In turn, it requires Developers to keep Operational considerations in mind while building their applications. This is referred to in the DevOps world as ‘Shift Left’. As in shifting towards the left, some Ops responsibilities. Shifting it to earlier in the software delivery lifecycle, towards Dev.
2. Collaborate across all teams:
The Dev and Ops teams typically use different tools to manage their projects, for change management and (outside of email) different collaboration tools. In order to better collaborate across the organizational boundaries, these teams should start using the same Change Management and Work Item Management tools or worst case, use tools that are integrated. Thus allowing seamless visibility across tools and traceability between respective Change Requests. Real-time collaboration using a common tool is obviously the best scenario.
3.Build ‘Application Aware’ Environments
As we move towards Software Defined Environments, we have the ability to build, version and manage complex environments, all as code. All of the benefits of this are moot if the environments are not a perfect fit for the applications and more importantly the changes to the applications being delivered. The goal is hence to build Environments that are ‘Application Aware’ or are fine-tuned for the applications they are designed to run. No more cookie cutter Virtual images for all kids of applications. More importantly, one needs to ensure that the environments are architected in a manner to allow for the evolution of the applications, both as they are developed; as they are projected to change or as they may evolve in the future. This obviously, would require close collaboration between Dev and Ops. Development Architects and Product Managers need to work with the IT Architects and Operations Managers to Architect Environments and their projected evolution to align with that of the application. Not only that, but also allow enough resilience in the environments to allow for unexpected change. For example, massive change caused by a super successful App. Think Instagram and how the founders had to keep changing their server environment almost daily as millions joined their service.
4. Environment Sprints?
Agile Development Principles prescribe that at the end of every Sprint, developers have a build. An executable that runs, even if does not do much in terms of functionality. It has been proposed (by the likes of Gene Kim) that this concept be extended to environments. This would mean that at the end of each Sprint, the Dev team would have an executable AND the Ops team would have an environment, a production-like environment (potentially with very limited production like capabilities), built that the executable can be deployed on. This would allow the build to be tested. That too in a production-like environment. This would also provide immediate feedback to the Ops teams on the behavior of the application in their environment and use that feedback to improve the environment. This also provides an opportunity for the Ops and Dev teams to align better. They will both have to use a single Sprint plan for releases of their Builds and Environments respectively and will provide feedback to both at the end of every Sprint, using which Dev can enhance their Apps to improve functionality and performance and Ops can enhance the environment for the same.
The Human factor
These principles are designed to foster Dev and Ops alignment from a teaming perspective, from a people perspective. These however do not replace the need for good old team building. Whether it is thru face to face get togethers or in todays distributed worlds, thru regular virtual meetings and online collaboration in real time. The best teams are the ones where the people know each other, trust each other, look out for each other and when there are challenges, know who to pick up the phone (or launch Skype) and talk to. This series on Adopting DevOps and my earlier series on Understanding DevOps will continue in future posts. My thoughts on #DevOps, Software #Architecture, #Agile Development, Innovation, Technology, Life…
