continuous delivery in the uk public sector
Post on 17-Aug-2015
59 Views
Preview:
TRANSCRIPT
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
top related