Continuous delivery is a method of automating and improving the software delivery process. It provides benefits like faster time to market, ability to react quickly to changes, and improved reliability. The public sector faces challenges in adopting this approach due to previous project failures, security concerns, and risk-averse organizational culture. However, groups like GDS are helping the public sector implement techniques like continuous delivery using small, agile teams and open source tools to address these challenges and deliver projects more successfully. The document then describes one public sector organization's journey toward continuous delivery, including prototypes, weekly releases, overcoming approval hurdles, and preparing the organization to support the system long-term.

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