DevOps. Do you, don’t you, or do you merely _think_ you do because analysts tell you so?
At their Knowledge 18 conference this year ServiceNow announced that in the London release, the addition of an Enterprise DevOps focus, the ServiceNow SAFe 4.5 (Scaled Agile Framework) product and new Slack and Microsoft Teams integration to further improve developer collaboration. The later Madrid release will see additional integrations to Atlassian Jira, GIT (a source code repository) and Jenkins (a continuous software integration and automation tool).
With the accelerating pace of business, the whole concept of DevOps sounds like a magic bullet to getting things done. After all, removing all barriers to deploying your latest set of fixes or your whizz-bang new product can hardly be a bad thing. But, and there’s always a but, this is only true if it is done properly.
Bringing together your development and operations teams is fraught with challenges, and the unwary can stumble at many hurdles.
If you’re not already, you will need to re-organise your teams around a product/service-led model, as the whole premise of a DevOps culture revolves around single products as primary entities and necessitates a level of specialisation and familiarity with that product within the teams supporting it.
DevOps operates within a system of values. These tend to be known by their acronym CALMS:
By ensuring you have adequate coverage of each of these areas, you can ensure the safe and stable adoption of a DevOps workplace. Inadequate coverage? Well, DevOps then is nothing more than a car-crash!
- Culture is more important than tooling!
- Collaboration is key. Don’t isolate your developers from your testers and your operations staff. If you need to reorganise to remove any inter or intra team barriers then consider doing so.
- Don’t labour under the misapprehension that you need to build a new team to adopt DevOps. Keep the existing teams, and work on changing their mindset.
- Never, for one moment believe that DevOps is an excuse for eliminating your IT Operations staff or functions.
Culture – What culture does DevOps need to survive and thrive? Well, primarily the breaking down of barriers between your Development, QA, Operations and Governance teams. Rather than operating in traditional silos, DevOps demands a more collaborative approach.
Automation – means removing the human element from as much of the develop-test-deployment cycle as possible. If it’s possible to bring it down to a single button press, great. If it’s possible to bring it down to a fully automated task which runs continuously, even better.
Obviously, the levels of automation which can be applied will vary depending upon the system and architecture used, but the rule is to strive to automate everything.
Lean – This is a working practice that has been around for many years and is generally well understood. DevOps uses Lean practices to generate more value with fewer resources. It’s this practice which really helps to streamline the deployment pipeline and reduce errors and inefficiencies. If you’ve already adopted Lean practices in your organisation, then you’re already halfway there.
Measurement – What management practice would be complete without some form of metrics? Without realistic measurements, how do you know that you’re delivering more value than before? How can you tell when things have gone awry? Measurement is an essential part of DevOps and should be reviewed regularly. Act upon its findings to further tighten your processes where necessary.
Sharing – goes arm in glove with the culture aspect, and so brings us full-circle. Both ideas and problems should be shared openly between the teams involved. By openly sharing issues and collaborating on their resolution, team members learn to work better together outside of their normal function or comfort zone, and also helps to improve transparency.
Over the coming weeks, we’ll explore these key values and principles in more depth. We’ll look at what DevOps is good at, and what it is not so good at. How it fits into your existing Service Management framework (of whichever flavour), and the benefits it can deliver (and some of the challenges you might face along the way).
In the meantime, I’d welcome feedback from readers – do you do DevOps currently? How challenging did you find the transition? Given the above principles are you still convinced you do DevOps … or are you merely on the journey?
If you do DevOps currently have you found the marriage between Development and Operations to be all sweetness and light … or are divorce proceedings looming?