Continuous Delivery in the UK public sector

Nuno Marques @nfma

Summary

• what?

• how?

• benefits

• public sector

• our journey

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”

What?

Continuous delivery is a collection of good design practices in software development to

automate and improve the process of software delivery !

How?

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

Public sector challenges

• previous failures

• security

• mentality

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

Public sector addressing failures

• GDS (gov.uk)

• small(er) companies

• free and open source

• be agile

Public sector security challenges

• data leaks

• being hacked

• required CTC, SC and background checks

• restricted access everywhere

• public humiliation in general

• 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

Public sector organisation’s mentality

• conservative

• change avoidance

• waterfall

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

Journey goal

• replace a system that had been delivered the year before

Journey tech stack, architecture & tools

• scala, play, dropwizard, mongodb, etc…

• microservices architecture

• environments (dev, test, preview, live, …)

• gitlabs, pivotal, jenkins

• GDS cloud

Journey till alpha

• prototypes

• UX getting feedback from prototypes

• people at Starbucks

• going to centres

• jenkin’s build

• automating deployment with puppet

Journey alpha till beta

• one devop person joined

• basic monitoring

• pingdom

• sensu

• releasing every week (negotiated)

Journey release challenges

• parked for a week because of approvals

• required going through every commit

• required explicit request to production environment

• gathered crowd

Journey addressing release challenges

• flawless and boring releases

• speeding up the approval process

• automating release notes

• improved commit messages

Journey more challenges

• tight and rigid deadline

• improving live products

• law changes

Journey addressing deadline

• scope control

• working extra

Journey addressing improvement of live products

and law changes• feature switches

• bug fixing release candidates

• sanitising data migrations

• improved monitoring

• logstash & kibana

• zabbix

Journey notes on feature switches

• quicker integration (compared to feature branches)

• configuration per environment

• intrusive

• requires testing even when off

• requires work after activation

Journey backlog

• moving towards the final infrastructure (still being designed)

• helping the organisation take over support

Q&A