Smoothing the continuous delivery path – a tale of two teams - Lyndsay Prewer

Editor's Notes

• #2: Introduce myself (lyndsayp Ltd and EE) Roles Over 30 teams working within a Scala microservices architecture, releasing into Production multiple times per day This session is an experience report of the best practices and pain points of two teams that both practice Continous Delivery. Establish: - what roles are present - how many deliver to web Show of hands - production deployment capability: one or more per year, per quarter, per month, per week, per day
• #3: Two very different teams Government Scala microservices Private sector .Net Monolith Both teams are doing a great job of getting their doughnuts (of differing sizes and shapes) out to Production. This is an experience report will compare and contrast What best practices help these team go faster, faster What areas of pain slow them down
• #4: Emphasise: Fast feedback Risk reduction
• #5: Valuable software in short cycles reliably released at any time Fast feedback - shortest time from concept to cash Risk reduction - smallest value possible
• #7: Whilst preparing this session, I read a fascinating blog post on how another highly successful company, called targetprocess, has evolved over the last 90 months. The article describes, in gory detail, their journey over the last 7 years, through various agile best practices. Over the last three years they’ve improved their delivery frequency, but still have some way to go. They’ve made lots of improvements in other areas though. The article reminds us that when improving one’s Continuous Delivery, it’s important not to do so at the expense of other practices. The overarching goal has to be Continuous Improvement, not Continuous Delivery.
• #10: HMRC Digital (Public sector) Gov.uk tax interfaces for citizens and businesses (70% of all gov transactions, > 1 billion transactions online) Traffic varies across the year, with peaks at key tax calendar events 30+ Product Teams Tech Stack Scala Microservices Docker Mongo DB Deployment frequency You build it, you run it - Amazon CTO Werner Vogels
• #12: CI that works Culture - Mind share
• #13: CI that works - knowing what to automate - a story about .Net Monolith
• #14: Cross functional teams Picture of team mix Picture of testing all the time Story about E
• #15: Cross functional teams Picture of team mix Picture of testing all the time
• #16: The test automation pyramid API and/or integration tests
• #17: Picture different test mixes Common automated testing problems
• #18: Picture different test mixes Common automated testing problems Picture different test mixes, highlighting problems
• #19: Tear drop shape Behavioural focus
• #20: Story about E, then .Net Monolith Story about HMRC (rollback)
• #21: Eye of Sauron, looking at the whole stack (user behaviour, down to disk space) Highlight: What to focus on (behaviour instead of environment) Leading vs. trailing indicators
• #22: Detect Alert Respond Display Analyse Diagram of right and wrong mix of the above
• #23: Detect Alert Respond Display Analyse Diagram of right and wrong mix of the above
• #25: Tell a story Mongo query defect at HMRC Kibana Change in success rate Kibana / splunk
• #28: Making changes to Running machine Stories and Diagram of Cookie change Database change
• #29: Story about no more manual scripts / steps
• #38: Microservice architecture Amazon quote - Build It, Run It, Own it Separation of features and concerns Prefer service dependencies over library dependencies
• #39: Principle of least surprise Service API's must always be backwardly compatible Story of when we were young, teams wanted to test against fixed versions of other services
• #41: Promote Build Quality In Excellent chapter in ILSD on VSM’s