Deploy all Things with DevOps
by Karl Schwirz and Michael Hodgdon
Any software professional will tell you that shipping code is hard work. Far too many organizations focus solely on how long it will take to build an application, while completely ignoring what happens after the product has been written. And by the time organizations realize that they should have focused on deployment, testing, and quality assurance, it’s already too late. Getting applications back on track is far more costly than doing it right from the start.
Has your organization fallen into this common trap? Ask yourself:
- Do your users typically tell you when you have defects or outages before your systems alert you of the incident?
- Does a software rollback cause panic across your entire organization, and often put everything else on hold?
- Are your developers spending exorbitant amounts of time merging code at the end of software integration cycles?
- Does the lack of visibility into your production systems prevent your teams from solving problems in real-time?
- Does getting a code change (e.g. bug, new feature, hotfix) require days or months for production deployments?
If you answered yes to one or more of these questions, chances are your teams aren’t reaching their potential. The key to building and maintaining applications in a way that integrates all functions of the software delivery process is known as DevOps.
Demystifying DevOps, in three parts
In this three-part series, we’ll demystify DevOps, provide recommendations for how to introduce DevOps techniques into your organization, and discuss the technology and organizational changes necessary to succeed — resulting in increased reliability and quality in your overall software development process. Over the course of this series we will demonstrate how you can use DevOps to:
- increase collaboration
- increase visibility into your development process
- seamlessly roll out changes to production daily or weekly
- introduce the highest level of quality possible into your software solutions
So, what is DevOps exactly?
The term DevOps is used interchangeably to describe a lot of different things. Our friends at Wikipedia provide the following definition: “The method [DevOps] acknowledges the interdependence of software development, quality assurance, and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance.”
Wait, huh? That jumped pretty quickly from “interdependence” to “improving operational performance.” There has to be more, right? In fact, there is. When our customers ask what DevOps means, we typically explain it like this:
It’s about your people.
- Culture: Own the change to drive collaboration and communication.
- Lean: Use lean principles to enable faster cycle time and feedback loops.
Use tools that help you move faster and gain insight.
- Automation: Take the manual steps out of your value chain.
- Monitoring: Measure everything and use data to refine cycles.
Use these insights to work smarter.
- Sharing: Share experiences to enable others to learn and improve.
- Improve work: Teams are more proactive in refining their software development process.
DevOps in the wild (and a 95% jump in velocity)
Let’s make this real by looking at how we’ve introduced these topics with one of our long-term clients.
They were building a massive data-collection application that ingested streams of information from employee devices and served by a website filled with custom-built dashboards and data discovery tools. It was a high-profile effort that was well-funded and resourced. We were brought in because, despite being set up for success, progress was slow and stakeholders were getting quite nervous.
Team resourcing didn’t appear to be the problem. The team of 12 — including web developers, software architects, data specialists, quality assurance leads, user experience designers, and business analysts — seemed to have enough depth to keep things moving. So, we started by taking a hard look at how they were measuring progress. After examining their story backlog and burn down, we calculated that they were operating at about 30% of capacity. The team was picking small batches of work, and passing it through the stages of completion: First developers would write some code, then QA would test it, then it was deployed, and on to the next. In other words, only one group was really working at a given time while the rest were sitting idle.
We told them: You can’t just throw people at the problem; you must change how the solution to the problem is executed.
Prior to our engagement, the team had several really bad releases that caused major internal political storms. The issues stemmed from conflicts during code merges, so the team reacted by slowing down to ensure quality. As time elapsed, morale waned and people burned out, and it became apparent that this strategy wasn’t going to result in building quality software AND delivering at a timely pace.
By the time we completed our assessment and action plan, they were back on schedule and delivering features on time with a 95% increase in velocity. We had shifted how they approached their build out and enabled their teams to take control of the delivery process.
By the time we completed our assessment and action plan, they were back on schedule, delivering features on time with a 95% increase in velocity.
So, how did we achieve these results?
We introduced a build and deployment strategy that allowed the team members to work together and in sync. Before, they’d slow down time-to-production to ensure a degree of better quality. However, as our friends at New Relic remind us, “You don’t have to choose stability versus new features.” We introduced the ability for anybody to create any version of the software in a new environment at the click of a button. This laid the foundation for the team to become more productive and increase stability. Over time, more and more efficiencies were added as they worked together to further mature their process.
Originally published at www.slalom.com