Adopting DevOps

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:

LogiGear_Chart 3_Adopting DevOps

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.

LogiGear_Adoptiting DevOps 2

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…

Sanjeev Sharma

Sanjeev is an IBM Distinguished Engineer, and the CTO for DevOps Technical Sales and Adoption at IBM, leading the DevOps practice across IBM. Sanjeev is responsible for leading the worldwide technicalsales community for DevOps offerings across IBM’s portfolio of tools and services, working with IBM’s customers to develop DevOps solution architectures for these offerings, and for driving DevOps doption. He speaks regularly at conferences and has developed DevOps IP, including the DevOps For Dummies book published in 2013.

Sanjeev is a 20 year veteran of the software industry. Sanjeev has an Electrical Engineering degree from The National Institute of Technology, Kurukshetra, India and a Masters in Computer Science from Villanova University, United States. He is passionate about his family, travel, reading, Science Fiction movies and Airline Miles. He blogs about DevOps at http://bit.ly/sdarchitect and tweets as @sd_architect.

Sanjeev Sharma
Sanjeev is an IBM Distinguished Engineer, and the CTO for DevOps Technical Sales and Adoption at IBM, leading the DevOps practice across IBM. Sanjeev is responsible for leading the worldwide technical sales community for DevOps offerings across IBM’s portfolio of tools and services, working with IBM’s customers to develop DevOps solution architectures for these offerings, and for driving DevOps adoption. He speaks regularly at conferences and has developed DevOps IP, including the DevOps For Dummies book published in 2013.

Sanjeev is a 20 year veteran of the software industry. Sanjeev has an Electrical Engineering degree from The National Institute of Technology, Kurukshetra, India and a Masters in Computer Science from Villanova University, United States. He is passionate about his family, travel, reading, Science Fiction movies and Airline Miles. He blogs about DevOps at http://bit.ly/sdarchitect and tweets as @sd_architect

The Related Post

The book is an incredibly effective and valuable guide that details the risks that arise when deploying cloud solutions. More importantly, it provides details on how to test cloud services, to ensure that the proposed cloud service will work as described. It is a great start to the topic. The 6 chapters detail a paradigm ...
DevOps may be the next big buzzword, but Test teams really need to focus on its little sister, Continuous Delivery If you pay attention to trends in software development—from the perspective of what some sophisticated teams are doing, what articles and books are being written, to conference topics, you may have noticed the tools being ...
LogiGear Magazine June Issue 2020: Transform Your SDLC With Continuous Testing
Cloud computing has been the buzzword in the world of Information Technology for quite some time and it is likely to retain that status in the coming years. Cloud computing has been helping business enterprises deliver services faster and cheaper compared to all other existing delivery models. Small and medium business enterprises have changed their ...
In this article, I share some of my experiences and observations on training teams, mainly in corporate settings. The operative word here is “team”, not “individual”. When training teams or groups in an organization, many of the considerations and benefits are different than those for the individual. We’ll examine those differences and I will share successful solutions. ...
By Jez Humble and David Farley Continuous Delivery from Jez Humble and David Farley is an important contribution to the field of software development. It takes continuous integration to the logical conclusion and covers how to set up a continuous integration system, delving into everything from check-in to delivery to production. It doesn’t state you ...
…On what you need to know before making the transition to EaaS 1. What are the main differences between cloud-based environments and cloud infrastructure? An environment is a collection of infrastructure elements working in conjunction to enable an application stack to work. For example, a simple 3-tier application, with a web front-end component, a business logic ...
LogiGear Magazine June Testing in Continuous Delivery Issue 2017
Over the years we’ve provided an extensive number of articles, videos, and infographics that provide a wealth of knowledge about Continuous Delivery.
If you haven’t already caught a glimpse, we announced in January the Testing in DevOps and Continuous Testing videos series, available on YouTube!
It’s no secret that the cloud is growing at an exponential rate. By 2016, two-thirds of the world’s server workloads will exist in the cloud. But according to Cisco’s 2012 Cloud Index, less than half of server workloads currently run in the cloud. Closing the gap between current capabilities and future requirements is a mission-critical ...
Do you want to speed up your automated tests by a factor of 10 and deploy your application continuously? In this article we share how the JIRA development team at Atlassian has accomplished this using Stages in Bamboo. Stages have allowed the JIRA Development team to take a week’s worth of testing and condense it ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe