Civil servants across government write the content that sits on GOV.UK. They use a number of publishing tools to write and publish that content to the website.
But between clicking the 'Publish' button and the content appearing online, a series of applications perform various tasks to make it available to users.
This is the publishing pipeline – the cross-government system used by thousands of government writers daily to reach their users – and it's the beating heart of GOV.UK. We've worked on the publishing pipeline in the past but as the platform scales to meet demand, it needs more work.
Users from across government have noticed a slowdown in how long it takes to publish content in recent months. We've also seen this in some of our monitoring, which checks the time that content was scheduled to be published and the time it actually became visible on GOV.UK.
It's essential that the publishing pipeline continues to work reliably and consistently. For example, when the government publishes a press release about a news event, it’ll follow up by telling news organisations and providing them with a link to the page.
If the page is not there, it could affect the government’s reputation for communicating effectively. So we've started work to make improvements to the pipeline.
Our first workshop
The developers on our Platform Health team – who help keep GOV.UK running smoothly at scale – have a mixture of confidence, knowledge and experience about our publishing pipeline. This includes the apps involved, how they talk to each other and the order of events that take place to publish a piece of content.
We wanted to build a shared understanding of the pipeline in a workshop, where we could challenge what we already knew, explore areas we’re new to and have the opportunity to ask questions.
Visually drawing out the pipeline on a whiteboard showed us it’s a complex system, with a published document going through many stages before it actually gets shown to users on GOV.UK.
Mapping it out from scratch meant we were thinking about the process step by step, voicing what we already knew at each stage and clarifying things with each other to help cement the process.
Once we felt the diagram was complete we then discussed and highlighted points that were most likely to be causing publishing delays and drew hypotheses. We think one of the possible causes is the way we do caching. But before we can choose which other hypotheses to work on, we’ll need to measure the time it takes for content to move through the pipeline.
After the workshop we felt more confident in our understanding about the publishing pipeline, which will help us to be more effective when we carry out further work on it.
First of all, we’ll be changing how caching works. This will make updates to pages appear sooner, meaning users should see the most recent content quicker.
Measuring the pipeline will expose where the bottlenecks lie and where it’s most beneficial to make tweaks. That’s also an important part of the Build, Measure, Learn feedback loop – a scientific approach to product development which helps eliminate uncertainty and wasted effort.
As we make changes to the pipeline, we’ll be able to measure the results of our work and understand whether we’re making improvements.
Steve Messer is a product manager and Deborah Chua is a developer on GOV.UK.
You can follow Steve on Twitter.
Comment by Allan Moorfield posted on