Inside DevOps: How it really works
DevOps done well can lead to a continuous loop where teams plan, code, build, test, release, deploy, operate and monitor
People talk an awful lot of about DevOps. This now "industry standard" term has been used (and, some would argue, abused) by just about every IT supplier out there, every one of which appears to want a slice of the DevOps pie. As a portmanteau of developer and operations, DevOps is intended to express a unification of the two disciplines such that they should forge a new and more considerate approach for each other.
But despite its straightforward core rationale, the industry has chosen to overeat on DevOps and purists would argue that the resulting indigestion is dragging down the agile development methodologies that DevOps itself champions. DevOps done right can lead to an infinitely virtuous loop where teams plan, code, build, test, release, deploy, operate and then monitor – and then plan again, and so on.
Management and orchestration software companies are fond of using the new DevOps label, but software automation controls – however sophisticated – only explain part of the story. IT leaders need to look inside a real development environment to see how DevOps works. During its Build 2015 conference and exhibition, Microsoft hosted a session entitled "DevOps as a strategy for business agility". Presented by Ed Blankenship, Microsoft product manager for Visual Studio Online, ALM and DevOps, the real mechanics of DevOps were shown in a way that goes beyond the headlines and industry spin.
Two lifecycles, with different DNA
This was the first time Microsoft had scheduled a session like this. Blankenship used it to explain that after the first decade of agile (the agile manifesto was laid down in February 2001) IT departments can now say with some confidence that the software application development lifecycle and the operations management lifecycle are essentially different. In 2015, as we move into the second decade of agile, it is time to bring the two together – and the foundation for DevOps is therefore validated.
"The need for DevOps is driven by the fact that markets move fast, so software development needs to deliver more quickly if firms are to stay profitable," says Blankenship. During his presentation, he cited examples of DevOps done right inside web-native firms such as Netflix, Amazon and Facebook, all of which appear to be able to show evidence of continual delivery with a functioning DevOps foundation beneath.
Bad DevOps, on the other hand, leads to frustration, delays and a lack of insight into why there is poor cohesion in the first place. This means that teams end up building the wrong thing.
There is a big consequence arising from this inefficiency. Microsoft claims that on average it takes 200 minutes to diagnose and repair a production issue, and that the average cost of infrastructure failure is $100,000 per hour.
Visual Studio becomes agile
Microsoft admits that this, largely, is how it used to work. "We did ask for feedback, but only after each milestone, so we weren't really good at responding and reacting," explains Blankenship. The firm used to work through its well-known Alpha, Beta, Release Candidate and Release To Manufacturing cycle for pretty much all software releases. But today, Visual Studio Online has moved to a three-week release cadence. These 'sprints' are aligned to goal points supported by DevOps where software is "potentially releasable", but not always necessarily released. The function and control is there to achieve the agile cycles, even if maximum agile agility is not always realised.
But DevOps should always be about people first and processes second, says Blankenship. The focus should be on empowering teams with tools they need to be able to get software to users when they need it and how they need it. "The first part of that is often about hypothesis-driven planning so that you can examine what might be possible," he says.
Microsoft's core Visual Studio Online Integrated Development Environment (IDE) works with the firm's own Team Foundation Server (TFS) source code management tool to provide requirements management, project management and build process management with collaboration and reporting functions. This is what DevOps actually is – application lifecycle management tools that straddle both the developer and operations sides of the wall.
Today, IT leaders know that teams have the ability to create Visual Studio extensions so that partners, customers and users of all kinds can add their own functionality and abilities into Microsoft software. So, for example, an extension might tailor software development tools to the exact needs of the development shop so that custom data is presented to the DevOps players. It is, if you like, a user interface within a user interface – for example, functionality inside Visual Studio itself – and this could be something as simple as a calendaring facility, or something more complex.
What does 'done' mean to you?
Microsoft says it has also been focused on helping teams to work better with Kanban boards with Visual Studio. "If you look at the way each team defines its own definition of what 'done' means, then this kind of extra richness needs to be built into tools. This kind of configuration should exist for each individual team at the team level, and Visual Studio now has this," says Blankenship.
Staying inside DevOps, after planning an IT project progresses to the develop and test phase. From an IT manager's perspective, the IT teams needs to identify who the subject matter expert is to resolve each stage of development in DevOps. CodeLens in Visual Studio is the function in VS2015 that allows users to do this. Then there is the IntelliTest function that goes out to test individual code methods, which is used to help discover the minimal amount of tests needed. Once again, this is real DevOps, this is not simply a software company telling you that they have a DevOps division and it's all shiny and lovely.
"Sometimes you need more automated testing, but sometimes you just need another set of human eyes," says Blankenship. "A 'pull request' system helps manage peer reviews and keeps track of multiple commits and helps to manage merges and conflicts where needed. All of which helps increase the quality of code that is being pushed through into production."
Microsoft has come under fire for its realignment towards open computing principles. But the firm's Visual Studio Community Edition is providing these tools for free for enterprise-level software development. DevOps done right is meant to reduce and hopefully eradicate so-called technical debt – the problems that still exist inside software that need to be resolved. These are the kinds of tools that will make this happen so that software can get through user acceptance testing and be able to ship more quickly.
Al Hilwa, programme director for software development research at IDC, says: "DevOps is now an established organisational aspiration encompassing not just real IT practices and supplier tools that support workflows, but also collaborative values that hope to inject agility and productivity in enterprises.
"The pains of taking software to production and encountering inconsistent configurations and errors are real. Organisations need their developer tools to play an active role in supporting the resolution and mitigation of these problems. In this light, it makes perfect sense for Microsoft, as it is a leader in developer tools, to integrate and support DevOps workflows in its software," adds Hilwa.
DevOps is automating many of the manual steps that we used to consider as very standard parts of the job of building software. But if you get a DevOps-flavoured pitch from a consultant or supplier of any shape that doesn't mention definable metrics, call stack analysis and the ability to use microservices to finesse definable tasks and jobs, then walk away quietly.
