►
Description
Presented by Chris Patterson, Product Manager, GitHub
The community-powered in GitHub Actions enable you to automate your software lifecycle from idea to production. In this demo centric session you will learn how to use GitHub Actions to build a secure deployment pipeline for your applications.
0:00 - Intro and GitHub Actions Growth Metrics
3:55 - Protect Environments
5:36 - Scope Secrets to Environments
7:02 - Track Deployed Environments
7:51 - Vizualize complex workflows
8:44 - Demo
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
I've
been
working
on
github
actions
ever
since
we
we
really
started
almost
two
years
ago
now,
actually
been
working
on
github
actions
and
building
it
out
and
before
we
get
started
with
today's
topic,
which
is
really
talking
about
how
we
can
improve
continuous
delivery
with
github
actions
and
really
focusing
on
some
of
those
really
neat
features
that
you
guys
saw
in
the
keynote
from
that.
I
wanted
to
talk
a
little
bit
about
where
github
actions
has
grown
since
we
launched
it
actually
at
universe.
A
One
year
ago
today,
since
it
went
or
not
today,
at
least
about
one
year
ago,
since
it
went
ga
so
github
actions
has
grown
massively
right
now
we
run
about
75
million
jobs
at
the
slide,
says
73,
but
I
looked
this
morning
about
75
million
different
jobs
a
month
across
a
wide
variety
of
workloads.
Ci
is
probably
the
most
common
thing
that
people
absolutely
automate,
but
the
amazing
growth
has
really
come.
I
think,
due
to
the
community
and
if
we
look
across
sort
of
all
of
the
different
ci's
that
happen
on
github.
A
And
so
I
just
really
want
to
thank
the
community
for
that
incredible
vote
of
confidence.
Frankly,
so
in
today's
topic
talk
about
continuous
delivery
with
github
actions,
and
you
know
this
is
always
a
fun
topic,
because
continuous
delivery
means
a
lot
of
different
things
to
a
lot
of
different
people,
but
specifically
the
actions.
You
know
the
question.
Actually
I
got
from
a
couple
of
people
when
I
first
started
talking
about
what
we
were
doing
was
well,
I
can
do
a
cd
with
actions.
A
Today,
actions
can
be
triggered
off
of
lots
of
different
events,
pull
requests
and
push
and
new
releases,
and
things
like
that,
and
that
is
absolutely
true.
In
fact,
I
did
a
talk
at
satellite
back
in
the
spring
of
of
a
way,
you
could
do
a
continuous
delivery
workflow
with
github
actions,
but
when
I
talk
to
different
types
of
customers
and
a
lot
of
them
tend
to
be
sort
of
more
enterprise
focused
or
are
customers
that
have
compliance
needs.
A
So
what
I
wanted
to
talk
about
for
this
talk
are
really
focusing
on
four.
I
call
it
four-ish
new
key
capabilities
in
github
actions
that
we
think
working
together
really
help
you
take
your
continuous
delivery,
workflows,
kind
of
to
a
next
level
and
and
then
over
time,
some
of
these
capabilities.
We
really
have
some
great
ideas
of
ways.
A
So
the
first
one
I
sort
of
term
protect
and
what
we
implemented
was
protected
environments,
and
the
idea
here
is
we
wanted
to
prevent
unauthorized
deployments
and
in
order
to
to
think
about
how
that
might
work
with
with
github
actions.
In
fact,
you've
seen
this
this
on
the
roadmap.
If
you
looked
at
our
public
roadmap,
we
have
something
called
manual
approvals
and
there
were
a
couple
of
different
ways
that
we
thought
about
implementing
that
kind
of
feature.
A
A
So,
for
example,
we
sorry
we
had
the
we
had
the
reposcope
secrets,
and
now
we
have
environment
scope,
secrets
and
with
those
things
we
have
the
ability
to
potentially
just
produce
other
scopes
and
the
way
these
environment
scope
secrets
work.
Is
you
can
the
job
that
does
the
deployment
doesn't
get
access
to
these
secrets
until
after
the
approval,
so
after
the
required
reviewers
go
through
so
that
protects
those
secrets
from
unauthorized
access?
A
Next,
we
heard
from
a
lot
of
people
that
you
know
they
want
to
be
able
to
track
what
is
currently
in
a
particular
environment
whether
that
environment
is
production
or
if
that
environment
is
a
staging
or
whatever,
and
you
know
one
of
the
questions
asked.
Actually
the
previous
session
was
about
how
you
could
track,
which
you
know,
work
items
or
which
issues
had
been
moved
into
a
particular
environment
and
starting
to
build
this
new
activity.
A
And
finally,
we
wanted
to
give
you
a
much
better
way
to
visually
track,
how
your
workflows
are
progressing.
You
know,
as
you
have
these
more
complex
workflows,
particularly
ones
that
do
sort
of
pipeline
style
deployments
to
different
environments
or
maybe
have
rich
matrices
or
other
concepts
having
the
ability
to
see
where
those
go
and
sort
of
track
their
progress.
At
this
very
visual
level,
we
think,
improves
just
the
overall
usability
of
actions,
the
usability
of
more
complex
workflows
and
the
ability
to
debug
potential
issues.
A
A
In
fact,
this
application
is
the
same
one
that
I've
used
previously
in
cd
demos,
but
I
wanted-
and
I
really
wanted
to
kind
of
show
you
how
we've
improved
things.
So
what
I'm
going
to
do
is
first
thing:
I'm
going
to
do.
Is
I'm
going
to
go
and
make
a
quick
code
change,
just
to
kind
of
kick
off
the
process
and
then
we'll
talk
through
how
this
works?
A
A
Use
a
pull
request
and
commit
to
a
different
branch,
so
we're
going
to
propose
that
file
change,
create
that
pull
request,
and
then
this
is
immediately
going
to
sort
of
start
off
the
overall
experience.
So
first
thing
you
see
that
happens
is
my
deploy
site.
Workflow
has
kicked
off
to
build
this
particular
application
and
while
that's
going,
let's
go
ahead
and
navigate
over
to
it,
so
we
can
take
a
look
at
how
things
are
moving
so
first
off.
A
Go
to
my
deploy
workflow
here,
I've
got
a
job
that
sets
up
to
build
and
all
it
does
is.
It
builds
my
site
and
builds
a
container,
and
this
is
one
of
the
places
where
the
power
of
the
community
has
really
come
in
to
help
is
I've
taken
advantage
of
some
really
incredible
actions
written
by
docker?
One
of
our
partners
here
to
build
my
container
and
using
this
nice
build
and
push
action.
A
A
I'm
taking
advantage
of
another
great
feature
from
actions
which
is
the
ability
to
have
actions,
output,
a
particular
value,
and
in
this
case
this
deploy
web
apps
action
written
by
the
azure
team,
outputs,
the
url
that
was
that
was
deployed
to
for
this
thing,
and
so
I've
just
bound
it
here.
And
if
I
go
back
and
look
at
my
pull
request,
I
can
immediately
see
a
couple
of
really
interesting
things
happen.
A
So,
first
off
we
see
the
build,
has
completed,
I'm
going
to
go,
show
the
environment,
and
we
can
already
see
that
this
pull
request
is
being
deployed
to
the
review
lab
environment
by
this
particular
workflow,
and
you
know
we
started
to
really
you
know,
connect
those
things
together.
In
fact,
this
workflow
is
completed
and
right
here
in
my
pull
request
view
I
can
see
view
deployment.
A
So
let's
go
ahead
and
click
on
that
and
I
get
a
really
quick
access
to
this
particular
application
instance.
I've
deployed,
I
can
see
rust.
Is
there
it's
going
to
load
my
popular
repositories
and
that
looks
really
awesome
fantastic.
So
everything
looks
good
in
this
case
and
I'm
actually
going
to
go
ahead
and
merge.
This
pull
request.
A
A
I
can
take
a
look
and
see
that
I've
got
these
new
contacts,
so
I've
got
hey,
we've
got
environment
secrets,
that's
new
and
I've
got
this
azure
subscription
secret.
Here
and
interestingly,
I
have
a
the
exact
same
name
secret
right
here
and
what
this
does
is
it
lets
me
continue
to
build
on
this
idea.
That
secrets
are
important
for
the
particular
context
I'm
in
so,
if
I
went
and
looked
at
my
workflow,
the
workflow
I
design
always
references.
This
single
secret
called
azure
subscription
secret.
A
It's
just
that
when
it's
running
in
the
context
of
say
a
particular
environment.
In
this
case,
any
environment
other
than
production,
so
just
the
repo
or
review
or
staging
it
gets
one
instance
of
the
secret.
This
is
this
one,
but
when
it
runs
in
the
context
of
the
production
environment,
it
gets
this
other
instance,
and
so
it
lets
me
create
workflows
that
work
kind
of
regardless
of
which
environment
they're
targeting
which
can
really
be
helpful
for
maintenance.
A
So
if
I
click
on
manage
environment
here,
we
can
go
and
take
a
look
at
a
couple
of
different
things
that
are
going
on.
So
we
see
we've
got
this
secret
right
here,
that's
that's
going
on,
and
then
I've
got
my
protection
rules
and
so,
as
a
repository
owner,
so
I
happen
to
be
a
repository
owner
or
or
admin
in
the
case
of
org
owned
repositories.
A
I'm
able
to
go
here
and
set
these
protection
rules,
and
so
by
required,
reviewers.
I
made
it
myself,
as
I
mentioned
before,
I
can,
I
can
add
different
different
sets
of
people,
so
I
could
add
a
team
if
I
wanted
to
and
then,
when
the
required
reviewers
when
the
reviewer
is
triggered.
Somebody
from
this
set
so
either
a
person
from
the
team
or
or
if
the
individual
person
listened
here,
has
to
approve
that
and
for
now
we
just
said
it's
just
one
person
in
the
list.
A
I
think
it'll
be
interesting
to
get
some
feedback
from
the
community
from
the
people
that
use
it
on.
If
you
want
to
have
a
minimum
required,
reviewers
or
other
kinds
of
things.
We've
also
added
this
weight
timer
to
a
force,
a
certain
amount
of
wait
time
before
a
deployment's
allowed,
and
that
could
be
useful
if
you
want
to
maybe
run
some
tests
or
run
some
validation
on,
say,
a
pre
on
staging
before
production
happens,
and
so
you
want
to
force
a
force,
a
certain
amount
of
time
to
sit
in
a
particular
environment.
A
So
if
we
go
back
and
take
a
look
here,
we
can
see
how
our
workflows
progression.
We
see
another
really
cool
new
feature,
come
up
in
our
visual
graph
here,
and
that
was
a
progress
bar
that
you
saw
briefly
on
this
staging
element
and
the
idea
there
is
in
the
case
of
long
deployments.
You
might
have
a
bunch
of
different
steps
and
be
able
to
see
how
much
time
has
passed
and
how
much
potential
time
remains
right
here
from
the
graph
can
be
really
helpful.
A
A
The
feature
seems
to
be
there,
and
so
I
could
go
through
and
approve
it
now.
I
can
see
right
here
if
I
happen
to
have
been
looking
at
this
particular
screen
right
now
that
I
need
to
approve
it,
but
also
you
know.
We
know
that
there's
a
lot
of
cases
where
you
might
not
be
right
in
front
of
it,
so
we've
integrated
with
a
couple
of
different
things.
A
So
first
we've
integrated
with
your
standard
web
notifications,
so
that
you
can
immediately
see
the
fact
that
somebody
has
this
new
approval,
requested
notification
type
for
a
particular
run,
and
if
I
click
on
that,
that's
going
to
take
me
right
there.
So
I
can
click
on
there
and
we've
also
started
to
do
some
other
work
to
integrate
in
other
places.
A
A
It
will
kick
off
on
this
deployment
to
my
production
environment
and
if
I
come
back
after
the
fact-
and
I
want
to
know-
hey
who
deployed
this
who
or
who
approved
this
deployment,
you
get
a
full
audit
log
of
exactly
who
made
the
approval,
made
the
approval
and
who
made
any
comments
again.
You
can
see
that
progress
bar,
so
we
think
that
pull
all
those
things
together
really
do
add
up
to
the
ability
to
do
very,
very
rich,
continuous
delivery
workflows
with
github
actions.
A
We
have
a
lot
of
plans
to
enhance
this
capability
in
the
future.
You
know,
for
example,
the
protection
rules
for
environments.
We
really
see
that
as
a
great
potential
point
for
integration
and
I'll
be
definitely
looking
for
your
comments
and
github
discussions
and,
of
course,
on
the
community
forum
in
the
future
on
ways.
You
guys
take
advantage
of
these
capabilities
and
ideas
for
what
you'd
like
to
see
them
go
to
in
the
future.
A
A
There's
no
beta
sign
up
process,
so
you
can
just
if
you're
already
using
actions
you'll
just
see
it
show
up.
If
you're
a
repo
owner
repo
admin,
you
can
start
creating
environments
and
protection
rules
and
environment
secrets
and
those
docs
roll
out
on
exactly
how
you
take
advantage
of
the
environment.
Keyword
in
your
workflows.