The path to DevOps success

  • Posted on June 23, 2015

In my last post, I talked about how DevOps can benefit everyone by instilling discipline that can help to improve most IT projects.  But, DevOps is a destination and a way of working, and one that requires mastery of other fundamental Application Lifecycle Management (ALM) disciplines before you can achieve and exploit it.

There are many underlying disciplines that support DevOps, but we’ve identified four that we believe are critical to DevOps success:

  1. Software Craftsmanship
  2. Strong Configuration Management
  3. Automation
  4. Agile


Software Craftsmanship

High-quality programming underpins everything.  If you can’t make changes without breaking code, then the journey stops there.

Software Craftsmanship means paying more attention to the quality of the code and the quality of testing.  Use the available tooling for metrics and analytics to improve code quality and the quality of incremental releases.

This can be harder than it sounds. Not only must you adopt professional software development disciplines, you must also use them at an ever increasing pace.  Fast turnaround of releases or defect fixes requires absolute mastery of the development process.

The confidence that is required for organisations to support a continuous delivery process can be catastrophically undermined by just one bad experience, and can cause a return to the old habit of using time as a buffer to protect the stability of the production environment.

Success is also dependant on treating non-functional and operational requirements with as much care as you treat functional requirements.  Exception messages that only operation teams will see should be as well-crafted as published content end-users will see.

Strong Configuration Management

Good source code version control is one thing, but you need to put in place a robust model for configuration management for your application. This covers source code, but also includes configuration files, designs, test and deployment scripts and a workable feature release model such as branching and merging or feature switches.

A well-defined and fully implemented approach for configuration management needs to be in place in order to enable the next step: automation.

Building in Automation 

Only automation can achieve the speed of turnarounds that DevOps requires for success.

Automation is incremental and can be added to your development and run processes over time.  Solid routines should be established before they are automated to ensure they are effective.

The limit of automation has not yet been found and organizations continue to innovate on aspects of their delivery that can be automated.  Indeed, ‘automate everything’ is a popular DevOps mantra.

Deployment is an obvious area for automation, but it should be supported by additional automated release management processes such as automated testing and automated quality gate verification.

Automation of operational processes such as environment provisioning, patching and security screening should also be considered.

Mass automation and the ability to automatically move releases through development and test environments and then automatically into production ultimately requires confidence in the process.  This confidence will generally come over time, but starting small and making incremental improvements is the best way to build it.

The Connection to Agile 

Agile isn’t a prerequisite to start doing DevOps but it is required to enable the high-performance capabilities that DevOps can provide. All of the disciplines that support DevOps are Agile principles and DevOps can be viewed as an evolution of these principles.

Only Agile can support the fast turnaround times for development and the backlog approach that nurtures future investment and innovation.

Furthermore, and it may seem obvious, the Agile transformation needs to progress beyond the development team.  The operations team also needs to be Agile to support DevOps, and in fact, the entire organisation needs to be Agile to be able to realise the benefits that the increased speed can offer.

This is root to branch Agile transformation, and for most organisations it represents a culture shift.  The greatest challenge in adopting DevOps, in our view, is to manage that transformation and shepherd the change.

If this seems like a hill to climb, then good news is on the way.  In my next post, I’ll talk about how organizations can use partners like Avanade as a DevOps Accelerator.

This blog post is part of a series about DevOps by author David Jobling. Check back to read the latest installment.



DevOps Consult

Thanks for sharing this- good Information! Keep up the great work, we look forward to reading more from you in the future!

March 8, 2017

David Jobling

Thanks!  Post is nearly 2 years old but happy it still remains relevant.  Even with the advances we’ve seen in the technology, people are still the key to success.

March 9, 2017

David Jobling

Tom, I would totally agree.  Speaking as a developer, access to scrubbed live data is quite invaluable.  I’d challenge anyone to write code that doesn’t need to be fixed at least once when exposed to real-world data; and the sooner those issues are found and fixed the less disruption there will be.  

I would definitely emphasis the scrubbing part of this model though.  Security of customer data is of paramount importance and making data more portable also makes it easier to lose or steal.  

Microsoft’s suite of Azure developer tools go even further and allow developers to debug Intelitrace logs from production or even connect to a production instance and do live debugging.  Both very useful where even scrubbed data isn’t enough to track down that bug.

July 17, 2015

Tom Foremski

App testing is key because bugs c aught earlier are hundreds of times less expensive to fix than later. But you need to test apps against real data and this is where devops disciplines can really accelerate apps delivery. But the provisioning and data masking bottleneck keeps most dev teams stuck in slow-motion no matter which disciplines or workflows they choose. Make one clone of the production database and let several apps teams use it as if they were the only ones, data as a service works really well when you virtualize the database. Provisioning is in minutes and with self-service interfaces the automation can be triggered by the development teams leaving ops to work on other projects. It seems to me that a virtual database concept should be at the heart of devops since it clearly addresses the two main pain-points that Gene Kim talks about: IT provisioning; and setting up test and QA environments. These can be fixed quickly with a virtual database: make one copy instead of multiple copies, and data mask-once, then copy many. We can cross those constraints out today if we use a virtual database and easy to run IT automation tools such as those from Delphix and move onto solving the other constraints on Gene Kim's list.

July 7, 2015

Techs and Specs Newsletter

Stay up to date with our latest news.

Share this page