This was first published on January 15, 2015
Beginning: I attended a session recently on “DevOps:The Big Picture”, Thank you Richard Seroter for such a simple and visual breakdown, which got me thinking; Can we really be able to align our current way of working ( mostly in silos) in terms of Development and Operations, in such a way to become what is being called as DEVOPS? Can we really implement this concept and gain from the common synergies without starting from the scratch?
Traditionally: IT function in most large firms has been comfortable following the traditional model and are mostly averse to speeding up functional delivery in contrast to the need by business stakeholders whose aim is to stay competitive & ensure the growing customer demand is met quickly. Remember that Waterfall versus Agile discussions, in fact in my opinion, we are still following a hybrid form of Waterfall methodology, like mini waterfalls or shorter cycles using agile and scrum runs. Interestingly, I found it’s already called as W-agile.
We all know how the quarterly or major release cycle works. Deploying a set of new features along with a few defect fixes in the old fashioned way, in a structured format of following from requirement gathering and analysis to coding, deploying and testing across multiple environments, running around for signoffs, with rollback strategy (showing our confidence) and finally a successful release with a few hiccups. Take a deep breath, rest a little and get ready for the new cycle, we repeat again, reason being; why change the process which has worked very nicely over the years, we are delivering right?
Developers have to wade through the exhaustive documentation prepared by the Analysts to break down the requirements even for few bug fixes or adding a minor feature, and then run through the hoops to get it deployed in multiple test environments, get it tested and attested by multiple teams, before getting the go ahead to push it in production. Every team you speak to say’s this lengthy flow reduces risk and impact on production environment, the real reason being maybe that no one wants to take the blame and end up paying the price for mistakes. Ultimately the perception persists that the turnaround time is far too much when compared to the features added.
Operations are skeptical about all change to Production environment, as they have been tasked with stability and maximum availability. Remember that old adage, “If it ain’t broke, don’t fix it.”
Having moved from the DEV to the OPS side, I can most assuredly vouch that all changes are viewed suspiciously to say the least, as mostly these guys are never part of the discussions nor are aware of what the release encompasses functionally. The minimal automation, environment differences, deployment experience, along with security policies around accesses, builds up more friction, when the blame is put on the artifacts provided or differences overlooked during the testing. A release in itself creates so much stress across all teams, especially when the deployment breaks and a fire drill ensures to either fix it or roll back to the previous state within the change window. In order to minimize experiencing that stress, they create stricter controls, and reduced number of deployment windows.
DEVOPS: Combining a right mix of interdependent variables like People, Process and tools for fast and quality software delivery. So, can we align ourselves with this concept? Yes We Can! (Sounds clichéd and overused but in this case it is true) We start with breaking the Berlin wall, demolishing the divide between the DEV and OPS teams, SILO should be the next 4 letter word!
Let’s summarize a few important components which we should focus on to promote collaboration.
People: First on the list are the People. Create or identify and distribute teams for each W-agile sprint, this team would comprise of analysts, coders, delpoyers, testers and leads from both Dev and the Ops as required, with minimal redundancy. A team, very much doing all the things from start to finish, ideally having a common Management oversight to enable adoption of this result oriented approach. We need to merge or recreate the teams in such a way that synergies are beneficially used, kind of make a lean and mean team focused solely on the time bound task for the full cycle with shared responsibility.
Please read the rest of the article here..https://askhurram.com/?cat=4