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
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
Emphasise:
Fast feedback
Risk reduction
Valuable software
in short cycles
reliably released at any time
Fast feedback - shortest time from concept to cash
Risk reduction - smallest value possible
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.
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
CI that works
Culture - Mind share
CI that works - knowing what to automate - a story about .Net Monolith
Cross functional teams
Picture of team mix
Picture of testing all the time
Story about E
Cross functional teams
Picture of team mix
Picture of testing all the time
The test automation pyramid
API and/or integration tests
Picture different test mixes
Common automated testing problems
Picture different test mixes
Common automated testing problems
Picture different test mixes, highlighting problems
Tear drop shape
Behavioural focus
Story about E, then .Net Monolith
Story about HMRC (rollback)
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
Detect
Alert
Respond
Display
Analyse
Diagram of right and wrong mix of the above
Detect
Alert
Respond
Display
Analyse
Diagram of right and wrong mix of the above
Tell a story
Mongo query defect at HMRC
Kibana
Change in success rate
Kibana / splunk
Making changes to Running machine
Stories and Diagram of
Cookie change
Database change
Story about no more manual scripts / steps
Microservice architecture
Amazon quote - Build It, Run It, Own it
Separation of features and concerns
Prefer service dependencies over library dependencies
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
Promote Build Quality In
Excellent chapter in ILSD on VSM’s