Devops isn't any single person's job. It's everyone's job.
Principal Product Manager, Jira Service Desk
Who's doing DevOps?
Chef is the company behind the Chef Automate platform for DevOps workflows. Tens of thousands of developers use Chef to test, automate, and manage infrastructure. At the forefront of the DevOps evolution, the Seattle-based company has released products like Chef, InSpec, Habitat, and Chef Automate to advance new ways of developing and shipping software and applications. To experiment with and refine its own internal DevOps practices, Chef relies on the Atlassian platform.
History of DevOps
The DevOps movement started to coalesce some time between 2007 and 2008, when IT operations and software development communities got vocal about what they felt was a fatal level of dysfunction in the industry.
They railed against the traditional software development model, which called for those who write code to be organizationally and functionally apart from those who deploy and support that code.
Developers and IT/Ops professionals had separate (and often competing) objectives, separate department leadership, separate key performance indicators by which they were judged, and often worked on separate floors or even separate buildings. The result was siloed teams concerned only with their own fiefdoms, long hours, botched releases, and unhappy customers. Surely there’s a better way, they said. So the two communities got together and started talking – with people like Patrick Dubois, Gene Kim, and John Willis driving the conversation.
What began in online forums and local meet-ups is now a major theme in the software zeitgeist, which is probably what brought you here! You and your team are feeling the pain caused by siloed teams and broken lines of communication within your company.
You’re using agile methodologies for planning and development, but still struggling to get that code out the door without a bunch of drama. You’ve probably heard a few things about DevOps and the seemingly magical effect it can have on teams: Nearly all (99%) of DevOps teams are confident about the success of their code that goes into production, in a survey of 500 DevOps practitioners conducted by Atlassian¹.
However, DevOps isn’t magic, and transformations don’t happen overnight. The good news is that you don’t have to wait for upper management to roll out a large-scale initiative. By understanding the value of DevOps and making small, incremental changes, your team can embark on the DevOps journey right away. Let’s look at each of these benefits in detail.
Compared to C-suite executives, DevOps practitioners “on the ground” are more likely to agree it is difficult to measure the impact of DevOps progress and success: 62% agree compared to 46% of C-suite executives.
Atlassian survey of DevOps practitioners
Collaboration and trust
We conducted a survey that found the number one factor of a DevOps team performing well is collaboration. Building a culture of shared responsibility, transparency, and faster feedback is the foundation of every high performing DevOps team. Collaboration and problem solving are ranked as the most important elements of a successful DevOps culture, according to our survey.
Teams that work in silos often don't adhere to the “systems thinking” DevOps espouses. “Systems thinking” is being aware of how your actions not only affect your team, but all the other teams involved in the release process. Lack of visibility and shared goals means lack of dependency planning, misaligned priorities, finger pointing, and “not our problem” mentality, resulting in slower velocity and substandard quality. DevOps is that change in mindset of looking at the development process holistically and breaking down the barrier between development and operations.
Release faster and work smarter
Speed is everything. Teams that practice DevOps release deliverables more frequently, with higher quality and stability.
A lack of automated test and review cycles slow the release to production, while poor incident response time kills velocity and team confidence. Disparate tools and processes increase operating costs, lead to context switching, and can slow down momentum. Yet with tools that drive automation and new processes, teams can increase productivity and release more frequently with fewer hiccups.
Accelerate time to resolution
The team with the fastest feedback loop is the team that thrives. Full transparency and seamless communication enable DevOps teams to minimize downtime and resolve issues faster.
If critical issues aren't resolved quickly, customer satisfaction tanks. Key issues slip through the cracks in the absence of open communication, resulting in increased tension and frustration among teams. Open communication helps development and operations teams swarm on issues, fix incidents, and unblock the release pipeline faster.
Better manage unplanned work
Unplanned work is a reality that every team faces–a reality that most often impacts team productivity. With established processes and clear prioritization, development and operations teams can better manage unplanned work while continuing to focus on planned work.
Transitioning and prioritizing unplanned work across different teams and systems is inefficient and distracts from work at hand. However, through raised visibility and proactive retrospection, teams can better anticipate and share unplanned work.
The CALMS Framework for DevOps
CALMS is a framework that assesses a company's ability to adopt DevOps processes, as well as a way of measuring success during a DevOps transformation. The acronym was coined by Jez Humble, co-author of “The DevOps Handbook,” and stands for:
The long-standing friction between development and operations teams is largely due to a lack of common ground. We believe that sharing responsibility and success goes a long way toward bridging that divide. Developers can win instant goodwill by helping to carry one of operations’ biggest burdens: the pager. DevOps is big on the idea that the same people who build an application should be involved in shipping and running it.
This doesn’t mean that you hire developers and simply expect them to be excellent operators as well. It means that developers and operators pair with each other in each phase of the application’s lifecycle.
Teams that embrace DevOps often have a rotating role whereby developers address issues caught by end users while, at the same, troubleshooting production problems. This person responds to urgent customer-reported issues, creating patches when necessary, and works through the backlog of customer-reported defects. The “developer on support” learns a lot about how the application is used in the wild. And by being highly available to the operations team, the development teams build trust and mutual respect.
As much as we wished that there was a magic wand to transform all teams into high-performing DevOps teams, DevOps transformations require a blend of practices, cultural philosophies, and tools. But like you’ve read, the benefits to breaking down the Development and Operations siloes are well worth it -- increased trust, faster software releases, more reliable deployments, and a better feedback loop between teams and customers.
Implementing DevOps is no small task. Yet given the right framework, effort, and tools, an organization can undergo a DevOps transformation that yields significant benefits.
Contact firstname.lastname@example.org for more details about the survey, conducted in partnership with Cite Research.