Find a job is a free service on GOV.UK that matches up candidates with prospective employers to find full-time or part-time jobs. It replaced Universal Jobmatch and is one of the most viewed government services on GOV.UK.
Since its launch in May 2018, more than 48.6 million adverts have been placed on the Find a job site.
In November 2018, we changed our release process on Find a job from periodic releases to continuous deployment. This means we release code every day. The switch allowed us to resolve issues quickly and reduce risk for the service, and follows the GOV.UK Service Manual advice for deploying software regularly.
Continuous deployment is when the process of releasing code to production is automated. This is distinct to continuous delivery, where code can be released to production at any time.
Our transition to continuous deployment has benefited both users and the service team. It means no more scheduled downtime, which helps user experience, and no more early morning calls for the service team.
How this helps users and government
Continuous deployment allows new features to be added as soon as they’re ready, which means we can fix issues quickly and reduce risk. It’s far safer to do 50 micro-releases than one big bang, and it’s easier to resolve issues if things go wrong.
Also, by changing things rapidly, we cut down the time users have to wait for improvements. We also receive feedback on changes more quickly, so we can iterate faster – in hours or days instead of weeks.
We decided on full deployment automation to decrease risk as it makes the process more repeatable and reliable, and lowers the chance of human error from DevOps staff running scripts and copying files. This also leads to zero downtime.
This way of working is all dependent on a robust, automated deployment pipeline, Test-Driven Development and comprehensive, automated testing.
How we made the switch to continuous deployment
When we proposed continuous deployment to our DWP Digital Change Advisory Board, a body that supports controlled change in our organisation, we needed to show them why the move was important.
We demonstrated how the switch would help modernisation and efficiency, and also improve the chance of delivery and decrease risk. All of these benefits were accepted by the Board.
However, we were challenged to prove that the changes would be authorised, controlled and well documented. And, that there were robust rollback plans and the security of the employer vacancy and job seeker profile data would be protected.
We proved this by agreeing what constituted a ‘standard change’ – small, self-contained, iterative changes within the application. This comprises of the vast majority of changes in most agile digital services, including Find a job. For the remaining changes, made up of new components and interfaces, we would release manually and through impacted change request processes.
The impact of our new way of working
After changing to continuous deployment, we can perform standard changes every day without the need to know exactly what features will be in any particular release, at least one week in advance – code will be deployed when it is ready.
We want to hear more about some of the successes and challenges others have had in the journey towards continuous deployment, so please tell us in the comments below.
3 comments
Comment by Jason Gibbs posted on
DWP has a Change Approval Board? What’s the reason for that in 2019?
Comment by Barry Traish posted on
I know, and doing this was a step away from that bureaucracy. However, DWP makes thousands of changes across highly integrated legacy systems and network components, and those changes need coordinating to avoid clashes. There remains an issue with applying legacy control and governance to modern, Digital services, but hopefully this is a step in the right direction.
Comment by Seán Massey posted on
You missed out that you ring a bell after every release !