Continuous Delivery for Legacy/Heritage Systems – LondonCD meetup June 2017

This is part 3 of a 4-part series of articles based on discussions at the LondonCD meetup group on 12 June 2017. The other posts are linked at the end of this article.

Applying the principles and practices of Continuous Delivery for new software is fairly straightforward (at least, until you deal with data and databases). However, existing “legacy” systems that were built without many automated tests and without much concern for repeatable deployments of discrete functionality pose a challenge for moving to Continuous Delivery.

Office Lens 20170612-205923

Continue reading

Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Summary:  Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.

I captured my notes as slides:

Update: the video of Pete’s talk is here on Vimeo:

Pete Mounce video frame

There were several specific points made by Pete that were interesting for me:

Continue reading

Operability: a DevOps cornerstone – new eBook from HighOps

HighOps operability eBook - coverOne of the driving forces behind DevOps is the increasing prevalence of complex, distributed software systems which calls for a substantially different approach to building ‘business’ software systems: an approach that anticipates and expects failures, transient behaviour, emergent states, and unpredictability; and ensures that failure responses are gradual, graceful, and graphable.

‘Making software work well’ in this dynamic, interconnected world is the focus of Software Operability, a subject I have been writing and speaking about for some time.

I recently began working with IT operations experts HighOps (@gotHighOps) and we have published a free eBook Operability: a DevOps Cornerstone. The book covers the fundamentals of operability, why it’s relevant, how to build and sustain a focus on operability,and how operability relates to both DevOps and IT service management approaches such as ITIL.

If you lead the Technology division, head up a software development department or IT operations department, or lead a development or operations team, and want to understand why and how to make your software systems work better, then this book is for you. If you are involved in Service Transition or Service Operation, this eBook will help you to make the case for a strong focus on the operational aspects of the software being delivered. Similarly, if your role is a Software Architect, you will find here sound practical guidance for improving how your software works
in Production.

Download the HighOps eBook ‘Operability: a DevOps Cornerstone’ here.

DevOps Questions from Unicom DevOps Summit Feb 2014

At the Unicom DevOps Summit event in London on February 28th 2014 we experimented with some extra audience/attendee participation by asking for questions on record cards and encouraged people to ‘dot-vote‘ on the questions most interesting to them. There were some good questions, but unfortunately we did not get chance to discuss many of them, so here are all the questions from the card board, along with some very brief attempts at answers.

  • Should security be a part of DevOps?
  • To what extent and how do you insist on standardisation for multiple Scrum + ‘DevOps’ teams with no separate Operations team?
  • What’s the likely process flow of / disruptions to / duration of DevOps adoption?
  • Where does ‘Operations’ sit in the ITIL model? All over the place? e.g. Service Transition?
  • How about some example scenarios? Tangible comparison points would be useful.
  • Where does DevOps start and finish (from a process perspective)?
  • Is DevOps just a job title?
  • Is co-location of resource necessary for successful DevOps?
  • How essential is cloud technology to DevOps?
  • How will the announcement that ThoughtWorks are ‘open sourcing’ their Go DevOps product affect other vendor products? Why pay for other products?
  • There are a lot of open source DevOps/release/orchestration tools – is anyone using (or know about) the Windows equivalent?
  • How do you overcome developer resistance to writing Run Book docs? Are the processes to drive adoption? Is it a sackable offence?

Continue reading

What Team Structure is Right for DevOps to Flourish?

A new version of these DevOps team topologies is now here: devopstopologies.com

The new version has many new topologies that we’ve encountered in the wild and we’re taking pull requests on Github for additions and changes.

The primary goal of any DevOps setup within an organisation is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management; this means that different organisations might need different team structures in order for effective Dev and Ops collaboration to take place.

So what team structure is right for DevOps to flourish? Clearly, there is no magic conformation or team topology which will suit every organisation. However, it is useful to characterise a small number of different models for team structures, some of which suit certain organisations better than others. By exploring the strengths and weaknesses of these team structures (or ‘topologies’), we can identify the team structure which might work best for DevOps practices in our own organisations, taking into account Conway’s Law.

Continue reading

Operability can Improve if Developers Write a Draft Run Book

Software Operability

The run book (or system operation manual) is traditionally written by the IT operations (Ops) team after software development is considered complete. However, this typically leads to operability problems being discovered with the software, operational concerns having been ignored, forgotten, or not fully addressed by the development (Dev) team. If the software development team writes a draft run book or draft operation manual, many of the operational problems typically found during pre-live system readiness testing can be caught and corrected much earlier. Because the development team needs to collaborate with the operations team in order to define and complete the various draft run book details, the operations team also gains early insight into the new software. Channels of communication, trust, and collaboration are established between the traditionally siloed Dev and Ops teams, which can help to establish and strengthen a DevOps approach to building and running software systems.

I…

View original post 1,295 more words

Roundup: Patterns for Performance and Operability

Patterns for Performance and OperabilityI recently posted a review of Patterns for Performance and Operability by Ford et al on the SoftwareOperability website. I think that this book is exceptionally useful in its treatment of both performance and operability, and anyone who cares about how well software works in Production should buy and read a copy (there are paper and eBook editions).

Two other reviews might be useful too: my colleague Anant East (Head of Architecture and Infrastructure, thetrainline.com) wrote up a detailed review of Patterns for Performance and Operability on the tech blog at thetrainline.com, and I posted a short review on Amazon.