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

Having the right skills and experience, even if you have to go outside, is essential for designing tests for large-scale cloud deployments. Moving existing applications to a cloud environment adds new dimensions to testing. One of the primary reasons for moving to the cloud is scalability. Capacity to handle traffic and data transfer can be ...
LogiGear Magazine June Issue 2020: Transform Your SDLC With Continuous Testing
Throw away clunky hyper-visors, and stop thinking about computer hardware and software license during your development projects. The first thing you think about when you hear “The Cloud” may not be development and testing. The Cloudy market is filled with SaaS applications, hosting, and cloud-based file systems. All are very useful, and offer a clear ...
Making the leap to CT is easier than you think— follow this guide to transform your testing process No pain, no gain! Achieving Continuous Testing shouldn’t take a “Hans and Franz” attitude. It should be painless, more like a natural progression from implementing certain practices over time.
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 ...
Special considerations that should be applied to an application running in the cloud. Over the last weeks, I have found myself in several rather intense discussions about “cloud testing”: what it is, what it isn’t, and what it means for testing and QA professionals. The major source of confusion in these discussions usually revolves around ...
Fitting QA into a modern DevOps group In a traditional software engineering organization, the QA group is often seen as separate from the Development group. Developers and testers have different roles, different responsibilities, different job descriptions, and different management. They are two distinct entities. However, for folks outside the engineering team – say in Operations ...
It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps–not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor, ...
From the culture shift, to differences in Agile, Dave Farley and Michael Hackett discuss the nitty gritty of Testing in DevOps. For this issue of LogiGear Magazine, our very own Michael Hackett sat down with one of the godfathers of Continuous Delivery, David Farley. In this exclusive interview, David discusses how test teams and automation ...
Introduction Everything changes. It’s the only constant. The landscape of software testing is undergoing a fast and dramatic change driven by societal, business and technology changes that have placed software everywhere. Computing is ubiquitous. There is hardly anything today that doesn’t contain a CPU or information transmission capability, with software to drive it. From smart toasters ...
LogiGear Magazine June Issue 2018: TESTING in DEVOPS
For this month’s book review, I read Continuous Testing for DevOps Professionals: A Practical Guide from Industry Experts, by various authors and edited by Eran Kinsbruner. The book is divided into 4 sections: Fundamentals of Continuous Testing, Continuous Testing for Web Apps, Continuous Testing for Mobile Apps, and The Future of Continuous Testing. The Fundamentals ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe