►
Description
Delivering the code to from the development environment to staging and production, usually tends to involve a series of manual steps, tweaking, fairy dust, and hoping for the best. Developers all dream for Continuous Delivery, where a good chunk of this work has been automated, and at the push of a button, it all happens.
For the past year, Heroku has been working on addressing this. Guðmundur Bjarni Ólafsson describes a structured workflow for Continuous Delivery, called Heroku Flow.
Guðmundur Bjarni Ólafsson is a Software Engineer on the Developer Experience team at Heroku. For the past year or so, he has been working on Heroku pipelines, GitHub Sync integration and review apps.
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
So
Heroku,
how
many
of
you
have
used
to
Roku?
Okay,
like
a
few
of
you
doing
the
selfie
thing
before
yeah,
so
Miroku
is
a
platform
as
a
service,
so
what
we
do
is
make
it
ridiculously
easy
to
run
code
that
you
have
in
the
cloud.
So
you
basically
push
the
code
to
Roku
and
we
manage
it
for
you.
We
run
it.
So
we
take
away
a
lot
of
the
operational
burden,
and
on
top
of
that,
like
we
support
a
lot
of
languages,
I
think
out
of
the
box.
A
We
support
nine
or
ten
different
languages
at
this
point,
and
we
also
have
support
for
something
called
add-ons.
So
if
you
need
a
database,
it's
real
easy
to
set
that
up
or
if
you
need
something
to
like
pipe
your
logs
to.
We
also
have
that
so
yeah.
What
I'm
gonna
do
is
just
go
through
a
quick
demo
of
what
Roku
is
so.
This
is
a
repo
that
I
have
on
github.
It's
you're
familiar
with
it
to
do.
When
we
see
thing
this
is
basically
an
API
that
does
that.
So
this
is
built
in
Ruby.
A
It's
using
something
called
pliny.
So
funny
is
say,
open
source
project
that
we
have,
which
I
highly
recommend
that
you
check
out
if
you're
doing
AP
is
it
takes
a
lot
of
local
food
production,
ization
burden
away
so
like
it
has
same
defaults
for
things.
So
if
you
go
go
like
github
pliny,
that's
going
to
be
the
thing
that
pops
up,
but
this
is
an
example
app
like
using
finding.
A
This
is
like
I'm
gonna
give
a
demo
of
like
this
dope.
We've
been
building
and
I'm
going
to
use
this
like
a
repo
as
an
example
of
that.
So
to
start
with-
and
some
of
you
did
this
before
today,
like
get
code
from
github
and
push
it
to
her
okay,
so
like
what
I'm
going
to
do
is
I
clone
the
repo
that
I
had
before
and
we
have
it
locally
and
we
open
up
the
folder.
We
take
a
look.
A
It's
the
same
code
as
in
the
repo
we
create
an
app
like
many
of
you
did
before
so
get
up.
Satellite
production,
that's
the
name
of
that.
You
can
see
two
year
olds.
One
is
the
like
the
web
front
end
and
the
other
one
is
the
get
remote.
So
you
can
start
pushing
to
that
thing
now,
but
this
is
an
app
that
meets
the
database.
A
A
So
it's
a
little
slower
than
you
usually
like
for
subsequent
builds
and
now
like
this
has
been
deployed
and
we
can
just
curl
the
endpoint
just
make
an
API
call
to
it
if
I
can
type
it
for
a
clean
and
there
you
see
like
Hello,
that's
the
default
endpoint
for
the
app.
I
had
the
database
setup,
but
I
didn't
run
any
of
the
migrations
like
it
doesn't
have
any
schema.
So
that's
the
thing
I'm
doing
here
so
I'm
just
running
a
one-off
process
that
loads
all
of
that
stuff
up
and.
A
There
we
go,
we
have
the
database
setup
with
all
the
user
tables
and
to
do
tables
and
the
app
needs
a
restart.
So
it's
restarting
all
the
Dinos
because
then
Mike
the
schema
has
to
be
loaded
again.
So
now
we
can
call
the
api
an
actual
endpoint,
which
is
the
slash
users
endpoint,
and
we
post
to
that
to
create
the
user
and
created
print
it
and
bam
there
we
go,
and
so
this
is
like
one
of
the
things
that
rogue
does
it's
like
ridiculously
simple:
to
set
up
apps.
A
You
can
do
more
things
like
if
you
need
conflict
for
eyeballs
of
any
sort
like
unique
credentials
for
your
amazon
account.
You
can
do
that.
We
can
also
do
like.
Let's
run
this
on
ten
instances,
instead
of
like
only
a
single
container.
So
what
I
mean
by
instances
it's
kind
of
like
containers,
if
you
use
docker
containers,
so
we
container
eyes
everything
yeah.
So
that's
like
one
of
the
things
you
get
out
of
the
box.
A
Do
you
guys
realize
like
we
just
did
this
and
that's
pretty
cool
and
for
only
features,
I'm
going
to
show
you
how
long's
will
show
like
some
of
the
internals,
like
the
api,
calls
that
we're
making
both
to
Heroku
and
github
there's
all
this
stuff
for
the
most
part
it?
Actually,
it
actually
runs
all
of
it
on
the
Viroqua
platform,
but
we're
not
using
any
special
endpoints
I
mean
there
are
a
few
cases
where
we
do
that.
A
But
for
the
most
part,
this
is
all
a
user
land
us
developers,
you
can
actually
use
that
and
and
also
I'll
go
through
like
some
of
the
challenges
we
have
while
building
this
stuff.
So
hopefully
you
can
take
some
learnings
from
this,
so
you
don't
run
into
the
same
issues.
So
the
team
I'm
on
it's
called
developer
experience
we're
a
team
of
a
few
guys
and
you
can
see
there
in
the
picture
I'm
not
on
it,
but
there's
a
in
the
middle,
a
designer,
let's
also
based
in
UK,
he's
an
awesome
guy.
A
So
he
can
stand
in
for
me
on
that
picture.
Oh
yeah
we're
two
to
three
engineers:
a
dedicated
designer,
a
dedicated
product
manager
and
a
half
time
engineering
manager.
So
one
of
the
guys
is
both
engineer
and
data
manager.
The
team
has
a
lot
of
autonomy
and
agency,
and
by
that
like
we
basically
have
free
reigns
over
what
we
do.
I
mean
we
need
some
support
from
product
and
stuff
like
that,
but
our
lives
is
to
make
developers
lives
awesome.
A
So
we
basically
feel
like
this
would
be
a
cool
thing
to
do
and
it
would
help
people
so
we
go
and
build
that,
and
the
way
we
work
is
that
we
do
a
lot
of
kind
of
fast
iterations.
So
we
do
something
like
scrum
Kanban
ish
and
we
try
to
do
four
to
five
iterations
/
weeks,
where
we
actually
ship
something
to
users.
A
So
we
do
like
small
increments,
and
we
do
them
fast
and
the
question
we
always
ask
ourselves
is
like
what
is
the
next
most
important
thing
and
I
don't
mean
that
in
the
terms
like
for
me
as
the
engineer
but
more
like
for
the
customer
like
what
is
the
most
valuable
thing
we
can
give
the
customer
and-
and
if
you
don't
know
about
the
lean
startup
method,
ology
a
lot
of
the
stuff
we
do
aligns
with
that.
Another
thing
is
like
experiment,
so
one
of
the
features
I'm
going
to
show
you
later
called
review
apps.
A
That
was
actually
an
experiment
that
we
did
when
we're
doing
the
get
up
integration
that
I'll
show.
Also
in
a
bit,
we
thought
like:
hey,
wouldn't
it
be
cool?
If
we
did
this,
so
we
took
like
a
week
or
two
to
do
that,
and
we
actually
got
something
working
and
shipped
it
to
users,
and
it's
super
useful,
so
we
actually
pick
them
up
as
a
proper
project
and
went
on
from
there.
A
A
So
you
have
to
be
okay
with
just
like
throwing
out
whatever
you've
been
doing
for
the
past
few
weeks
and
like
as
an
engineer
that
just
wants
to
build
saying
that
can't
be
a
bit
painful,
sometimes,
but
it's
all
about
like
making
other
people's
lives,
it's
better,
so
so
using
pull
request
to
drive
continuous
delivery
like
let's
get
back
to
that.
So
the
first
feature
with
it
is
something
called
get
up
saying
and
the
motivation
for
doing
this
was
basically
like
deploying
directly
from
github
should
be
like
fairly
obvious.
A
A
So
that's
like
in
spirit
of
the
experiments
and
like
fast
iterations
that
we
doing
we
went
to
private
beta
in
a
week,
public
beta
like
which
is
like
thousands
of
users
like
within,
like
what
was
it
like
two
months
and
then
four
months,
like
alongside
other
projects
that
we
did
like
we
went
to
GA.
So
this
is
like
a
baked
in
feature
to
the
platform.
A
So
remember
what
I
showed
you
before
like
this
get
push
heroku
master
thing,
so
it's
basically
getting
rid
of
all
this
and
just
like,
let's
not
be
silly
and
just
deploy
directly
from
github
and
so
to
get
there
I
kind
of
want
to
take
a
look
at
the
API
calls
that
we're
making
and
when
I
started
on
roku
get
pushed
Roku
master
was
the
only
thing
you
can
do.
There
wasn't
an
API
to
create
bills.
Girl
fails.
So
this
is
one
of
the
first
projects.
I
worked
on,
so
I,
don't
know
when
you
can
like.
A
Can
you
see
it
in
the
back
the
text
there
all
right,
so
it's
a
post,
endpoints
we
post
to
your
app
a
built
and
you
have
a
link
to
a
tarball.
So
terrible
is
just
like
a
compressed
file
with
all
the
stuff
in
your
repo
and
one
of
the
things
that
gives
you
back
is
a
streaming
URL.
So
it's
a
URL
you
can
connect
to
and
it's
something
SSE
like
stuff
and
you
can
get
like
a
streaming
build
output
like
you
saw
with
git
push.
A
So
this
is
in
the
Iroko
API.
This
is
like
one
of
the
primitives
we
have
and
then
on
the
github
side
there
is
the
same
called
get
archive
link
and
you
can
say,
hey
give
me
a
tarball
of
all
the
stuff
in
the
repository
and
like
there
are
a
few
things
to
note
about
this.
Api
one
is
that
there
are
no
sub
modules
that
you
get
so
anyone
using
sub
modules,
okay,
good,
and
so
this
will
all
work
for
you
guys
and
then
there's
this
note
up.
A
There
that
says,
like
for
private
repository
these
links
or
temporary
and
expire
quickly,
and
that
is
not
a
joke,
so
they
expire
in
like
a
few
seconds
so
like
when
we've
had
like
some
capacity
issues
on
the
build
system
like
it's,
not
picking
up,
builds
right
away
like
few
seconds
pass
and
this
link
is
expired.
Phil
bet
failed
built.
A
I've
already
authenticated
with
github,
so
I
have
like
the
organizations
that
I
can
connect
to
and
in
a
minute
it's
gonna
yep
there
we
go
it's
opening
that
up
and
it's
my
personal
org
and
then
I
type
in
whiny
to
do,
which
is
the
repo
I
had
before
and
search
and
connect,
and
now
this
row
crap
that
I
did
before
it's
connected
to
that
repository.
So
there's
a
one-to-one
mapping
between
the
repo
on
github
I'm,
this
app
on
her
okay.
The
next
thing
I
want
to
show
is
manual
deployments.
A
So
that's
like
from
this
dashboard
deploying
code
from
github
to
roku
and
the
way
we
do
that
we
you
can
see
down
there.
This
manual
deploy
I,
hope
you
can
see
it.
I
was
hoping
for
like
a
big
screen,
so
everyone
would
see.
So
this
is
like
the
master
branch
and
we
hit
deploy,
and
then
you
can
see
that
it's
fetching
the
code
from
github
and
then
it
says,
built
master
and
you
can
see
the
streaming
output.
So
it's
the
same
as
you
saw
in
the
terminal,
but
it's
just
coming
through
the
dashboard.
A
Now
then,
there
we
go
and
if
you
hit
the
link,
we
get
the
same
hello
as
before,
so
it's
basically
playing
the
same
code
again,
but
through
github
broth
and
through
the
terminal
and
but
like
manual
deployments,
are
turn
up
but
like
wouldn't
it
be
cool.
If
you
could
have
it
happen
automatically
so
I
merged
something
into
master
like
it
would
kick
things
off
by
itself.
So
the
get
up
API
has
this
thing
called
web
hooks
and
the
web
hook
is
basically
wants
something
changes
on
your
repo.
A
You
get
a
notification
about
it,
so
it's
an
HTTP
call
that
you
get
and
there
is
a
lot
of
different
types
of
events
that
you
can
get
and
the
ones
we
are
interested
in
now
it
is
push
so
you
need
to
set
up
these
hooks
through
the
API
and
there
is
this
section
called
wild
card
event.
So
if
you
do
set
up
hooks
like
please
use
that
because
otherwise
you
have
to
migrate
all
the
hooks
that
you've
set
up
to
use
like
the
different
events
that
you
need.
A
So,
while
cut
events
they're
your
friends,
please
do
that
in
the
push
event.
If
you
look
into
that,
you
can
see
there,
we
go,
it
has
like
a
raft,
so
it
tells
you
like
master
changed
and
it
tells
you
the
get
Shah
of
that
commit
and
it
gives
you
like
who
made
the
push
and
which
commits
are
in
it
and
all
that
stuff
so
from
there
to
enable
automatic
deployments
through
our
dashboard.
It's
just
hitting
that
button
and
from
there
on
like.
If
someone
pushes
to
get
up
on
the
master
branch
it
automatically
deploys.
A
But
you
have
this
other
feature
which
is
wait
for
CI
and
if
you
have
Travis
or
circle
or
something
then
it'll
automatically
waits
until
you
have
a
green
status
on
the
comment
before
deploying.
So
I'm
not
going
to
show
like
what
this
looks
like
when
you
push
to
get
up
quite
yet
I'll
get
back
to
that.
I.
A
Don't
want
to
spoil
the
surprise
so
another
trick
with
web
hooks
I
want
to
show
is
like
if
you
were
debugging
things
in
the
settings
section
on
the
repo
under
web
hooks
you
have,
whichever
hooks
are
set
up
on
the
repo
and
they
send
me
everything
thing.
That's
a
wild-card
event,
which
is
your
friend
and
and
then
here
at
the
bottom.
You
can
see
the
different
events
that
have
been
sent
and
these
crazy
uuid.
They
are
super
helpful
and
like
what
we
do
with
those
is.
A
We
basically
log
them
out
whenever
we
get
an
event
from
github.
We
log
it
out
and
the
cool
thing
about
that
is,
if
you
have
something
set
up
like
splunk,
familiar
with
splunk
anyone.
So
it's
like,
if
you
have
log
entries
like
lots
of
la
countries,
it's
a
search
cluster,
so
you
basically
dump
all
your
logs
into
that
and
it's
a
search
engine
on
top
of
it.
So
you
can
take
that
delivery,
ID
and
copy
it
into
spunk,
tell
it
to
search
in
the
last
hour
and
voila.
You
have
a
log
entries
relating
to
that.
A
A
So
if
you
ever
have
any
questions
about
github
like
support
at
github
com
like
they
are
the
masters
they
respond
quickly,
they
can
usually
help
out
with
whatever
crazies
you
have
anything
from
like
small
stuff,
too
crazy
technical
details
so
recommend
that
I'm
one
learning
from
this
project
is
that
we
did
not
have
a
public
API
from
the
get-go.
So
we
decided
to
do
like
fast
iterations.
A
Like
will
do
the
API
later,
like
what
problems
are
going
to
rise
from
that,
so
we
were
doing
things
really
fast,
iterating
and-
and
we
forgot
about
doing
CLI,
because
we
were
like
focusing
so
much
and
just
building
the
product
and
the
dashboard
side
of
things.
So
we
don't
have
a/c
alive
for
it.
And
another
thing
is
that,
because
we're
just
going
at
this
like
crazy
speed,
we
didn't
think
too
much
about
like
what
the
internal
data
model
should
look
like.
A
So
here's
just
like,
what's
the
fastest
thing
we
can
do,
and
let's
just
do
that
and
oh
man
like
we
got
into
so
much
trouble
because
we
figured
like
everythings,
we
assumed,
like
I,
want
to
map
one-to-one
mapping
between
it's,
not
a
one-to-one
mapping.
It's
like
crazy
stuff.
So
if
you
have
the
wrong
data
model,
you
have
to
run
some
fun
data
migrations
and
also
like
we're
integrating
with
the
github
API.
So
you
have
to
run
migrations
across
api's
because
we
can't
just
like
give
get
up
a
like
migration
script
like
police
around
this.
A
So
like
doing
this
migration
it
we
were
two
engineers
we
both
started
doing
it
individually
and
basically
failed
like
we
spent
a
whole
day
each
like
trying
to
get
it
done.
But
it's
just
like
this
is
too
much
like
I
can
do
this,
so
we
as
good
software
developers
we
paired
up.
We
made
a
big
plan
on
a
whiteboard
like
well
we're
in
San
Francisco,
and
it
was
like
16
different
pull
requests
that
we
have
to
do
to
migrate
all
this
stuff.
A
A
Wouldn't
it
be
cool
if
you
would
spin
up
like
a
whole
new
Heroku,
app,
that's
isolated
from
everything
else,
ship
the
code
run
all
the
database
migrations
all
that
stuff
and
then
somehow
put
a
comment
or
something
on
github,
so
you
can
actually
click
through
to
the
running
app
and
not
just
review
the
code
on
github
but
actually
see
why
you've
been
building
and
testing
and
one
cool
thing
with
that
that
we
thought
is
like
it's
not
just
cool
for
the
developers.
It's
also
non-developers.
A
So
you
can
have
product
people
take
a
look
at
it
and
like
people
that
don't
necessarily
have
coding
skills.
So
you
can
say
like.
Is
this
like
the
thing
that
you
actually
want
it
and
it's
isolated
from
everything
else?
So
this
is
inspired
by
something
called
for
chat.
So
there
was
one
guy
on
the
team
that
said
this
for
setting
up
for
the
Roku
dashboard,
it
needs
some
tweaking
and
hacking,
but
once
it
was
set
up
like
it
was
awesome,
so
we
were
like
okay,
there's
like
president
for
doing
this
and
the
waning
fourchette
works.
A
It
basically
does
all
these
steps
that
I
did
before,
and
so
we
didn't
want
to
write
like
a
service
that
did
that
and
as
it
turns
out
just
after
the
build
a
p.I,
there
was
another
project
called
app
setups
and
maybe
there's
an
app
that
Jason
there.
You
can
see
that
an
app
that
Jason
is
basically
a
declarative
specification.
What
meets
like
it's
needed
for
this
app
to
run
so
you
can
see
there
is
like
a
Postgres
database.
A
There
is
how
to
run
the
data
migrations,
so
we
have
everything
encoded
in
there
that
you
need
to
run
the
app
also
conflict
whar's
like
if
you
need
a
three
prudential
like
you,
should
not
commit
those
in
there.
You
can
inherit
them
from
like
a
parent
up.
That's
implementation.
Details
like
if
you
set
this
up
you'll
get
to
all
that.
So
the
app
setup
saying
it's.
We
built
it
for
something
called
rogue
button.
So
it's
like
it
was
not
built
for
review
apps
and
like
the
way
that
works.
A
Is
we
get
this
button
on
the
repository
and
you
can
click
that
it
takes
you
to
the
rogue
dashboard.
You
can't
this
UI
and
you
can
just
say,
deploy
this,
so
this
is
instead
of
doing
all
the
cloning
that
I
showed
in
the
beginning
and
setting
it
up,
and
it's
just
like
a
couple
of
clicks
and
you
have
the
app
running
on
roku
and
I,
actually
think
that
you
bud
has
a
button
like
this
I
think
it
did
at
some
point,
but
I
haven't
checked
lately.
A
A
It
spins
it
up
and
the
other
one
is
an
app
that's
already
been
created.
There's
also
this
feature
to
say
like
create
them
automatically.
So
when
you
open
a
pull
request,
we
spin
up
in
your
environment.
Whenever
you
closed
the
pull
request
or
you
merge
it,
we
actually
flows
down
the
whole
thing,
so
the
amp
only
lives
like
well
the
pool
across
this
open.
A
A
A
So
now
it's
been
spun
up.
So
it's
deployed
the
this
pull
request
to
a
nap
and
we
can
click
on
that
link
and
it
takes
us
to
the
hello
get
of
satellite
thing
that
we
just
did
so
to
do
this,
like
the
comment
that
you
saw
there,
we
were
talking
about
using
get
up
comments
before
but
weird
like
it's
kind
of
hacking
things
and
it
turned
out
that
just
a
month
before
something
get
off
that
open
up
an
API
called
deployment
API.
A
The
deployments
API
is
kind
of
like
commit
statuses
that
you
have
for
Travis,
CI
and
that
stuff,
but
for
deployment.
So
when
we
start
spinning
this
up,
we
can
say
like
hey,
I'm,
Heroku
and
I'm,
creating
a
deployment,
and
then,
if
it
succeeds,
you
can
say
like
that,
succeeded
or
it
failed,
and
it
can
link
to
different
things
and
and
just
I
think
there's
a
month
ago.
Get
up
did
some
updates
on
the
API
to
do
some
other
cool
stuff.
A
So
when
I
mert
a
closed
the
pull
request
now
you
can
see
that
this
link
there
it
changes
to
temporarily
deployed.
So
one
of
the
changes
they
did
to
the
API
was
to
say
you
can
spin
up
transient
environments
and
review
apps
or
transient
they
go
away
after
a
while
and
when
we
closed
them
down,
we
send
an
inactive
status
to
github
and
with
basically
does
this,
so
you
can't
link
to
the
like
a
penny
more
because
it
would
just
be
like
this
app
doesn't
exist
anymore
and
so
for
review.
A
Apps
like
where
does
test
data
come
from
and
that's
a
common
question
that
we
get
and
we
generally
advise
that
you
use
seeds.
So
you
basically
have
a
script
that
generates
data
for
your
database
like
something
small,
nothing,
too.
Crazy,
but
we
often
get
the
question:
can
I
please
just
copy
this
database
and
we
have
a
happy
way
to
do
it
and
we
generally
don't
like
advise
people
to
do
that,
because
really
bad
things
can
happen.
A
So
it's
something
that
we're
hoping
to
bake
better
into
the
product
rather
than
doing
a
happy
thing
and
similarly
to
like
now
public
API-
and
there
are
complications
with
this
where,
like
these
are
long
running
processes
like
spinning
up
a
review,
have
to
take
up
to
half
an
hour
in
some
cases
like
if
the
build
has
to
do
a
lot
of
things
and
on
the
get
up
side
of
things.
So
we
have
like
yeah
the
app
setup.
A
Singh
has
its
own
state
machine
like
it's
spinning
up
and
then
it's
done
or
it's
torn
down,
and
then
the
get
up
API
also
has
like
the
PRS
open,
closed
or
merged.
So
they're
like
to
state
machines,
so
compound
is
like
three
state
machines,
kind
of
and
tracking
all
that
status
tricking,
and
it
was
something
that
we
didn't
give
like.
A
Give
it
too
much
thought
into
in
the
beginning,
so
race
conditions
who
doesn't
love
race
conditions
like
we've,
been
closing
them
down
like
crazy
and
I,
think
hoping
that
we've
fixed
it
all,
but
probably
not
that
you
know
how
it
is
so
yeah,
that's
always
fun
so
give
far
into
like
these
kind
of
processes.
State
machines.
There
is
a
paper
called
out
of
the
tar
pit
and
it's
one
of
the
best
academic
papers
are
red,
and
it's
precisely
on
this
like
how
to
manage
states.
A
So
if
you've
got
time,
it's
80
pages
long
like
please
read
that
the
last
bit
that
we
did
is
something
called
pipelines.
But
this
is
our
most
recent
projects
and,
like
usually,
you
have
like
in
this
software
development
lifecycle.
You
have
like
development
staging
and
production
environments,
so
this
is
basically
to
encapsulate
that
and
visualize
it
like
make
it
look.
Nice
like
let's
do
some
features
around
that
stuff
and
and
like
usually
people
on
roku.
A
They
have
like
at
least
two
apps
like
if
you
have
any
big
system,
but
you
have
a
staging
app
and
a
production
app
so,
and
this
is
what
people
usually
see
like
when
they've
been
using
that
but
like
we
wanted
to
fix
all
that,
so
we
I'm
going
to
set
up
now
a
pipeline
for
these
two
apps
and
enable
a
few
features
I'm
getting
to
the
cool
like
thing
in
a
bit,
so
you
hit
the
create
pipeline
button.
You
give
it
a
name,
sorry
about
the
small
size.
A
I
like
scaled
it
up
as
much
as
I
could
before
recording
all
this
and
I
connected
to
the
same
repo
as
the
apps
and
hit
create
pipeline,
and
since
it's
connected
to
the
same
repo
when
I'm,
adding
apps
to
the
pipeline
I.
It
knows
that,
like
these,
this
app
is
connected
and
has
a
staging
in
the
name.
So
it's
probably
a
staging
app
the
production
of
it's,
probably
a
production
app,
so
there
we
go
and
and
for
the
staging
app
I'm
going
to
set
up
automatic
deployments.
A
So
this
is
the
new
UI
for
that,
so
then
set
up
and
then
I'm
going
to
enable
a
review
apps.
So
this
is
new
UI
for
that
and
it's
based
off
the
staging
app.
So
if
there
are
config
warrants
that
have
to
be
inherited,
which
is
not
in
this
case,
then
it's
going
to
copy
them
from
there
and
then
like
automatic
review
apps.
So
now
we
have
this
pipeline.
A
What
is
that
I'll
look
like,
so
we
had
to
load
a
lot
of
context
and
we
have
to
talk
with
lots
of
people
inside
the
company
we
had
to
like
iterate
and
reiterate
on
the
API.
It
took
probably
a
good
like
months
or
two
to
get
the
API
kind
of
settle
down,
and
but
the
good
thing
is
that
we
ended
up
with
an
API
that
I
think
is
really
good
and
it
kind
of
forced
us
to
think
about
the
internal
data
models
like
what.
How
are
we
going
to
build
this?
A
So
we've
been
thinking
like
we
probably
need
to
refactor
quite
a
lot
of
things
to
move
these
like
mechanisms
over,
and
it's
also
add
ons
and
config
wires
and
some
stuff,
and
it's
going
to
be
a
fun
refactor
in
a
big
distributed
system
to
do,
but
maybe
one
day,
let's
see
and
so
getting
on
back
to
using
pull
request.
Oh
yeah,
using
pull
request
to
drive
continuous
delivery
so
and
I'm
to
the
demo,
know
where
I'm
going
to
show
all
this
stuff
together.
A
A
It's
a
lot
of
work
in
it
but
like
if
you're
not
using
broke
me,
you
can
like
set
stuff
like
this
up
with
a
get
of
API,
given
that
you
have
like
containers
and
stuff
like
that,
so
I
have
these
like
split
screen,
so
it's
like
get
up
on
the
left
side
and
then
broke
on
the
right
side.
So,
let's
start
by
creating
a
PR.
So
it's
the
same
Chainz
as
I
did
before.
So
it's
like
hello
to
like
Hello
Kitty
up
satellite
in
the
two
apps
there.
A
A
There,
I
go
and-
and
you
can
see
on
the
polar
quest
is
the
same
as
before.
You
have
the
app
and
we
click
that
you
see
a
legate
of
satellites,
and
so
this
is
like
a
trivial
example
of
a
review
if
it's
just
a
small
code
change,
but
it
can
being
like
you
have
database
migration,
so
people
have
like
big
database
is
connected
to
this
thing
and
setting
up
like
you,
can
there's
a
post
deploy
script
thing
you
can
do
so.
A
People
are
setting
up
like
resources
on
AWS
or
doing
other
crazy
API
integrations
creating
OAuth
clients
like
this
is
not
just
for
trivial,
setups
and
so
yeah,
then,
like
the
rogue
dashboard,
like
the
thing
you're
looking
at
that's
actually
using
all
of
its
this
stuff,
I
had
to
blur
out,
because
there
might
be
some
like
product
secrets,
but
I
get
so
you
can
see.
We
have
like
a
lot
of
pull
requests
open
and
like
one
staging
up
one
production
app
and
then
like
the
thing
that
happens.
When
you
merge
the
pull
request,
you
can
see.
A
Now
you
can
see,
there's
a
reflex
to
always
delete
the
branch
right
after
but
reveal
goes
away,
and
you
can
see
that
staging
storage
building
and
after
a
few
seconds
there
we
go
and
then
we
can
go
ahead
and
verify
that
what
we
actually
built
on
staging
is
what
we
were
expecting
so
we'll
head
over
to
the
powder
and
open
up
the
staging
app.
So
is
hello.
Before
and
now
it's
at
hello,
get
up,
satellite
and
and.
A
A
So,
let's
head
back
from
there
back
to
the
promotion
and
hit
the
promote
button,
and
you
can
see
that
this
promotion
actually
takes
way
quicker
than
the
actual
builds
and
that's
like
just
copying
the
build
artifacts
it's
way
smaller
than
triggering
a
whole
rebuilds,
so
builds,
can
take
up
to
like
half
an
hour
for
some
apps
yeah.
Let's
open
up
the
production
app
and
there
we
go
like
we've
taken
something
that
was
in
a
pull
request,
downloaded
and
like
made
sure
that
it's
actually
the
thing
that
we
want
automatically
like
deployed
that
to
staging.
A
It's
like
it
takes
you
somewhere.
Sometimes
you
don't
know
what
it
is
that
you'll
end
up
with,
but
I
think
we
have
something
that's
kind
of
cool
and
and
all
of
this
stuff,
it's
something
that
we
call
roku
flow.
So
there's
like
get
flow,
get
up
flow
and
now
there's
roku
flow,
and
it's
been
it's
a
lot
of
hardware
in
this
stuff
and,
like
the
team,
has
done
great
I'm
super
proud
of
what
we
got
and
thank
you
all
for
listening.