DevOps Practices – w.c. 19.08.19

The last few weeks have seen us really kick off the DevOps practices alpha in earnest. The three areas where we have focused on are:
– engaging with teams regarding their existing practices,
– thinking about measures of success, and
– planning for our next steps.

Since we kicked off the alpha last week we have been focusing on this hypothesis:
“Adopting a consistent approach to containerisation will make it easier and more efficient to develop, test and (re)deploy services”.

Existing practices

Last week we ran a workshop with people from the API-Factory, infrastructure, security, and applications teams, focused on the current practices of the API-Factory team. Although sadly I had to miss it, this was a great chance for teams that do not normally discuss the details of their work together to start having these kinds of conversations.

Although these conversations aren’t a direct, measurable output of the DevOps practices work they are what creating a DevOps culture really is all about. Cate described it as one of the best meetings she’s been in since joining Hackney!

We also had an interesting chat with colleagues in Data & Insight team who are using containers but in a very different way to the API-Factory team. One of the things that we are mindful of is to test an approach that is flexible enough for different teams with different needs but still creates consistency and predictability where it can.

Measures of success

JJ, who is with us from Digi2al working on this DevOps practices alpha phase, has spent a lot of time in the last couple of weeks thinking about how we can measure the success of whatever we try. This will mean that rather than having a hunch that our new approach is better we can actually point to some evidence.

To start the process of identifying measures of success we looked at ‘Accelerate: The Science of Lean Software and Devops’ by Nicole Forsgren and Jez Humble. We took their four key measures as our starting point: Lead Time, Deployment Frequency, Mean Time to Restore (MTTR) and Change Fail Percentage.

We have started engaging with various teams across HackIT, as well as suppliers, to see if we can get baseline data for these before we start testing anything. One of the things that we have identified is that we are not currently collecting data on some of the measures above. This gives us an opportunity in our test to start collecting these useful insights, as well as recommendations to make regardless of the success of our test.

Next steps

This week we have a busy week on the DevOps front.

On Wednesday we are holding a workshop with teams from across HackIT to design the deployment path we will use to test our hypothesis. This will build on the existing deployment path that API-Factory is using but take into account that it might not be the best fit for everything.

On Thursday we have the GOV.UK PaaS team coming in to give HackIT a show and tell on their product and then do a deep dive after with people from across HackIT’s development and infrastructure teams.

+ posts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.