►
Description
Presented by Guillermo Rauch, CEO, ZEIT
What does it take to build and deploy a cutting-edge website? Guillermo will take you through the complexity of the modern web, whether you’re building single or multiple pages that are static or dynamic, or working on the frontend or backend with serverless lambda functions.
He’ll help you bring your app code to life with preview deployments for every push and maximize performance and availability with a global CDN. Finally, he’ll cover how to go into production—and revert it—faster than ever before, while improving QA and testing with GitHub apps.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
So
for
my
presentation
today,
I'm
gonna
talk
about
briefly
about
the
industry
trends
that
we're
seeing
that
are
leading
to
better
ways
to
develop,
deploy
and
scale
websites
and
applications
followed
by
what
are
the
best
practices
that
we've
learned,
followed
by.
What
are
the
best
ways
to
use
github
in
combination
with
our
deployment
technology
and
our
development
technology,
to
make
apps
that
are
more
efficient,
more
correct
and
are
faster
in
every
possible
way.
A
little
bit
about
me,
some
of
you
and
recognized.
So
we
know
each
other.
A
My
background
is
in
front-end
development
back
in
2007
I
got
started
with
a
project
called
mootools,
which
was
kind
of
the
spiritual
predecessor
to
react
in
many
ways.
Mootools
was
a
project
that
was
early
on
adopted
by
Facebook
that
later
on
became
fbj
us
and
the
rest
is
history,
one
part
of
that
history
that
is
really
interesting,
mootools
overrode,
prototype,
dot,
flatten
and
then
the
web
could
never
use
it
again
and
that
led
to
a
big
discussion
over
the
damage
that
mootools
did.
A
But
overall,
it
was
a
really
great
experience
that
led
me
into
this
path
of
JavaScript
and
front-end
development.
I
spent
some
time
creating
other
projects
REO
and
Mongoose
later,
on
a
focus
on
this
idea
of
developer
experience.
How
can
we
build
the
best
developer
experiences
to
build
great
websites
and
applications
as
a
company
site?
We
started
in
2016
with
a
deployment
platform
and
later
on,
a
way
of
creating
really
slick,
really
easily
react.
Applications
called
next.
Yes,
this
react
framework
kind
of
pioneered
this
idea
of
zero
config
development.
A
We
pioneered
this
idea
that
the
file
system
should
kind
of
work
like
PHP,
and
it
should
be
very
easy
to
just
get
started,
put
a
bunch
of
files
inside
with
a
bunch
of
components
inside
and
off
to
the
races
we
got.
It
started
with
this
idea
of
empowering
developers
to
do
really
fast
applications
and
one
of
the
techniques
that
we
sort
of
used
as
a
default
was
server
rendering
and,
very
importantly,
we
didn't.
A
We
didn't
think
that
the
web
and
the
applications
and
websites
that
you'd
build
would
be
just
a
single
page,
and
we
kind
of
put
forward
this
idea
that
your
project
scales
by
its
introducing
more
and
more
pages
so
instead
of
single
page
applications,
we
kind
of
introduced
the
idea
of
multi
page
applications
in
2018.
We
created
a
new
deployment
platform
and
it
was
based
around
this
idea
of
static
hosting
and
serverless.
A
We
found
that
the
best
way
to
scale
your
site's
and
applications
is
to
have
no
state
whatsoever
in
terms
of
a
server
they'd
have
to
maintain,
and
in
2019,
we've
made
a
very
significant,
significant
progress
in
growing
at
this
technology.
A
few
days
ago,
we
announced
our
collaboration
with
Google
Chrome,
and
part
of
this
has
been
the
idea
that,
in
order
to
make
react
faster
at
scale,
we
have
to
all
work
together
on
marrying
developer
experience
with
great
end-user
performance.
A
So
we
kind
of
started
with
servers
a
bunch
of
years
ago
and
really
in
the
indie
industry
itself,
the
idea
of
creating
a
server
to
get
it
started
with
building
a
website
or
building
a
web
application.
It's
a
still
a
pretty
pervasive
idea,
but
what
we're
seeing
is
sort
of
this
transition
into
server
less.
If
you're
a
front-end
developer,
you
don't
want
to
deal
with
creating
clusters
and
containers,
even
though
the
parallel
track.
Someone
else
in
this
conference
is
talking
about
containers.
A
We
think
that
the
best
way
to
empower
the
developer
that
is
kind
of
working
on
the
last
mile
on
the
pro
is
to
actually
not
worry
about
servers.
The
transition
that
we're
seeing
as
well
as
from
the
data
center
to
a
global
edge
network
so
when
you
get
rid
of
all
the
server,
so
you
have
this
tremendous
advantage
when
it
comes
to
application
delivery.
Where,
if
you
export
your
project,
you
can
put
it
oddly
at
the
edge
automatically.
A
That
frameworks
like
free
at
rails,
introduced
where
you
would
base
everything
on
templates
and
we're
seeing
the
emergence
of
components
as
sort
of
the
primitive
of
the
entire
web
components
that
are
highly
reusable
components
that
are
well
documented
components
that
follow
a
style
guide,
components
that
have
a
semantic
meaning
as
part
of
broader
design
systems
and
even
more
interestingly,
we're
starting
to
approach.
This
idea
that
we're
transitioning
away
even
from
code
to
I'm,
gonna
use
a
buzzword
here,
low
code
and
perhaps
even
later
on
no
code,
negative
amounts
of
code
and
I.
Think.
A
To
summarize,
really
what
we're
seeing
is
a
transition
away
from
the
back
end
and
a
transition
towards
empowering
the
front
end
developer
and
when
I
was
referring
to
this
idea
of
code
and
no
code.
I
think
something
that's
interesting.
Is
that
we're
decisively
focusing
less
and
less
and
less
in
abstraction
and
more
and
on
interaction.
For
example,
when
you
build
a
a
design
system
built
of
components,
you're,
essentially
focusing
a
lot
more
on
the
product,
rather
than
the
underlying
abstraction
or
code
or
even
code
ifs
and
and
and
and
get,
and
all
that
just
kidding.
A
Some
services
are
maintained
by
yourself
or
your
company,
where
you
have
an
API,
such
as
a
REST,
API
or
right,
or
a
graphical
API,
but
broadly
we're
also
seeing
the
transition
towards
deferring
some
of
the
work
that
you
would
have
previously
done
yourself
to
dedicated
powerful,
very
optimal
services.
So
I
like
to
talk
about,
for
example,
headless
CMS
is
where
they're
providing
a
service
that
you
can
query
directly
from
the
front-end
or
sometimes
at
build
time.
A
That
is
entirely
separate
and
independently
scale
and
maintain,
and
you
operate
with
it,
with
an
API
and
I'd
like
to
talk
about
content
management,
because
using
the
sort
of
metaphor
of
Ruby
on
Rails.
That
I
was
talking
about
earlier,
where
it's
more
server
centric.
It's
it's
more
about
scaffolding,
kind
of
everything
from
scratch,
one
of
the
sort
of
beginning
of
of
how
he
was
introduced
to
the
world.
It
was
a
screencast
by
DHH
on
creating
a
blog
and
throughout
the
years
a
lot
of
people
have
asked
me
like.
A
Where
is
the
Ruby
on
Rails
of
JavaScript?
And
my
response
is
the
Ruby
on
Rails
of
JavaScript
is
probably
not
gonna.
Look
like
Ruby
on
Rails,
because,
instead
of,
for
example,
scaffolding,
your
own
blog
system,
on
top
of
your
own
database,
you're
likely
deferring
that
word
to
fantastic
content,
management
service,
like
content
fall
or
even
wordpress,
is
with
a
headless
API
and
we're
seeing
the
same
with
persistence
with
famously
firebase
a
few
years
ago.
A
That
is
looking
at
everything
from
the
lens
of
the
web.
Browser
because
now
they
have
the
ability
that
to
completely
sidestep
and
heavily
paralyze
the
access
to
services
and
we're
seeing
this
show
up
in
the
data
as
well
right.
So
if
you
go
to
stack
overflow,
the
trends
have
changed
dramatically.
Everyone
used
to
seek
this
full
stack
server
in
front
and
combined
framework,
and
now
it's
all
conversations
surrounding
around.
Ok.
How
do
you
use
react
to
make
an
API
call
to
this?
A
How
do
I
combine
view
with
graph
QL,
so
the
conversation
global
is
also
being
delineated
in
this
way
and
again
we're
seeing
it
in
the
data
in
a
very,
very
dramatic
way.
So
the
idea
that
kind
of
makes
this
happen
is
that
you
can
use
a
lot
of
JavaScript
to
sort
of,
whereas
you
would
have
use
it
on
the
backend.
You
can
now
use
it
on
the
front-end.
You
can
query.
A
Api
is
whether
you
do
it
at
build
them
or
on
the
front-end
and
there's
also
this
sort
of
entry
point
that
is
a
markup
of
your
project
and
what's
interesting
from
a
scalability
standpoint,
is
that
two
out
of
those
this
three
are
naturally
serverless
right.
So,
like
you
can
build
out
two
of
the
third
two-thirds
of
this
stack
completely
statically
and
the
rest
you
can
define
you
can
defer
two
ways
of
scaling
and
ways
of
executing
code
in
a
secure
manner
without
using
servers.
A
So
this
translates
into
a
world
where
again,
the
front-end
developer
not
only
is
skipping
the
idea
of
setting
up
a
server.
There
is
no
need,
there's
absolutely
no
requirement
and
there's
two
examples
that
I'd
like
to
talk
about
here.
There's
probably
in
this
room,
two
types
of
people,
those
of
you
that
spend
a
lot
of
time
on
Twitter
and
those
of
you
guys
spend
a
lot
of
time
in
LinkedIn
in
hybrids
that
spend
a
lot
like
me.
A
They
spend
a
lot
of
time
in
LinkedIn
and
Twitter
and
don't
do
any
work
at
all
during
the
day.
So,
what's
interesting
about
these
two
applications
is
that
they
recently
completely
revamped
themselves
right.
So,
like
Twitter
started
as
a
project
of
being
a
mobile
website
and
then
is
sort
of
succeeded
very
organically
and
it
can
kind
of
became
twitter.com
and
Linkedin.
It
was
kind
of
a
similar
situation,
but
what's
interesting
about
these
two
apps
is
that
they
both
boot
up
to
just
a
static
markup.
A
When
you
launched
this
apps,
they
kind
of
are
behaving
more
like
their
iOS
counterparts.
You
boot
up
to
them,
and
you
see
the
Twitter
bird
and
then
you
see
a
skeleton,
and
then
you
see
data
being
loaded
in
parallel
which,
as
you
imagine,
they're
acquiring
their
own
API,
but
in
in
a
modern
application
you
could
put
in
multiple
API,
so
I
get
mentioned
kind
of
concurrently.
So
this
to
this
to
you
why
primitives
are
signaling
to
me
that
they're
moving
on
to
adopting
this
model
at
a
scale?
A
So
really,
this
is
really
changing.
How
we
think
about
the
entire
development
lifecycle
from
education
and
training
is
an
example
that
I'd
like
to
give,
because
we're
all,
probably
here,
familiar
with
the
nascent
ways
of
learning
about
programming.
What
we're
seeing
broadly
is
that,
if
you
go
to
a
coding
school
today,
you're
probably
being
taught
a
front
and
stack
like
react
and
redux
and
style
components
we're
seeing
the
proliferation
of
developing
directly
in
the
browser
right.
So
tools
like
code
pen
or
code
sandbox.
A
They
even
bundle
technologies
like
web
pack
directly
in
the
browser,
so
they're
mixing
the
medium
that
you're
using
to
develop
with
the
medium
that
you're
using
to
deploy
or
the
actual
application
medium
or
even
the
trajectory
of
the
web
inspector
that
is
evolving
to
become
the
tool
that
you're,
also
using
to
edit.
So
web
inspector
today
has
tools
for
even
persisting
CSS
back
to
your
editor
and
even
the
tutorials
right
so
like.
A
If
you
compare
the
experience
of
learning
any
back-end
language,
that
sort
of
traditional
native
stack
to
the
idea
that
you
just
opened
web
inspector
you're
editing
the
web
front-end
directly
now
I
like
to
talk
about
this
in
the
context
of
someone
getting
started.
But
there
is
even
an
interesting
aspect
of
that
when
it
comes
to
debugging,
when
you
adopt
a
front-end
focus
stack
such
as
this,
for
example,
when
an
exception
occurs,
you
have
one
area
of
debugging
surface
to
worry
about.
You,
don't
have
sort
of
this
duality
between
server
and
Franta.
To
worry
about.
A
You
have
one
security
model
to
worry
about
so
like
now.
All
you
know
is
that
there
is
a
bunch
of
static
assets
being
shipped
to
a
client,
and
there
are
gonna
be
execute,
execute
it
in
a
safe
manner
and
you're
gonna
control,
the
authentication
and
a
CL
medium
back
to
the
server
when
it
comes
to
development
is
what
we're
seeing
the
biggest
transition
of
all.
So
what
next
J
is
pioneered
among
other
things.
Is
this
idea
that
hot
module
replacement?
A
It's
not
something
that
you
configure
hot
module
replacement
is
something
that
is
an
invariant
to
this
model
and
we're
benefiting
here
from
this
ability
of
just
shipping
J's
back
and
forth
from
your
local
environment
to
the
browser.
So
this
quick
video
is
a
little
bit
of
sped
up,
but
we
recorded
it
because
we
wanted
to
show
how
easy
we've
made
it
specifically
because
of
this
ability
to
see
to
have
this
direct
contact
with
your
creation.
A
We
kind
of
bootstrap
this
hacker
news
clone
from
scratch
in
just
a
few
minutes
and
everything
from
CSS
to
your
real
components,
to
the
patient
navigation
system.
It's
all
kind
of
provided
by
by
next
year's
for
you,
so
the
development
experience
is
drastically
superior
to
what
we've
been
used
to
with
regards
to
like
traditional
server
stacks
when
it
comes
to
design
we're.
Seeing
some
of
the
most
interesting
changes
as
well.
A
I've
recently
turned
my
attention
to
a
stack
that
is
becoming
really
popular
in
combination
with
neck
j/s,
which
is
tailwind,
and
we
kind
of
see
the
same
story
here.
Not
only
are
we
targeting
the
browser
but
we're
starting
to
develop
the
design
develop,
obviously
because
of
HMR,
but
we're
also
starting
to
design
directly
in
it.
So
there's
a
bunch
of
screencaps
on
the
web.
That
kind
of
show
off
this
idea
that
you
started
with
markup
you
throw
in
a
bunch
of
well-thought-out
classes
and
you're
practically
just
designing
directly
in
the
browser.
A
So
this
is
kind
of
the
testament
to
this
idea
of
the
role
of
the
developer
and
the
role
of
the
design
or
a
kind
of
conversion
into
one
I.
Think
when
you
have
the
right
primitives
to
start
with
combined
with
this
front-end
medium
that
allows
you
to
like
just
see
your
changes,
reactively
you're,
effectively
designing
in
the
browser
and
another
close
example,
that
is
the
heir
to
github.
A
So
not
only
are
you
able
to
move
very
quickly
if
you
focus
on
front-end,
but
if
you
combine
a
front-end
that
has
already
all
these
primitives
that
have
been
built
up,
for
example,
in
the
form
of
a
reusable
component
system,
then
you
move
even
faster
and
they
think
for
from
our
perspective,
we
show
a
lot
of
examples
such
as
the
the
next
json',
where,
if
you're
kind
of
always
confined
to
your
local
computer
right.
So
in
this
example,
the
first
thing
that
happened
was
we
boot
it
to
like
localhost
3000?
A
Let
me
see
if
the
yeah,
so
you
you
cannot
run
your
local
development
server
and
you
go
to
localhost,
3000
and
kind
of
the
work
gets
confined
to
that.
You
know
simple
experience
of
the
browser
and
your
editor,
but
we're
talking
about
a
lot
we're
talking
a
lot
about
how
we've
really
simplified
the
stack.
A
We
have
just
a
bunch
of
static
acids
we
have
jas,
we
have
CSS
anything
what's
interesting
here,
is
that
it's
directly
affecting
how
fast
and
how
frequently
we
can
deploy
and
deploy
is
that
technology
that
will
allow
us
to
escape
two
things.
One
is
it
allow
us
escape
localhost
and
share
our
work
more
proactively,
and
the
other
one
that
is
particularly
interesting
is
that
it's
allowing
us
to
work
more
closely
with
the
production
environment.
A
So
when
you
think
about
a
developer
that
is
immersed
in
this
world
of
this
really
nice
separation
that,
for
example,
you
know
having
access
to
JavaScript
HTML
se,
it
says
that
queries,
APs
and
the
backend
provides
a
lot
of
things
really
become
completely
uninteresting.
So
even
the
idea
of
a
container
setting
up
a
deployment
pipeline
configuring
it
setting
up
SSL,
it's
really
completely
uninteresting
to
this
profile
of
developer,
that
is
focused
on
delivering
product
results
and
I.
A
Think
what
we've
really
appreciated
is
that
this
kind
of
profile
worries
a
lot
more
about
the
product
right
so
thinks
about
enabling
or
disabling
features,
customizing
the
component
system,
combining
them,
ensuring
that
there
are
effective
solutions
to
the
customers,
problems,
performance,
light,
house
audits.
These
are
this.
These
are
the
concerns
of
this
type
of
developer.
So
really
what
we
went
from
is
this
world
of
I
had
a
lot
of
config
and
it
had
a
lot
of
state
to
worry
about.
It.
A
Had
a
lot
of
clusters
and
containers
I,
don't
have
anything
other
than
a
URL
that
it
kind
of
deploy
with
one
command,
and
that
gives
me
access
to
a
snapshot
of
that
kind
of
front-end.
Heavy
work
that
I
was
doing
and
what's
interesting
as
well,
is
that
one
of
the
particular
integration
points
of
this
system
is
the
code
review
process
right.
So
when
you
first
interact
with
this
continuous
deployment
technology,
you
can
add
it
on
top
of
your
git
workflow,
so
that
every
push
and
every
PR
gets
automatically
deployed.
So
what
happens
really?
A
A
And,
of
course,
you
will
continue
to
write
and
read
code,
but
there
is
an
argument
to
be
made
about
being
a
lot
less
reliant
on
that
idea
of
just
reading
a
diff
and
then
optimistically,
merging
and
hoping
that
you
got
your
tests
right
and
in
fact,
this
profoundly
impacts,
even
the
way
that
you
do
tests
and
I'll
talk
about
that
a
little
bit
later
on.
So
what
it
looks
like
in
the
context
of
your
github
system
is
when
you
install
our
app,
is
this
now
it'll,
deploy
it
automatically?
A
Every
push
that
you
made
us,
you
see
on
the
right-hand
side
gets
its
own
deployment
property
now
what's
interesting
here.
Is
that
we're
registering
a
check,
but
we're
also
telling
github
that
we
have
a
deployment,
and
this
is
kind
of
one
of
the
very
interesting
features
of
this
system
is
github
knows
there
is
a
deployment,
so
I'll
show
you
a
quick
demo
earlier
today,
I
was
on
github
and
I
was
on
the
explore.
A
Tab
and
I
came
across
a
very
interesting
project,
so
it
was
a
new
way
of
creating
a
credit
card
form
that
was
originally
written
in
view,
and
this
woman,
Jasmine
am
if',
decided
I'm
gonna
pour
it
over
to
react,
and
this
looks
great
I
have
you
know
the
ability
to
see
exactly
how
it
works,
but
it
was
kind
of
like
looking
around
it
was
like.
Okay.
I
would
like
to
try
this
out.
So
what
we
did
is
we
told
this
user?
Hey?
A
How
about
you
deploy
it
right,
because
by
deploying
it,
you
now
can
give
everyone
the
ability
to
interact
directly
with
it
and
because
we
know
it's,
you
know
a
simple
front-end
project.
It
should
be
very
easy
to
deploy
so
I'm
gonna
go
and
open
sort
of
our
project
creator
tool
here,
I'm
gonna,
say
I
want
to
deploy
under
guillermo
rauch,
and
it's
coming
from
this
repository
and
then
I'm
gonna
say
that
actually
also
want
to
clone
it
for
myself
and
I
want
to
create
a
private
repo.
A
So
it's
gonna
take
all
the
code
that
was
in
that
repo.
It's
gonna
create
a
variable
for
myself
on
github,
but
obviously
it's
not
gonna.
Stop
there
what's
interesting
about
this
is
okay
now
I
have
that
foreign
code
and
I
want
to
get
this
URL
back.
That
allowed
me
to
share
it
with
everyone
in
the
world,
so
my
project
gets
created
and
the
deployment
begins.
So
what's
interesting
is
deployment
when
I
talked
about
this
idea
of
oh
there's,
just
HTML
and
CSS,
it's
kind
of
an
overly
simplistic
view
of
too
this
front
in
the
world.
A
Today's
front
in
the
world's
a
little
bit
more
complicated
than
that.
There
is
usually,
for
example,
a
build
process
right.
So
this
example
is
that
create
react,
app
application,
so
I'm
gonna
briefly
show
you
the
logs.
Ok,
it's
already
deployed
so
I'm
gonna
show
you
what
it
looks
like
really
quickly.
So,
instead
of
my
gift,
I
now
can
interact
with
it.
I
have
my
deployment.
It
has
obviously
its
own
unique
URL
that
I
can
share
with
anyone.
A
It's
live
rather
than
you
know
code,
but
what's
interesting
too,
is
that
the
system
automatically
built
and
pushed
to
production
the
code
that
was
already
on
github
and
I
have
the
ability
to
do
so,
not
only
for
just
this
initial
version,
which
we'll
call
our
production
deployment,
but
it
can
do
it
for
every
push
in
the
future.
So
this
is
where
it
gets
even
more
interesting
right.
So
I
mentioned
earlier
that
I
got
my
own
copy
of
the
repository
right,
so
I
completely
stole
this
repository.
Is
private
I?
A
Have
the
ability
to
animate
I
use
a
big
awesome,
github
UI
here
I?
Have
the
ability
to
continue
to
make
edits
to
this
and
without
affecting
production?
I
can
create
this.
Let's
call
it
code
review
that
is
actually
based
on
actual
improvements
and
I
apologize.
I
can't
see
much
so
I'm
gonna
do
an
atrocity
here.
I'm
gonna
add
some
code,
so
the
github
inline
editor
has
a
very
convenient
feature
here,
which
is
that
it
it
could.
A
It
could
commit
directly
to
my
master
branch,
but
I,
don't
even
know
if
that
looks
good,
but
instead
I
can
propose
a
file
change
that
can
later
on
become
a
poor
request.
So
I
now
have
my
code
change.
Let's
take
a
really
quick
look
at
it.
Ok
again,
it's
code,
I
cannot
see
what
it
looks
like.
So,
let's
instead
create
a
pull
request,
and
typically
here
is
where
the
workflow,
especially
for
a
product,
focus
team
kind
of
breaks
down
right
because
ok,
it
made
a
visual
change
to
my
project.
A
How
come
all
I
get
is
a
boring
code.
If
I
want
to
see
what
it
looks
like
so
as
I
mentioned,
we
cannot
go
through
the
process
of
building
and
and
reading
your
project
and
then
we're
gonna,
give
it
a
unique
URL.
So
my
ugly
addition
to
these
beautiful
projects
there
and
again
I
get
this
sort
of
unique
snapshot
of
my
front
and
that
I
can
share
with
my
team
now.
This
idea
of
just
sharing
with
your
team
is
not
entirely
new.
It
really
it's
not
entirely
new.
A
This
has
been
done
before,
but
what's
happening
that
we're
sort
of
seeing
every
day,
and
it's
becoming
more
obvious
to
us
every
day
through
multiple
improvements
that
we've
made
it.
The
underlying
system
is
that
the
constraints
that
this
has
to
have
tremendous
benefits,
one
that
is
really
obviously
it's
it's
dramatically
faster
to
deploy
its
zero
config
notice.
That
I
took
a
random
project
that
was
on
github
trending
today,
the
beautiful
sort
of
card
thing,
and
they
just
added
it.
A
Interestingly
enough,
it
has
no
single
point
of
failure,
because
that
URL
is
kind
of
it
has
the
ability
to
like
infinitely
scale
and
kind
of
show
up
everywhere.
Without
you
know,
being
down,
and
things
like
that
and
as
I
mentioned
earlier,
there's
this
advantage
of
a
security
model.
It
just
is
very,
very
easy
to
understand
so,
as
I
mentioned,
I
think
that
the
benefits
of
getting
this
URL
for
every
step
of
evolution
to
your
code.
A
It's
interesting,
perhaps
not
entirely
new
until
you
start
considering
sort
of
the
performance
improvements
or
the
features
of
the
model
when
it
comes
to
scaling
and
distributing
your
project.
But
I'm
gonna
talk
about
where
this
gets
really
really
interesting.
So
I
mentioned
earlier
that
that
URL
that
a
god
is
as
good
as
any
other
production
URL,
including
it,
for
example,
the
definitive
domain
of
your
project
like
google.com,
they
could
say
I'm
gonna,
deploy
that
beautiful
credit
card
form
to
Google
com.
A
So
you've
probably
heard
of
the
this
idea
of
testing
and
production,
and
obviously
when
I
say
this,
a
lot
of
you
are
like
oh
testing
in
production,
now,
I,
don't
even
deploy
in
a
Friday
night
and
then
I
test
in
production.
But
there
are
two
features
here
that
are
interesting
is
one:
is
the
environment?
Is
the
same
right
so
like
that
URL
had,
even
though
it
didn't
have
the
exact
domain?
For
example,
it
has
an
environment
that
completely
mirrors
production.
A
It's
served
by
the
same
city
and
the
CDN
behaves
with
interesting
features
like
caching
and
etags
and
rewrites,
and
all
kinds
of
different
features,
but
it's
gonna
be
consistent
with
how
production
works
when
it
comes
to
testing
my
back-end,
it
gives
me
the
ability
to
go
directly
to
the
real
data
source.
So
in
a
lot
of
cases,
when
you
have
an
API
like
your
graphical,
API
or
you're
acquiring
a
headless
CMS,
you
have
the
ability
to
this
new
front-end
query.
The
actual
data
that
then
the
eventual
front-end
that
goes
to
prod
is
gonna,
is
gonna.
A
Query.
So
I've
been
a
big
proponent
of
this
idea
as
well.
That
real
testing
happens
when
you
mirror
the
end
user.
So
you
can
write
as
many
unit
tests
as
you
want,
but
then
you
went
to
the
credit
card
forum
and
then
there's
a
new
div
that
overlaps
the
input
and
then
I've
lost
all
my
revenue
because
I
don't
know
like
I
can't
type
into
the
input.
A
Next,
to
my
grave,
just
kidding
won
it,
but
they're
they're
fun
when
it's
right
test,
not
too
many,
mostly
integration,
that
is
a
riff
of
eat
food,
mostly
plant,
not
too
much
mostly
plants
and
the
other
one
I
guess
I'm
really
been
on
this
thread
of
really
fun.
Interesting
tweets
is
In,
God,
We
Trust,
all
others
must
bring
into
and
tests,
and
it
probably
said
that
when
we
didn't
have
it
into
and
test
and
it
was
kind
of
reminiscing
on
what
would
have
happened.
A
What
could
have
been
so
the
interesting
thing
about
that
URL
that
I
talked
about
is
that
it
really
becomes.
It
really
puts
the
deployment
at
the
center
of
gravity.
All
I
do
every
day
from
the
moment.
I
wake
up
to
the
moment
go
to
bed
is
deploy,
deploy,
deploy
and
deploy.
That's
all
I
do
so.
The
deploy
URL
is
sort
of
this
sort
of
center
of
gravity,
and
the
interesting
thing
is
that
once
I
have
that
prod,
ready
or
L,
there
is
an
ecosystem
of
possibilities
and
applications
that
opens
up
to
me.
A
For
example,
I
can
perform
end-to-end
tests
against
that
I
can
perform
screenshot
diffing,
so
I
only
talked
about
okay.
What
happens
if
a
div
moved
on
to
my
input
and
all
my
unit
tests
pass,
but
all
of
a
sudden
can't
type
I
can
actually
div
what
it
looks
like
I
can
may
make
assertions
about
content
being
returned
by
the
HTML
or
content
appearing
in
my
functional
responses.
A
I
can
make
assertions
about
performance
and
conformance
I
can
do
cross
browser
testing
like
do
some
really
quick
boot
it
up
in
Safari
and
hope
it
doesn't
break,
and
things
like
that.
I
can
actually
do
that.
Really.
Scalable
user
testing
by
shipping
that
URL
to
a
set
of
people
that
are
gonna,
give
me
feedback
on
it,
and
I
can
get
feedback
internally
much
more
quickly
from
my
own
team.
Obviously,
and
I
can
do
my
as
much
manual
QA
as
I,
want
right.
A
I,
give
you
this
URL,
typically
on
on
slack
or
or
JIRA
and
say,
hey,
take
a
look
at,
and
just
tell
me
if
this
feels
good,
for
example,
things
that
it
might
not
be
as
easy
to
do
automatically
so
in
practice.
This
is
enabled
by
that
property
that
I
mentioned
earlier,
which
is
that
our
system
will
signal
that
there
is
a
deployment.
So
it's
not
just
a
regular
check
like
it
will
be
with
circle
CI,
for
example,
or
Travis
CI,
or
get
up
actions,
but
it's
a
deployment
right.
A
A
So
we
started
to
create,
with
this
github
app
check
lis
a
lot
of
the
critical
user
stories
that
we
want
to
have
the
certainty
that
they
get
completed
before
we
merge
the
master.
So
our
system,
right
now
in
combination
with
github,
then
creates
a
gravity
around
deployment
that
enables
a
bunch
of
super
interesting
applications
to
do
things
that
you
typically
were
doing
earlier,
either,
maybe
not
completely
or
you
were
doing
them
with
code
and
perhaps
now
there's
tools
that
allow
you
to
do
it
with
beautiful
UI.
A
It's
a
great
example
is
that
we
used
to
write
tests
like
into
and
tasks
with
a
lot
of
code,
or
we
used
to
get
more
distracted
by
unit
tests.
But
now
I
sold
chocolate
for
someone
to
say:
hey
go
here,
click
this
click
that
boom
off
to
the
races,
and
not
only
are
we
able
to
test
more
effectively
and
ship
with
more
confidence,
but
we
can
also
ship
with
less
confidence,
which
is
very
interesting.
So
typically,
the
behavior
of
our
system
is
that
you
merge,
and
that
goes
to
prod.
You
merge
goes
to
prod,
ok.
A
So
if
I
had
a
truckloads
of
confidence
here,
because
everything
passed,
we
have
the
five
systems
of
testing.
It's
pretty
insane,
so
super
confident,
so
you
merge
and
you
go
live
and
even
probably,
during
this
talk,
my
team
has
been
doing
that
right
because
they're
so
confident,
but
in
reality
there's
always
the
stuff
that
goes
wrong
right
like
like
we're,
not
perfect,
and
we
always
want
to
balance
agility
with
you
know.
You
know
the
ability
of
making
reasonable
mistakes.
A
So
an
interesting
property
of
this
is
that
you
can
very
quickly
revert
your
pr's,
so
I
mentioned
earlier
that
every
push
gets
a
deploy,
which
means
that
when
you
revert
likely
that
deployment
that,
in
this
case,
for
example,
to
maybe
20
seconds,
already
existed,
so
we
automatically
diff
and
we
apply
the
previous
deployment
at
with
zero
milliseconds,
not
20
seconds.
So
this
is
a
fairly
good
property.
Really
fast
reverts
will
increase
your
ability
to
confidently
ship
with
no
confidence
but
toward
the
future.
A
We
envision
even
better
ways
of
experimenting
so
we're
starting
to
integrate
with
third-party
providers
to
do
this.
But
basically,
when
you
build,
for
example,
your
next
project
you
can
tell
next,
yes,
hey
I,
want
this
page
to
have
two
variants
and
I
want
this
variant
to
have
access
to
a
smaller
percentage
of
the
traffic,
and
that
in
itself
is
pretty
good,
because
you're
constrained
the
delivery
of
a
new
feature
to
smaller
set
of
users.
A
But
what
we
are
able
to
do
as
well
is
that
we're
able
to
get
data
from
it
right
so
there's
a
constant
flow
that
completes
the
feedback
loop,
where
if,
for
example,
tools
like
century
tell
us
hey,
there
is
an
increased
exception
rate
on
this
new
page
that
you
just
shipped,
and
you
were.
You
know
it
works
great
on
Chrome,
but
going
back
to
the
example
of
testing,
it
is
common
that
we
test
more
with
headless
browsers
like
puppeteer.
So
what
about
Firefox?
Ok,
you
might
have
missed
it.
A
A
The
system
that
we've
evolved
over
the
past
few
years,
we're
very
lucky
to
have
amazing
customers
using
it
in
production
and
a
lot
of
you
using
it
on
github
if
they
can
have
a
Pico
system,
but
for
those
of
you
that
haven't
tried
it
yet
the
easiest
way
to
sort
of
recap
everything
that
I've
talked
about
today
is
either
code.
Slash
github
do
not
go
to
sydejko,
slash
gitlab
under
any
circumstances.
A
A
A
As
you
know,
your
pages
that
are
all
gonna
be
your
front-end
pages,
and
then
you
can
say:
okay,
I'm,
going
to
define
a
API
directory
and
I
start
introducing
functions
that
can
bridge
the
gap
between
back-end
and
front-end,
and
the
way
that
we
see
this
in
production
is
that,
for
example,
I
showed
earlier.
Our
system
has
a
the
ability
to
take
screenshots
of
your
projects
right.
So
the
way
that
we
did
that
the
screen
is
gone,
but
the
way
that
we
did,
that
is
like
we
didn't
wait.
It's
putting
on
the
front
and
hat.
A
We
didn't
wait
for
the
API
team
to
figure
out
how
to
create
that,
because
we
knew
that
it
was
a
feature
was
particularly
interesting
to
the
front-end,
but
we
knew
that
it
required
back
in
execution.
So
we
just
find
it
alongside
our
next
Reyes
repo
inside
the
API
pages
directory,
and
then
we
just
deployed
it
all
together
and
has
that
same
cohesion
as
the
front-end
code?
And
that's
why
you
have
this
view
of
build
and
you
have
a
view
of
runtime.
A
So,
like
I,
said
the
broad
trends
that
are
probably
already
going
on
in
a
lot
of
projects,
even
when
they
look
at
things
like
WordPress
and
the
REST
API
plug-in
or
when
they
look
at
how
Rails
has
shifted
toward
being
an
API
server.
A
lot
more.
We
kind
of
find
a
very
nice
cohesion
of
these
two
worlds.
B
With
my
experience
and
with
a
maintaining
a
large
set
of
NN
tests
that
go
against
live
production,
there's
usually
idiosyncrasies
and
those
production
services,
whether
those
services
have
downtime
problems
or
they
have
changing,
perhaps
the
services
you're
baking
on
or
not
as
resilient
or
fault,
tolerant
or
as
predictable
and
reliable.
Have
you
found
anything
as
you've
been
working
with
customers
who
are
using
live
production,
back-end
services?
You
know
any
any
type
of
ways
to
sort
of
help
them
eliminate
positives.
It
may
be
as
a
result
of
service
problems.
I.
A
There
is
also
this
assumption
that
when
you
move
into
kind
of
the
sba
type
front
end,
you
don't
know
that
there
could
be
multiple
versions
of
your
front
end
running
at
any
given
time
right
so
like
the
ability
to
maintain
this
kind
of
backwards,
compatibility
of
the
API
has
been
more
of
a
more
of
a
concern,
I
think
rightfully.
So
anything
is
a
good
thing
because
of
this
front
is
that
load
once
and
perhaps
you
have
them
open
for
very
long
sessions
right
I.
Think
for
me,
Twitter
is
a
great
example.
A
Right
like
and
I
very
hardly
ever
refresh
that
so
the
versioning
being
mindful
with
versioning
of
your
production
api's
will
allow
that
this
system
continues
to
sort
of
have
this
congruence
of
oh
yeah.
I
can
confidently
run
my
test
and
it's
gonna
go
to
like
data
that
works
and
when
it
comes
to
flakiness
I
think
that's
interesting
right.
We
debate
this
a
lot
and
I
think
the
flakiness
of
your
end-to-end
test
kind
of
creates
this
lower
bound
on
the
flakiness
of
your
user
experience.
A
So
I
think
if
I
experienced
that
flakiness
with
some
of
these
systems
that
we've
configured
it's
just
some
flakiness,
that
the
end
user
would
like
at
least
some
subset
of
end-users
would
experience
now.
It
is
true
that
maybe
that's
within
your
tolerance
of
your
SLA
targets
or
the
quality
of
service
that
you
want
to
provide
so
apps
like
check
Lee,
and
we
work
very
closely
with
that
company
allowed
you,
for
example,
to
retry
some
of
the
assertions
that
you
think
are
more
complex
or
have
more
time
variants
or
will
allow
you
say
this.
A
One
I
don't
care
as
much
about
it's
an
interesting
data
point.
If
it
passed,
but
it's
not
required
so
I
think
github
checks
in
that
sense
are
very,
very
useful
and
going
back
to
that
idea
of
it
really
allows
you
to
ship
without
even
seeing
the
code,
which
is
obviously
a
pipe
dream.
You
have
to
do
code
reviews,
but
one
thing
that
we've
we've
done
is
we
installed
a
bot
called
Kodiak
that'll
automatically
merge
certain
categories
of
pr's.
A
If
all
the
tests
pass-
and
we
can
do
that
with
quite
a
high
degree
of
confidence
like
we
send
that
PR
all
the
checks
fast
and
in
order
merges
so
the
PR
kind
of
becomes
they
kind
of
like
dumpster
fire
like
if
it
didn't
tautomer
j--
and
it
fell
in
their
categories
of
the
ones
that
should
oughta
march.
Then
it
becomes
a
thing
that
you
have
to
put
your
attention
on
because,
like
hey
like
something,
went
wrong.