The DevOps movement has changed how software is built and released by injecting automation and best practices into the veins of the software development lifecycle (SDLC) in a way that has substantially reduced the time and effort required to build and deploy software.
In fact, two-thirds (66%) of respondents to a recent survey from Atlassian credit DevOps with helping them produce better quality software.
However, exactly how best DevOps practices are implemented still varies widely from one organization to another. In theory, there is a logical flow, dubbed the DevOps loop, that spans everything from the planning stages all the way to release. In practice, the DevOps loop is rarely followed in a precise manner, said Mitch Ashley, a chief technology adviser for the Futurum Group during an Ignite Talk held at an AppDev Field Day hosted by Tech Field Day, an arm of Futurum.
“The problem is we took the same set of steps that we had in waterfall, and we laid it out in a loop,” says Ashley. “The DevOps loop is not how software gets built. This is fake news.”
Instead, DevOps defines a methodology for collaboration and teamwork based on a set of tools and practices that connect two long-estranged departments of software development and IT operations. The challenge is the DevOps loop does not address any of the real-life frictions involved in moving software artifacts through a pipeline, says Ashley.
“DevOps is really about looking at how we build software and think about how we automate more steps, but more importantly, how we take that idea of making smaller units of work and delivering parts of it so that people can work independently instead of everything showing up at once causing one big set of problems instead of work,” says Ashley. “It’s more like a multiverse than it is a loop.”
Sprint Methodology
The sprint methodology at the core of any DevOps workflow solves this problem by breaking down projects into short, repeatable units that can be finished in short sprints or iterations, typically lasting two to four weeks.
Teams, at the beginning of the journey, determine the number of sprints required to complete a project. Bite-size chunks of work are then assigned to team members, each responsible for a separate deliverable.
The approach lets members work separately at varying paces implementing the DevOps loop into each of their workflows. Developers can incorporate feedback and respond to changes faster. Additionally, better support can be provided by guiding users through their journey and retiring all end-of-life activities on time.
“In practice, DevOps is distributed development, whether it is distributed geographically, or work is distributed amongst people. All of them work on their parts at different paces. It’s a continuous integration process that’s running all the time.”
A valuable benefit of this is individual interaction takes precedence over tools and processes. As lengthy projects are broken down into smaller segments and distributed across teams, professionals with varying skill sets working from different time zones can collaborate and work congruently to build something bigger.
“Eventually all of them get combined to be released into production and then deployed to test and development environments.”
The concept of DevOps is meant to provide a foundation on which different IT personas can work individually, yet collaboratively, irrespective of the tools they use, or the work they do, while maintaining alignment and velocity. It is how project managers, developers, stakeholders and customers can all be part of the loop.
“The truth of it is we are empowering people to do work at the same time and work a lot of it at their own pace with their own skill set,” says Ashley. “The timing of release is about getting it to come together.”
