►
Description
The Government Digital Service is transforming the UK government by improving services so that they're simpler, clearer and faster for people to use. GDS built GOV.UK, the single website for government, and has started work on shared platforms like application hosting, payments and notifications.
Jenny and Alex will introduce GDS, describe some of the tools and processes that go into building and running GOV.UK in the open, and talk in detail about how we closed hundreds of government websites and maintain redirects to GOV.UK so that links to the old sites continue to work.
Jenny is a senior developer at the UK's Government Digital Service. She's tech lead of the Custom Formats team, which owns the more specialised publishing formats and tools on GOV.UK, the single domain for government.
Alex is the technical lead and only developer on the GOV.UK infrastructure team, which keeps the UK government's website running reliably. At the moment the team is improving disaster recovery and thinking about the future of GOV.UK's hosting.
About Satellite:
GitHub Satellite 2016 was a celebration of the latest and greatest in development. Watch the recordings to learn how engineers, founders, activists, and beyond tackle the latest and most difficult challenges in software.
For more, join us in San Francisco on September 13th-15th for GitHub Universe, three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
We
are
developers
at
the
government
digital
service
in
the
UK.
We
work
on
the
single
domains
of
government
at
UK
and
today
we're
going
to
talk
to
you
a
bit
about
it.
I'm
gonna
talk
about
where
the
website
came
from,
how
it
began
and
how
we
work
on
it
day
to
day
and
then
Jenny's
going
to
talk
about
how
we
moved
all
of
the
old
government
websites
onto
one
single
domain.
A
So
to
begin
at
the
very
beginning.
This
is
how
the
government
website
looked
in
2010
or
2011,
so
it
was
had
a
reputation
of
not
being
massively
easy
to
use
and
if
you
think
about
the
technology
that
we
were
all
using
in
2010
or
2011,
it's
pretty
clear
from
using
this
that
the
government
wasn't
really
keeping
up
with
the
rate
of
change
of
mainstream
consumer
technology.
So
there
was
a
small
team
that
was
put
together
to
create
a
vision
for
what
a
government
website
could
look
like.
A
It
was
a
small
cross-functional
team
and
they
came
up
with
an
alpha
which
they
made
in
about
three
months,
and
this
was
really
designed
to
make
people
sit
up
and
think
what
government
could
do
with
a
website
at
the
same
time
that
they
were
doing
that
they
had
some
design
principles.
So
these
are
not
just
principles
for
designing
their
principles
for
creating
great
digital
services.
So
they're
things
like
right
up
at
the
top.
The
most
important
is
start
with
needs.
A
The
asterisk
there
is
user
needs
and
not
government
leads
because
government
had
always
been
good
at
thinking
about
what
it
wanted,
but
not
good
about
thinking.
What
people
who
interacted
with
government
wanted
so
number
5
on
the
list.
Iterate
then
iterate
is
an
indication
that
things
are
never
finished
really
and
then
there's
certainly
never
created
finished.
They
always
require
work
to
keep
going
so
the
team
that
was
working
on
the
Alpha
shipped
the
live
website.
A
That
became
the
single
domain
for
government
and
we
moved
all
of
the
old
government
websites
onto
one
single
domain
and
made
it
easier
for
people
to
find
things
easier
to
use.
And
that
brings
us
to
where
we
are
today
so
Goff.
Don't
UK
is
the
single
website
for
government.
It's
the
place
that
citizens
visit
if
they
need
something
from
government
and
it's
the
place
for
every
government
department.
A
Publishers
to
so
I
want
to
talk
a
bit
about
how
we
work
on
gov
dot,
uk'
and
how
we
go
about
our
day
to
day
work
so
that
tent
design
principle
that
I
showed
you
on
the
list
is
make
things
open.
It
makes
things
better
and
we
try
to
follow
that
as
much
as
we
can
on
wk.
So
road
map
is
a
public
Trello
board.
A
I
think
this
is
amazing,
because
this
is
people
on
github
getting
excited
about
the
launch
of
a
government
website,
which
is
just
not
something
that
ever
could
have
happened
before
there
are
cat
gifts
and
means,
and
it
just
goes
on
and
on
and
on-
and
this
never
would
have
happened
with
direct
up
the
old
site.
This
image
at
the
bottom
here
is
3
a.m.
in
the
morning
in
October
2012,
when
the
old
orange
website
switched
over
to
the
new
one.
A
That
was
the
team
that
made
the
change
to
do
that,
and
that's
a
great
reason
for
making
our
stuff
public.
It's
not
that
great
much
more
importantly,
is
stuff
like
this.
This
is
a
pro
quest
from
a
digital
agency
that
was
doing
some
work
for
a
different
part
of
government,
so
they
were
making
use
of
one
of
our
core
applications
on
WK
and
they
needed
to
change
it.
To
support
a
PostgreSQL
database,
this
wasn't
something
that
we
needed.
A
It
was
something
that
we
thought
about
doing
at
some
point
in
the
future,
but
it
wasn't
a
priority
for
us,
but
because
all
of
my
code
is
public
long
enough
that
you
can't
on
github
they
were
able
to
without
having
to
jump
through
any
hoops
make
this
change
and
with
a
bit
of
backwards
and
forwards
on
the
pull
request.
With
review
from
us,
we
were
able
to
get
this
changed
merged
into
our
public
repo.
So
this
is
a
great
example
for
making
our
code
public.
A
We
make
a
bit
of
a
distinction
between
the
things
that
we
publish,
so
everything
that
we
have
on
github
is
open
source
licensed,
but
we
don't
use
the
term
open
source
to
describe
what
we
do.
We
say
coding
in
the
open
instead,
and
we
say
that
because
we
don't
have
the
resources
to
foster
a
community
around
what
we're
doing
and
also
we're
not
certain
that
fostering
a
community
around
what
we're
doing
is
the
most
useful
thing.
A
lot
of
our
code
is
very
specific
to
the
problems
that
we're
trying
to
solve.
A
There
are
some
things
that
we've
extracted
so
small
parts,
which
we
know
a
useful
and
reusable,
and
we
do
publish
those
as
supported
open
source,
but
we
don't
do
it
for
everything
and
then
the
stuff
that
we
can't
publish
for
that.
We
use
github
Enterprise,
which
it's
been
talked
about
today.
These
are
in
this
ProQuest,
some
of
our
actual
production
passwords
encrypted
in
our
github
repo
with
GPG,
so
I
hope,
GPG
works
so
hopefully
you're
getting
the
idea
that
we're
really
big
fans
of
version
control.
A
A
This
is
changing
the
SSL,
so
security
ciphers
that
are
in
use
on
the
config
and
this
change
by
itself
doesn't
really
mean
anything
at
all,
at
least
not
to
me
just
looking
at
this
dish
and
in
places
that
I've
worked
before
and
maybe
places
that
you've
worked
before
the
change
in
the
git.
Repo
might
have
looked
like
this,
and
this
is
a
seven
character,
change
from
March
2014
and
there's
no
useful
information
in
the
commit
message
at
all.
A
So
fortunately,
the
actual
change
in
our
repository
looks
more
like
this.
This
is
the
commit
message
that
went
along
with
that
change
and
it
explains
in
a
huge
amount
of
detail,
the
state
of
the
system
before
the
change
was
made
and
afterwards
and
the
reason
for
the
change
and
all
of
the
contexts
and
thinking
that
has
gone
into
it,
and
we
find
this
really
valuable,
especially
for
changes
that
are
two
years
old
and
especially
in
this
case,
because
this
developer
doesn't
work
on
God
at
UK
anymore.
So
it's
not
like.
A
B
A
So
we
make
huge
use
of
pull
requests
as
part
of
our
flow
for
reviewing
code
and
getting
in
reduction.
But
we
put
a
lot
of
work
into
our
commits
as
well,
and
we
do
that
for
a
few
reasons,
partly
and
probably
most
obviously,
because
you
don't
need
an
internet
connection,
see
your
comments.
But
in
all
of
the
context,
was
on
the
github
pull
request.
Then
you'd
be
relying
on
being
able
to
access
that
to
see
what's
going
on,
but
also
more
fundamentally.
We
do
that.
A
Because
government
has
an
interesting
history
of
dealing
with
vendor
lock-in
and
we're
very
conscious
that
if
we
had
to
stop
using
github
for
whatever
reason
we
would
want
to
be
able
to
take
the
context
of
our
repository
with
us.
So
we
think
it's
really
important
to
store
that
information
with
the
code,
and
that
doesn't
mean
that
we
don't
build
things
on
top
of
github.
A
So,
like
I
said,
we
make
huge
use
of
pull
requests
for
getting
our
work
done
and
we've
built
stuff
to
enable
us
to
do
that.
So
this
is
a
project
we
have
which
shows
open,
pull
requests
against
our
repositories.
Every
team
has
a
or
pretty
much
everything
has
a
monitor,
which
shows
the
pull
requests
that
they
need
to
review,
how
long
they've
been
open
and
what
the
state
of
them
is.
A
B
So
alex
has
talked
about
how
we
build
up
UK
and
I'm,
going
to
talk
about
the
second
part
of
our
talk.
Title
they're,
not
breaking
the
web
part
so,
as
I
said,
go
pique
launched
in
October
2012
and
it
replaced
to
earlier
central
government
websites
called
Directgov,
which
is
that
orange
one
and
business
link,
which
was
blue
and
go
BK,
had
actually
be
on
our
online
for
some
time
before
that,
in
beta
and
on
night.
B
So
this
process
is
what
we
mean
by
transition.
It's
government
organisations
starting
to
publish
on
gov
UK
and
their
old
sites
being
redirected
to
that
new
content
on
wk.
A
guiding
principle
of
UK
is
that
users
shouldn't
have
to
understand
the
internal
structure
of
government
in
order
to
be
able
to
interact
with
it
or
to
find
the
information
that
they're
looking
for
so
this
image
that
Alex
showed
you
earlier
of
all
these
different
Department
websites
before
transition.
B
If
you
want
to
find
out
something
that
the
government
is
doing
or
that
policy
on
something
you
might
have
to
know
which
the
part
was
responsible
for
that
policy
navigate
your
way
around
always
differently
structured
websites
to
find
what
you
needed,
because
the
content
wasn't
all
in
one
place
and
it
wasn't
structured
and
organized
around
user
needs
or
written
with
user
needs
in
mind,
and
there
are
some
areas
of
responsibility.
The
across
multiple
departments,
such
as
the
government's
policy
on
Afghanistan,
it's
made
by
multiple
departments.
B
You
are
all
involved
in
different
aspects:
there's
a
list
of
them
in
the
middle
of
the
page
there
and
now
there's
just
one
page
on
gov
UK
for
this
policy,
and
it
is
maintained
by
all
these
departments
and
that
page
lists
all
of
the
publication's
from
each
department.
So
you
can
see
them
all
together
in
one
place,
but
the
responsibilities
are
still
clear.
If
you
want
to
understand
that
our
first
design
principle
from
that
list
that
Alex
showed
you
is
start
with
needs
user
needs,
not
government
needs.
B
B
So
since
we
were
writing
new
content
for
WK
to
meet
fellow
Jews
in
the
Eids,
why
bother
redirecting
URLs
from
the
old
site
when
I
just
turn
them
off
completely
and
forget
about
them?
Well,
there
are
links
to
all
those
old
sites
in
search
engines
on
other
web
sites.
This
is
a
link
to
direct
gov
on
the
website
of
Citizens
Advice,
which
is
a
well-known
charity
in
the
UK
that
provides
free
and
impartial
advice
to
people.
Missing
link
is
still
on
their
site
today.
B
Charities,
don't
know
where
to
have
the
resources
to
be
able
to
update
all
of
their
links
all
over
their
sites,
and
we
shouldn't
expect
them
to
do
that.
We
should
be
able
to
keep
these
links
working.
There
are
URLs
printed
on
mugs
on
other
promotional
materials.
I,
don't
know
what
the
point
of
this
thing
is,
but
it's
there
and
on
pre-printed
stationery.
So
this
is
on
the
back
of
an
envelope,
but
it
could
be
letters
or
leaflets
and
a
doctor
surgery,
and
these
printed
URLs
in
particular,
have
to
stay
working
for
a
really
long
time.
B
And
this
kind
of
context
is
something
that
most,
how
probably
wouldn't
need
to
deal
with
government
is
special.
Sometimes
another
way
the
government
is
special.
Is
that
people
interact
with
government
not
out
of
choice
out
of
necessity,
they're
often
in
difficult
times
in
their
lives
and
challenging
situations.
B
There
were
hundreds
of
them
with
millions
of
users
at
a
high
level,
a
site
transitions
by
the
organization
that
owns
that
site,
changing
the
DNS
so
that,
instead
of
the
domain
pointing
to
the
old
site
servers,
it
changes
to
point
to
the
CDN
that
sits
in
front
of
gov
UK's
transition
tools,
and
then
we
serve
the
archives
or
redirects
to
users.
That
means
that
we're
handling
everything,
except
for
the
DNS
centrally
so
departments,
can
end
their
hosting
contracts
for
those
old
sites.
They
can
turn
off
the
servers.
B
The
initial
system
that
we
built
to
do
this
was
called
redirector
and
that
was
used
for
direct
gov
and
business
link
and
those
first
24
departments,
and
that
system
was
built
really
quickly
in
just
a
few
weeks
before
Jeffrey
Kaye
launched
the
data
source
for
redirector
was
lots
of
really
big
csv
files
of
mappings
mappings
are
a
URL
on
an
old
site,
with
the
behavior
that
they
should
have
after
transition,
but
that's
a
redirect
to
a
new
URL
or
an
archive,
so
those
CSV
E's.
There
were
lots
of
them.
B
They
were
all
bunched
together
in
a
particular
order
to
overwrite
each
other
in
certain
ways
with
Perl
scripts,
and
then
there
were
make
files
that
generated
other
make
files
and
all
of
that
generated
a
big
bundle
of
nginx
web
server
configuration,
and
that
was
what
was
deployed
to
servers
to
actually
serve
all
those
redirects
and
archives.
So
this
system
was
built
really
really
quickly.
It
worked,
but
it
had
some
disadvantages.
B
Changes
to
mappings
should
only
be
made
by
a
few
people
working
within
gov
UK
because
they
were
in
CSV
files.
In
a
git
repository.
We
restrict
access
to
those.
Only
certain
people
are
allowed
access
to
our
code
that
gets
deployed
to
production
and
that
and
a
git
repo
is
not
the
most
successful
place
for
non
developers
to
edit
things.
So
GDS
became
a
bottleneck
for
maintaining
all
of
those
mappings
for
those
first
sites.
B
Also,
the
whole
system
needed
to
be
deployed
periodically
for
changes
to
mappings
to
take
effect,
so
it
was
difficult
to
fix
a
single
one
quickly
if
you
found
that
it
was
broken
and
by
the
time
those
initial
24
departments
had
transitioned,
it
was
already
generating
hundreds
of
thousands
of
lines
of
nginx
configuration
which
isn't
really
how
index
is
intended
to
be
used.
It
used
up
a
lot
of
memory
on
those
servers
and
it
took
quite
a
long
time
for
nginx
to
restart
because
it
was
having
to
load
so
much
conflict
into
memory
else.
B
It
turns
out
that
it's
quite
difficult
to
make
a
list
of
all
of
your
URLs
that
exists
on
a
website
in
the
first
place
in
order
to
work
out
what
you
would
need
to
map
there's
a
few
reasons
for
that.
The
structure
of
the
old
site
might
have
already
changed
several
times
in
the
past.
Some
of
those
old
sites
have
been
around
for
10
or
15
years.
B
B
There's
also
some
content
that
some
of
those
sites
had
published,
because
the
organisation
had
legal
obligation
to
publish
that
content
and
make
it
available
and
keep
it
up
to
date.
And
so,
even
though
there
aren't
very
many
people
actually
viewing
those
pages,
so
the
URL
show
up
rarely
in
server
logs
or
in
Google
Analytics.
We
still
need
to
move
that
content
onto
gov
UK
and
redirect
it
and
make
sure
that
it's
available
so
that
we're
not
breaking
the
law.
B
B
B
It
also
isn't
always
easy
to
decide
where
to
redirect
each
URL
to
we
learnt
really
early
on
that.
The
people
who
knew
the
content
and
the
users
of
the
old
site
best
should
be
making
the
decisions
about
where
to
redirect
to,
because
you
just
need
to
understand
why
use
would
be
going
to
those
old
pages
to
make
that
decision
and
when
we
were
transitioning,
Directgov
and
business
link.
B
B
So,
although
we
had
a
system
in
production
that
got
the
job
done,
we
knew
there
were
problems
with
it,
both
technical
and
process
problems,
and
so
we
had
to
iterate
and
build
something
that
were
better
meet.
Our
users
needs,
so
the
team
that
I
was
on
built
some
new
applications
instead
of
use
a
set
of
redirector
for
the
next
300
organizations
that
were
transitioning
onto
KPK.
B
That
app
rights
to
a
Postgres
database
and
then
we
have
a
separate
application
called
bouncer,
which
is
a
small
ruby,
rack,
app
that
reads
from
that
database
and
then,
when
users
visit
URLs
on
the
old
sites,
those
requests
go
to
bouncer
and
it
serves
redirects
or
archive
pages
to
them.
So
what
are
the
benefits
of
this
new
system
over
the
previous
one?
Well,
there
are
some
technical
passages
to
start
with
changes
to
my
things
are
written
to
a
database
and
so
they're
available
immediately
on
the
mix
request
a
bouncer
for
that
URL.
B
We
don't
need
to
deploy
the
whole
system
as
developers
taking
up
our
time
to
build
those
changes
to
go,
live
straight
away.
Also,
these
applications
scale
much
better
for
us
than
this
really
large
bundle
of
Internet's
configuration
the
restart
time
for
an
app
business
dependent
on
the
number
of
mappings
that
are
in
the
database,
and
we've
already
got
systems
on
cough
UK
for
doing
zero,
downtime
deploys,
and
so
we
can
use
our
usual
techniques
for
scaling
applications.
Instead
of
having
to
come
up
with
something
more
custom
for
the
old
redirect
system.
B
Also,
we
use
rails
a
lot
on
gov
UK.
We've
got
something
like
80
applications
that
make
up
WK,
the
majority
of
them
are
rails
and
we
have
fewer
developers
than
applications.
So
it's
really
important
to
us
for
our
workflow
that
people
can
work
on
different
applications
and
there's
always
some
context.
Switching
but
at
least
having
more
things
in
rails
makes
it
easier
for
us
to
do
that.
It's
much
easier
for
developers
to
maintain,
and
this
really
custom
system
of
CSVs
and
pearl
and
make
files
that
was
only
understood
by
a
few
people
who
built
it.
B
So
the
new
apps
are
easier
for
us
as
developers
to
maintain
and
work
with.
But
what
about
government
users?
What
do
they
get
from
this?
The
transition
tool
can
be
used
by
people
in
departments
to
manage
all
of
the
mappings
for
their
sites
themselves,
which
means
that
GDS
is
no
longer
a
bottleneck
to
making
changes
and
getting
them
live.
B
So
this
is
what
the
main
page
for
searching
for
an
editing
mappings
for
a
site
looks
like
in
the
transition
tool
in
order
to
be
successfully
self
sort
of
transition
needs
to
work
for
people
without
them.
Having
to
understand
DNS
or
HTTP
is
a
mostly
not
technically
in
departments
who
are
making
these
changes
to
sites
and
mappings.
But
even
though
this
application
is
controlling
effectively
how
parts
of
the
internet
work,
we
had
to
make
something
that
would
work
for
users
who
didn't
have
that
technical
knowledge.
B
So
we
had
to
understand
their
needs
in
order
to
build
it.
Well.
So
if
we
zoom
in
on
that
page
to
see
a
few
examples
of
how
it
does
that
we
try
to
avoid
HTTP
terminology
where
we
can
Yap.
So
we
say
oh,
we
archive
and
redirect
for
individual
mappings,
rather
than
referring
to
HTTP
status
codes,
and
we
say
that
it-
you
are
l,
remapping
redirects
to
a
new
URL,
rather
than
calling
it
the
location
like
the
header
on
a
301
response,
and
with
hindsight
that
means
maybe
seem
surprising.
B
But
we
needed
to
adapt
how
our
teams
thought
about
this
process
in
order
to
make
the
application
work
better
for
users,
and
it's
also
worth
pointing
out
that
a
single
mapping
will
actually
handle
requests
for
multiple
URLs,
because
we
canonicalize
urls
both
in
the
transition
tool
and
in
bouncer,
so
that
in
general
we
are
ignoring
parts
of
the
URL
that
wouldn't
have
made
a
difference
to
the
content
that
the
user
would
have
seen
on
the
old
site.
So
generally,
we
ignore
query
strings.
B
At
the
time,
Dave
Mann
wrote
a
blog
post,
which
explains
some
of
the
technical
terms
around
transition,
and
we
had
feedback
from
our
users
that
they
found
it
useful
to
have
that
context,
and
so
we
put
it
into
the
app
as
a
glossary
and
we
get
it
up
to
date.
No
matter
how
much
we
try
to
avoid
using
those
technical
terms
in
discussions
around
transition,
they
do
still
come
up
because
at
heart
we
are
getting
organisations
to
make
changes
to
DNS
and
they
need
to
understand
some
of
those
things.
B
B
But
actually
we
realized
that
everything
that
configuration
does
need
technical
context
and
peer
review,
and
so
we
also
need
to
be
in
control
of
what
domains
our
tools
are
handling
centrally.
So
it
wasn't
appropriate
for
departments
to
do
that
part
themselves
and
pull
requests
already.
Give
us
the
workflow
that
we
needed
to
do
that
and
I'm
just
going
to
point
out
here
that
we
decommissioned
the
nuclear
decommissioning
Authority
they
manage
and
dispose
of
nuclear
waste.
B
Pretty
cool
became
practical
requests,
like
github
already
controls
who
has
access
to
write
to
this
repo
to
update
the
configuration
we
get
peer-review
with
comments
on
pull
requests.
We
can
validate
changes
to
the
conveyed
with
tests
that
run
in
our
CI
environment
and
we
can
see
the
status
of
those
tests
on
the
pork
rice
before
we
merge.
We
didn't
need
to
build
a
new
feature
in
our
application
for
this.
The
transition
tool
already
did
everything
that
you
need
to
do.
B
This
data
gives
our
users
the
information
that
they
need
to
find
URLs
that
they
had
missed,
so
they
can
create
mappings
for
those
URLs
and
it's
also
an
opportunity
to
catch
missed
user
needs.
If
you
see
after
as
I
had
a
transition
that
something
that
we
had
thought
we
could
archive
is
still
getting
a
really
high
level
of
traffic.
Then
that
indicates
that
people
are
still
going
to
look
at
it.
Then
perhaps
we've
missed
a
user
need.
We
should
consider
writing
new
content
on
WK
and
redirecting
that
old
URL.
B
So
the
graphs
on
these
pages
give
an
overview
of
all
the
data
and
then
below
that
there
are
tables
which
show
every
URL
and
the
number
of
requests
with
the
status
that
they're
getting,
and
we
use
a
bar
chart
within
the
table
to
indicate
the
number
of
requests
for
each
of
those
URLs.
This
table
shows
some
URLs
that
used
to
be
for
referring,
because
they
didn't
have
my
things
at
the
time
and
then
within
the
table.
B
B
Traffic
doesn't
actually
go
down
very
much
after
a
site
transitions.
You
might
think
that
after
the
old
site
just
starts
redirecting
somewhere
else
that
the
traffic
would
all
disappear
really
quickly,
but
actually
it
goes
down
a
little
bit
to
start
with.
Then
it
stays
stable
for
well
about
three
years
after
that
so
far
anyway.
So
it's
really
important
that
we
keep
these
URLs
working.
We
keep
all
these
tools
up
and
running
a
long
time
after
these
sites
of
transition,
so
that
people
can
still
get
to
the
wk
and
find
the
content.
B
B
It's
hard
talking
to
work
out
the
reasons
for
it,
and
so,
if
we
just
look
at
the
six
months
of
the
data
from
the
very
foot,
the
start
of
that
graph
and
zoom
in
on
that,
so
this
site,
transitioned
really
early
on
this,
was
before
we
started.
Building
the
transition
tool,
and
so
the
data
that
is
shown
on
these
pages
comes
from
processing
our
CDN
log
files,
and
we
were
storing
the
looks
then,
but
we
weren't
displaying
this
data
anywhere.
B
B
We
were
serving
like
550
thousand
for
a
thousand
a
day
compared
to
about
ten
thousand
redirects,
which
isn't
great
because
most
of
our
users
are
getting
errors
at
that
point
and
then,
after
a
while,
the
error
rate
suddenly
drops
and
then
most
requests
to
read
the
right
thing,
and
then
it
drops
again
and
a
few
weeks
later,
so
this
site
was
managed
in
redirect
at
the
time
so
a
deploy.
If
that
system
would
suddenly
fix
a
lot
of
things
at
once.
B
That
was
actually
emerges
for
one
URL
that
was
erroring
on
that
day,
so
we
import
the
data
into
the
transition
tool
every
hour.
So
you
just
get
really
quick
feedback
after
their
site
transitions,
so
they
can
fix
these
errors
really
quickly.
So
they
created
a
mapping
for
this
URL
straight
away
and
the
next
day
it's
back
down
to
pretty
much
zero
again
and
you
might
not
be
able
to
read
the
scale
on
that
graph.
There
were
a
hundred
thousand
requests
for
that
one
URL
in
that
one
day
we
serve
four
hundred
thousand
404s.
B
This
site
was
for
the
government
organization
that
regulates
medicines
for
the
UK
and
they
publish
information
about
medicines
and
drugs
which
need
to
be
recalled
because
there
were
production,
faults
or
they're
contaminated
and
they're
dangerous
for
people
to
take,
and
this
URL
was
an
RSS
feed
for
those
alerts
and
lots
of
doctors
or
other
people
who
work
in
medicine.
We
subscribe
to
that
to
get
all
that
information
as
quickly
as
possible.
B
This
content
is
really
really
important
and
it
gets
a
lot
of
traffic
and
it's
really
important
to
redirect
these
URLs
so
that
we
keep
them
working
and
displaying
data
to
our
users
like
this
enables
them
to
do
that.
This
is
what
we
mean
by
designing
with
data,
and
we
enable
our
users
to
design
the
data
to
the
longer
explanation,
for
this
design
principle
says
that
analytics
should
be
built
in
always-on
and
easy
to
read,
and
this
is
a
great
example
of
doing
that.
B
So
what
do
you
see
when
you
visit
URLs
on
old
sites
after
transition?
Well,
bouncer
serves
three
types
of
responses:
I've
mentioned
them
all.
Already,
most
requests
are
redirected.
So
if
you
visit
this
really
long
URL
on
Directgov
now,
then,
instead
of
seeing
this
Orangeburg
up
page
bounce,
it
redirects
you
to
this
page
on
cookie
Kay,
it
has
got
a
shorter,
cleaner,
URL.
It's
a
serious
experience
for
users.
They
don't
really
notice
bounce
of
doing
that,
we're
just
getting
people
to
the
best
place
to
that
content.
B
Now
we
saw
this
page
earlier
on
that
there
was
no
user
need
for.
If
you
visit
that
URL
now
you
get
a
page
like
this,
it's
been
archived
and
but
these
archive
pages
aren't
just
a
dead
end
for
users.
There's
a
link
at
the
top
there
too.
The
last
item
in
the
UK
is
government
web
archive
and
then
there's
a
link
to
the
department's
new
homepage
on
gov
UK
at
the
bottom.
B
There's
a
link
to
a
contact
form
on
WK,
so
that
users
can
give
us
feedback
if
they
can't
find
what
they
were
looking
for,
if
they
think
we
should
be
redirecting
them
somewhere
else,
and
if
you
click
on
that
first
link
to
the
web
archive,
you
can
see
that
the
original
content
is
still
available
there
in
that
archive.
It
hasn't
completely
disappeared
from
the
web.
B
This
is
an
example
of
a
404
page,
and
you
get
one
of
these.
If
you
visit
a
URL,
but
we
don't
know
about
it
might
be
the
really
well
something
that
existed
or
like
this
one.
It
could
just
be
something
random,
but
you
still
get
the
links
here,
it's
similar
to
ones
on
the
archive
pages,
so
you
can
still
get
on
to
wk
or
find
other
places.
B
The
largest
plays
a
transition
finished
over
a
year
ago.
Now
so
like
what's
happened
since
then.
Where
are
we
at
now?
The
transition
Tolan
bouncer
handle
about
800
sites
across
one
and
a
half
thousand
domains.
We've
got
about
500
users
across
well
over
300
organizations
across
government,
maintaining
about
two
million
mappings
and
bouncer
handled
about
three
about
three
million
requests
they
across
all
of
those
transition
sites.
B
B
Okay,
so,
like
transition
is
not
actually
finished
yet
at
GDS
we've
built
tools
that
users
want
to
use
by
making
decisions
based
on
our
design
principles.
We
use
these
principles
really
really
frequently
we're
in
deciding
what
to
build
and
how
to
build
it,
and
there
are
constant
reference
point
for
us
they're,
really
at
the
heart
of
how
GDS
works.
So
this
is
how
we
build
a
few
K
and
how
we
do
it
without
breaking
the
web.
To
finish
our
github
Wilma's
ation
is
called
alpha,
Garvin
or
the
repos
would
be
talking
about
there.