Nuno Marques, Equal Experts Continuous Delivery in the UK public sector

1. Continuous Delivery in
the UK public sector
Nuno Marques
@nfma

2. Summary
• what?
• how?
• benefits
• public sector
• our journey

3. What?
Continuous delivery is a pattern language used
in software development to automate and
improve the process of software delivery
wikipedia
Pattern language is a method of describing
good design practices within a field of expertise
Christopher Alexander, “Pattern
Language”

4. What?
Continuous delivery is a collection of good
design practices in software development to
automate and improve the process of
software delivery

5. How?

6. Benefits
• time to market
• users benefit from application/features earlier
• smaller feedback loops
• better ability to react to change in a timely manner
• better efficiency
• improved reliability and stability
• no rollbacks

7. Public sector
challenges
• previous failures
• security
• mentality

8. Public sector
failures
• NHS IT Programme
• £10bn overrun (2002-2011) parts used
• BBC Digital Media Initiative
• £98m (2008-2013) cancelled
• Universal Credit
• £10bn (2013- ) 75% cancelled

9. Public sector
addressing failures
• GDS (gov.uk)
• small(er) companies
• free and open source
• be agile

10. Public sector
security challenges
• data leaks
• being hacked
• required CTC, SC and background checks
• restricted access everywhere
• public humiliation in general

11. • own computers
• disk encryption
• locked with strong passwords
• security clearances and background checks
• no access to organisation’s systems
• shared systems don’t contain sensitive data
Public sector
addressing security

12. Public sector
organisation’s mentality
• conservative
• change avoidance
• waterfall

13. Public sector
addressing organisations mentality
• GDS paving the way
• informal coaching
• reassurance through data
• making change the norm
• being agile as opposed to doing agile

14. Journey
goal
• replace a system that had been delivered the
year before

15. Journey
tech stack, architecture & tools
• scala, play, dropwizard, mongodb, etc…
• microservices architecture
• environments (dev, test, preview, live, …)
• gitlabs, pivotal, jenkins
• GDS cloud

16. Journey
till alpha
• prototypes
• UX getting feedback from prototypes
• people at Starbucks
• going to centres
• jenkin’s build
• automating deployment with puppet

17. Journey
alpha till beta
• one devop person joined
• basic monitoring
• pingdom
• sensu
• releasing every week (negotiated)

18. Journey
release challenges
• parked for a week because of approvals
• required going through every commit
• required explicit request to production
environment
• gathered crowd

19. Journey
addressing release challenges
• flawless and boring releases
• speeding up the approval process
• automating release notes
• improved commit messages

20. Journey
more challenges
• tight and rigid deadline
• improving live products
• law changes

21. Journey
addressing deadline
• scope control
• working extra

22. Journey
addressing improvement of live products
and law changes
• feature switches
• bug fixing release candidates
• sanitising data migrations
• improved monitoring
• logstash & kibana
• zabbix

23. Journey
notes on feature switches
• quicker integration (compared to feature
branches)
• configuration per environment
• intrusive
• requires testing even when off
• requires work after activation

24. Journey
backlog
• moving towards the final infrastructure (still
being designed)
• helping the organisation take over support

25. Q&A