►
From YouTube: What is Infrastructure as Code? #DemoDays
Description
2:06 - Program Start
3:43 - Overview
4:55 - What is Infrastructure?
7:05 - ...as code?
9:12 - Demo staring from a GitHub Repo and deploying to the cloud
11:23 - Breaking down the necessary components
12:45 - Infrastructure as Code in a project
15:19 - Usha N.'s source example: https://github.com/Azure-Samples/node_express_app
16:11 - Putting the pieces together
18:11 - What are the benefits of #InfrastructureAsCode #IaC?
20:12 - What's deployed in your cloud?
20:55 - A brief word on compliance
22:44 - How to get started
24:40 - Templating engines and multiple pathways to #IaC
26:53 - In-depth demo, seeing the pieces in action
35:41 - how it flows in the Azure portal
39:55 - How does this scale? Why is trust important?
42:12 - Triggering GitHub Actions
46:11 - Managing secrets
56:01 - Following a PR from start to Production deploy
1:05:40 - Transparency, traceability and trust
1:11:17 - Managing secrets responsibly
Evgeny Rahman and Eric Johnson discuss Infrastructure as code from first principals, define what #IaC is, why it's something you would be interested in, and walk you through what an IaC pathway looks like. Improve your developer velocity while creating scalable, trusted workflows.
For the next session in this series: https://www.linkedin.com/events/6803785695086415872/
A
A
A
Hello
friends,
hello,
hello,
hi,
linkedin,
how's,
it
going
everyone.
I
see
you
all
in
chat,
hi,
dev,
community,
hello,
france,
hello
to
everyone
who
has
joined
us
previously
and
a
particular
hello
to
anyone
joining
us
for
the
first
time.
If
this
is
your
first
time,
I'm
aj-
and
this
is
github
demo
days
where
we
tend
to
focus
on
hands-on
demos
of
specific
features
and
processes.
A
A
Also,
if
you
do
find
this
discussion
useful
and
want
to
see
how
it
might
apply
to
your
team
or
organization,
feel
free
to
use
the
qr
code
that
I'm
going
to
drop
in
the
corner
right
now,
and
you
can
book
a
meeting
with
us
so
to
help
me
with
the
topic
today.
I've
got
evgeny
ramen
solution,
architect
from
professional
services
and
eric
johnson
senior
solutions.
Engineer
thanks
for
joining
us
today,
gentlemen.
I'm
excited
to
dig
in
please
take
it
away.
B
B
All
right-
and
I
guess,
let's
kind-
of
kind
of
get
started
here.
Our
aim
today
really
is
to
kind
of
address
to
talk
about
infrastructure
as
code
and
really
sort
of
it's
a
starting
point.
We've
got
a
couple
of
weeks
here
of
sessions
here,
that'll
be
looking
at
various
topics
of
infrastructures
codes
or
how
to
do
it.
How
github
handles
that
and
how
we
sort
of
deploy
and
build
github
using
infrastructure
code?
B
B
B
Example
right
on.
Thank
you.
Thank
you.
Thank
you
all
right.
So
infrastructure
is
code
with
github
and
your
favorite
robot,
and
there's
some
flexibility
in
that
we'll
get
to
that
here
in
just
a
second
but
from
the
get-go
here.
What
what?
What
are
we
talking
about?
What
is
infrastructure's
code
iac
here
for
short,
we'll
start:
what's:
infrastructure,
let's
just
start
there.
B
This
could
be
actual
physical
servers,
virtual
cloud
type
stuff
with
the
software
that
you're
going
to
need.
That's
not
your
application,
but
that
gets
all
of
that
stuff
set
up
if
you're
deployed
to
the
cloud
as
so
many
of
us
are
at
this
point,
that
would
be
cloud
resources
and
storage.
Maybe
server
provisioning
is
virtual.
Maybe
there's
nothing
involved
with
server
at
all
here,
but
it's
configuration
clearly
there's
quite
typically
networking
components
of
this
thing,
so
networking
configuration
as
well
cache
other
utilities.
B
From
that
standpoint,
database
configuration
as
well
and
and
typically
when
we
talk
about
infrastructure
as
code,
it's
getting
the
gear
up
this
practice,
typically
with
infrastructure,
as
code
kind
of
takes
you
up
to
the
point
where
whatever
you're
doing
with
object,
relational
mappers
or
data.
Definitely,
however,
you're
getting
the
database
structure
in
place,
that's
kind
of
a
gray
area.
Typically,
we
don't
consider
that
infrastructure's
code,
strictly
speaking,
but
whatever
tool
you're
using
to
manage
that
would
would
take
there.
B
Now,
so
that's
infrastructure
right!
You
know.
Obviously
we
we
tend
to
take
that
for
granted.
You
kind
of
in
the
old
days
there
might
have
been
a
dedicated
team,
and
maybe
these
are
your
days
too,
a
dedicated
team
that
kind
of
handles
operations,
provisioning
and
and
kind
of
continuity
around
this,
but
obviously
in
the
world
of
cloud.
That
sort
of
changes,
the
roles
of
that
team
and
whether
there
is
a
dedicated
team
or
not,
if
you
don't
full-fledge
devops-
maybe
that's
not
at
all
dedicated
to
the
code.
B
Maybe
who
approved
it,
but,
more
importantly,
what
change
happened,
so
you
can
generalize
about
that
and
get
much
better
at
repeating
what
you've
got
to
do
to
deploy
your
applications.
Well,
what
we're
going
to
talk
ab
really
today
and
focus
on
today
is
the
github
piece
of
this.
So
how
does
it
work
to
to
be
able
to
handle
those
sorts
of
configurations
as
code
just
the
way
that
you
would
be
handling
your
application
code,
so
configuration
typically
done
in
files,
versioned
and
managed
in
github?
B
As
you
might
know,
there
are
great
ways
to
build
in
automated
tests
as
part
of
that
deployment,
just
as
as
you
would
managing
your
application
code
itself,
and
of
course
you
have
the
option
there
around.
All
of
this
not
only
around
sort
of
automating,
workflows
and
so
forth,
but
the
ability
to
sort
of
put
policy
and
approvals
to
codify
those
put
those
in
place
and
because
we're
talking,
github
and
pull
request
is
our
vehicle
we're
going
to
see
sort
of
trace
of
all
of
that
sort
of
stuff.
B
C
Yeah,
definitely
all
right.
So,
let's
see
here's
the
repo
we
are
going
to
start
with
at
github
a
lot
of
things.
I
would
say
most
things
start
with
the
repo
or
source
code
repository.
This
might
be
a
familiar
site
to
some
of
you,
the
file
layout
with
the
readme
and
everything
you
know.
This
is
meant
to
be
a
very
basic
starting
point.
C
We
are
doing
a
demo
using
a
node.js
application
today
and
we're
going
to
be
showing
you
how
we
can
take
the
application
which
the
source
codes
here
we
are
going
to
use
infrastructure
as
code
in
this
case
azure
resource
manager,
templates
or
arm
templates,
and
those
are
these
files
here
and
we're
gonna
dive
into
all
of
this.
So
you
know
we'll
look
at
the
structure.
C
What
these
files
mean,
why
we
have
multiple
files
and
so
on,
and
so
we
are
going
to
deploy
the
application
using
the
infrastructure
as
code
templates
and
the
power
of
github
actions
and
github
actions
are
our
automation,
workflows
and
with
github
actions.
You
can
do
a
lot
of
different
things.
You
know
it's
not
just
ci
cd,
you
can
do
project
automation.
You
can
really
do
anything
you
can
think
of
that's
compute
that
you
can
encode
into
a
file
like
this.
C
You
can
integrate
a
whole
bunch
of
stuff
right,
so
we're
gonna
talk
about
how
the
building
blocks
inside
github
actions
all
work
together.
To
give
us
this
development
experience
where
we
can
automate
our
infrastructure
provisioning
and
we
are
going
to
see
how
the
changes
that
we
run
through
here
as
actions
workflows,
are
going
to
end
up
in
azure
and
how
we
see.
C
B
A
B
C
C
Okay,
that's
that's
where
everything
everything
lives,
that
sort
of
metadata
and
meta
functionality
for
the
repo.
So
in
this
case
the
workflows
that
power,
the
automation
that
happens
in
the
repo
happen
through
here
and
each
of
these
files-
will
represent
a
separate
workflow
and
we'll
see
how
those
get
triggered.
They're
triggered
off
of
different
events
and
off
of
different
paths,
and
they
serve
different
purposes
and
we'll
look
at
the
structure
of
actions
as
we
go
through
and
do
the
various
deployment
pieces
and
explain
why
they
are
the
way
they
are.
B
Cool
cool
cool
cool
all
right
in
and
looking
here
at
those
other
folders,
so
application,
I'm
guessing!
That's
gonna!
That's
that's
my
app
right!
That's
the
that's!
In
our
case,
this
is
a
node
app!
That's
gonna,
be
you
know,
sort
of
typical
functionality:
oh
yeah,
okay,
web
config,
app.js,
okay,
I'm
familiar
with
all
that
stuff
package
package
lock
so
that
all
that
stuff's
kind
of
versioned
in
there,
the
app
itself
awesome.
Can
you
take
us
back
up
one
yep
all
right.
C
All
right,
so
infrastructure
is
just
our
infrastructures
code
and
the
s-code
part
is
very
important
here
right.
We
are
not
going
to
be
doing
anything
that
is
not
powered
by
what
you
see
here
and
in
this
case
infrastructure
as
code
is
represented
with
json
files
right.
So
we
have
the
actual
template
that
shows
the
definitions
for
the
infrastructure
that
we'll
be
deploying
and
it
uses
schemas
that
are
predefined
for
azure,
and
you
can
check
out
the
schemas
here.
There
is
some
other
stuff
going
on.
That's
templatized
like,
for
example,
the
web.
C
App
name
will
be
sourcing
the
parameters
from
the
other
file,
which
we'll
look
at
in
a
second,
and
you
know
we
have
other
pieces
like
on
cloud.
You
know
you
always
want
to
specify
your
location.
There
is
a
azure
concept
called
a
hosting
plan,
which
is
what
controls
the
resourcing
in
your
resource
group
and
we'll
go
over
these
concepts
a
little
bit.
C
These
are
the
parameters
that
fit
in
there.
So,
for
example,
we
have
the
name
that
we
prefer
to
give
to
our
hosting
plan
our
location.
So
this
is,
I
guess,
the
file
that
you
could
think
of
as
the
values
for
the
variables
if
the
other
file
is
essentially
a
declaration
of
what
variables
we
want.
This
is
how
we
provide
those
variables
to
the
other
file,
or
you
know
how
we
instantiate
based
on
a
template
and
then.
C
Exactly
what
it
sounds
like
it's
essentially
something
that
explains
what
this
arm
template
setup
represents,
and
you
know
it
has
some
information
about
the
type
of
subscription
we're
using
so
we're
going
with.
Essentially
the
beginner
azure
for
student
type
subscription,
which
anybody
here
should
be
able
to
use.
You
know
it's
the
beginner
level
the
os
we
are
using
is
linux.
You
know
we're
deploying
a
node.js
application,
so
that's
perfectly
a
great
fit
and
I'd
like
to
give
a
huge
shout
out
to
usha.
C
But
if
you
go
out
to
the
org,
this
is
actually
an
org
from
microsoft
on
github,
and
it
has
a
lot
of
great
examples
of
things
that
you
can
do
on
azure,
a
lot
of
plug-and-play
kind
of
functionality,
a
lot
of
interesting
workflows
and
examples
of
templates,
and
things
like
that.
So
a
shout
out
to
the
team.
That's
been
building
this
and
especially
usher.
Thank
you.
B
Thank
you,
yeah.
Thank
you,
usha,
okay,
all
right,
so
let
me
kind
of
make
sure
I
got
all
that
that's
a
lot!
So
what
I'm?
What
I'm
hearing
in
terms
of
what
we're
going
to
be
showing
today
here
is
a
couple
pieces,
so
our
application
itself
we're
not
going
to
focus
on
that
today.
It's
an
application!
Great!
It's!
No!
That's
a
key
piece!
B
We're
not
going
to
worry
about
that
too
much
today,
but
but
the
two
pieces
here
are
mostly
the
the
infrastructure
folder
itself,
so
configuration
for
demo
purposes
we're
going
to
go,
deploy
to
azure,
so
we're
using
azure's
own
like
arm
templates
for
that,
okay,
yes,
more
on
choice,
there
are
other
choices
there
more
in
that
a
sec
and
then
also
then,
for
our
purposes.
Today,
what's
going
to
kind
of
kick
this
off
the
the
engine
behind
the
two
engines,
I
guess
right.
So
the
infrastructure
folders
got
arm
templates
which
handle
the
configuration
our
workflows.
B
C
It's
three
great
things:
working
together
right,
like
our
source
code
hosting
and
the
pull
request
flow.
The
power
of
the
github
flow,
which
lets
us
review
changes,
make
them
with
checks
and
balances
in
place,
get
the
team
collaborating.
Then
we
are
going
to
power
that
particular
process
with
actions,
because
actions
can
be
event-driven
right.
C
C
B
B
We
switch
back
to
me
a
couple
more
slides,
all
right,
why
you
know
you
know
and
kind
of
what
do
we
get
from
all
of
this
here,
we'll
see
it
in
in
in
just
a
sec
right,
but
but
really
really.
What
do
we
see
from
this?
It's
consistency
right.
The
idea
here
is:
if
we've
got
a
sort
of
a
a
series
of
patterns,
a
series
of
configurations.
B
We
can
reuse
them,
okay
and
and
and
in
essence,
reusing
the
means
that
we
can
be
sure
in
particular,
very
important
kind
of
reuse.
We
can
start
deploying
those
in
a
test:
environment,
temporary
environment,
staging
environment.
You
know
again
how
many
layers
do
you
need
to
go
through
your
typical
qa
processes?
B
Okay
again,
the
idea
here
is
that
that
what
you've
got
here,
the
configurations
are:
reproducible
they're
not
going
to
change.
You
know
again
in
one
place
or
another
here,
and
the
configurations
tend
depending
on
the
mechanism
you
choose
here,
to
be
self-correcting
as
well.
So
there's
not
this
idea
of
like
oh
yeah,
well,
that
we've
had
that
thing
deployed
and
we
knew
what
what
it
was
when
we
started
and
the
application
first
got
out
there.
B
But
after
that
things
have
gotten
a
little
scary
or
vague
or
whatever
again,
depending
on
sort
of
the
engine
that
you
choose.
The
vehicle
here
that
you
choose
for
infrastructure
as
code
configurations
can
in
fact
be
be
self-correcting,
shout
out
here
just
around
compliance.
We
are
not
going
to
dive
into
this
today,
but
again
the
fact
that
you're
reusing
components
here
that
you
see
exactly
who
did
what
means
auditing
is
far
easier
for
for
those
folks.
B
One
more
is
going
to
dive
specifically
into
compliance's
code,
we're
going
to
have
some
folks
here,
some
guests
who
work,
particularly
with
the
united
states
federal
government,
around
standards
for
figuring
out
how
to
do
this.
There's
a
whole
variety
of
of
standards
here
to
be
that
can
be
stuck
to.
We
can
go
ahead
and
version
these.
Similarly
treat
this
as
code
that
speeds
deployments
improves
compliance,
makes
the
the
security
folks
much
happier
with
with
what's
going
on
and
then
at
the
end
of
the
day,
lets
folks
deploy
their
applications.
B
C
Yes,
we'll
definitely
work
on
this.
We
want
to
make
sure
that
when
we
give
you
the
repo,
when
we
open
source
it,
it
has
everything
you
need
in
it.
It
has
everything
commented
it
has
how-to's,
it
has
guides,
and
so
you
know,
that'll
take
just
a
little
bit
of
writing
time.
Right,
like
everybody,
loves,
writing
documentation
and
it's
always
super
easy,
and
so
we'll
do
that
and
release
it
and
we'll
make
sure
to
let
the
audience
here
know
when
it's
available
out
there,
for
you.
B
So
yes,
not
immediately,
though
okay
again,
what
do
you
mean
how
to
get
started?
This
repository
will
be
a
start
for
for
doing
infrastructure
as
code
kind
of
this
way,
but
but
we
should
really
talk
just
just
a
little
bit
more
bigger
right
right
now
our
example
we're
going
to
show
github
actions
we're
going
to
show
azure's
arm
templates,
but
that
is
by
no
means
the
only
way
to
do
this.
B
B
Okay,
now
in
our
world,
get
up,
actions
are
what's
to
sort
of
detecting
changes
that
particular
file
and
those
actions
then
go
ahead
and
push
the
arm
templates
out
to
infrastructure.
To
update
that
to
make
that
change.
That's
what's
gonna
happen
here
in
our
demo
and
that
works
fine.
That
doesn't
work
so
fine
if
you're,
not
using
azure,
though
right.
So
if
you
are
deploying
the
cloud
to
aws,
that's
not
really
gonna
be
an
option.
The
arm
itself
is
it's
a
great
technology,
but
that
is
very
azure
specific.
B
There
are
a
whole
bunch
of
sort
of
other
options
here
around
this
okay.
We
call
them
sort
of
a
templating
engine.
Here,
I
don't
know,
that's
the
official
name,
but
basically
it's
it's
that
glue
that
sits
in
the
middle
between
code,
changing
in
github
and
that
code
being
deployed
again
arm
templates
here
are
what
we're
looking
at
for
this
today,
powered
by
github
actions
in
this
case,
aws
is
cloud
formation
set
of
conformation
configurations
here
that
can
serve
as
that
engine
in
the
middle
okay.
B
In
a
situation
that
is,
you
know
if
you're
going
to
on-premises
infrastructure,
or
you
were
talking
to
multiple
clouds.
You
might
use
the
last
item
on
this
list.
Your
terraform
okay,
which
is
which
again,
is
designed
to
work
to
do
exactly
that
that
engine
here
that
operates
in
the
middle
listening
to
changes
they
get
enforcing
those
configurations
and
making.
B
All
of
that
you
know
consistent
again,
terraform
really
geared
primarily
here
to
cloud
infrastructure,
a
couple
of
tools
that
did
predate
these
other
three
a
little
bit
are
designed
to
work
sort
of
all
over
the
place,
but
we're
really
designed
not
even
to
be
pre-cloud,
they're,
ansible
or
chefs.
So
the
idea
here
are
tools
again
written
in
different
languages,
but
the
idea
that
these
tools
here
are
looking
at
on
server
configuration
and
making
sure
that
that
does
not
drift
itself
again.
B
Those
these
tools
are
looking
out
to
get
hey
something
changed
in
the
repository.
We
need
to
go
ahead
and
change
configuration
the
ins
and
outs
of
using
any
of
these
tools.
They
are
different,
different
languages
and
so
forth.
So
so
again
they
operate
differently,
but
the
benefits
here
that
we're
talking
about
the
benefits
of
you
know
being
able
to
have
your
your
infrastructure
configuration
server
or
cloud
configuration
here.
Work
through
get
workflow
and
automated
testing
approvals
and
all
that
sort
of
thing
code
reviews
there
again
will
work
with
any
of
these
tools.
C
All
right,
okay,
so
we
are
going
to
take
a
look
at
what's
already
there
first
right,
because
everything
that
I've
shown
you
so
far
is
actually
built
exactly
the
way
I've
described
it
right.
So
we
had
actions
that
ran
already
provisioned
our
production
version
of
the
infrastructure
right
and
then
we
also
had
the
actions
run
to
deploy
the
node.js.
C
C
But
you
know
it's
always
helpful
to
have
the
context
of
what
those
gears
might
be
doing
so,
let's
dive
in
so
first
we
are
going
to
look
again
at
the
application
just
to
show
you
where
the
pieces
that
are
kind
of
going
to
be
most
visible
to
us
live.
So
this
is
a
web
application
on
node.js.
If
you're
not
familiar
with
node.js,
it's
a
javascript-based
framework
or
library.
You
know
you
know.
C
Different
people
have
different
opinions,
but
essentially
it's
a
set
of
code
that
will
help
you
to
write
reactive
web
applications
that
can
listen
to
input
through,
like
this
mini
server
kind
of
paradigm.
So
this
is
kind
of
the
app
app
has
a
lot
of
these
pieces,
such
as
listening
to
the
ports
listening
for
incoming
http
requests
and
then
routing
that
around
to
other
pieces
of
the
application-
and
you
know
you
can
load
up
your
dependencies
in
here
and
this
views
is
what
we're
going
to
look
at
next.
C
The
views
and
the
view
engine
which
is
adorably
named
pog
is
what's
going
to
power.
The
changes
we're
going
to
show
today
so
here
are
the
views
in
the
views
directory
right
and
you
see
that
they
all
have
this
extension
of
dot
pod.
So
this
is
what's
known
as
a
view
template
most
major
application
frameworks
for
the
web
have
some
form
of
templating
engine
that
they
work
with.
Node.Js
has
plug,
it
has
j,
it
has
dust,
I
believe,
but
the
way
that
it
looks
is
this
right.
C
C
Element
which
has
a
paragraph
in
it
called
github,
plus,
azure
rock,
and
just
to
show
you
live
where
that
is
it's
this
right
here
right,
so
the
change
we'll
be
introducing
will
be
to
update
this
area
and
we'll
go
through
a
process
where
we
review
and
approve
those
changes.
So
that's
just
the
very
basics.
You
know
we're
making
a
change
to
our
application
right,
like
I
mean
imagine,
you
know
when
we
make
a
change
to
github.com
to
add
new
functionality
or
new
messaging
right.
C
Here
you
know
we
have
our
pump
templates.
We
have
a
lot
of
javascript,
which
is
what
node
is
written
in,
or
you
know
what
you
write:
node
applications
and
more
accurately,
and
this
css,
you
know
I
mean
you
can
kind
of
see
it
in
action
here.
Right
like
this
is
why
the
site
looks
that
way,
because
we
have
some
styling
in
there
and
stylus,
which
is
also
for
styling.
C
As
the
name
might
say,
it's
enough
about
the
application
right
like
let's
look
at
how
it
gets
out
there
so
jumping
back
into
infrastructure,
I'm
going
to
show
you
where
these
pieces
fit
in
into
the
azure
control
panel
or
portal
there
in
a
second.
But
just
let's
look
at
the
major
elements,
so
there's
the
schema
declaration
that
we
talked
about.
This
is
version
one,
and
you
know
the
schema
really
drives
each
of
these
things
being
valid
right
like
so.
Essentially
what
goes
in
here
is
not
arbitrary.
C
It
has
to
follow
a
certain
structure.
Right,
like
I
mean
json,
is
fairly
free
form
as
a
file
format,
but
this
particular
json
file
follows
this
schema.
So
it's
a
deployment
template
right
like,
and
this
is
how
a
lot
of
other
stuff
works.
You
can
use
similar
things
with
terraform
and
cloud
formation
right
like
there's,
these
kind
of
schema
based
json
files
and
the
schema
has
to
be
valid
and
the
inputs,
and
that
have
to
be
valid
in
order
for
it
to
be
evaluated
correctly
by
the
engine
that
drives
the
infrastructure's
code.
C
In
our
case,
it's
the
arm
engine
right,
so
the
azure
resource
manager,
engine
and
so
going
back
through
this.
You
know
we
have
a
place
to
plug
in
the
subscription
id.
You
know,
and
here's
where
the
schema
really
comes
in
right.
Like
it's
a
string,
we
have
a
web
app
name,
which
is
the
name
that
we'll
see
in
our
portal.
We
have
location,
which
is
you
know
where
the
physical
data
centers
are
that
will
host
this
application.
C
C
Right,
it's
just
somebody
else's
computer
and
then
a
few
of
these
are
fairly
regular,
like
you
know
whether
we
want
the
application
to
always
be
on
what
kind
of
skew
this
offering
falls
under.
So
these
are
more
almost
like
accounting
type
pieces
that
we
have
to
provide
in
order
to
provision
the
infrastructure
right
like
because
you
know
this
plugs
into
the
actual
azure
cloud
and
into
a
subscription.
In
this
case.
This
is
my
test
subscription
and
we'll
also
talk
about
subscription
id
in
that
frame
as
well.
C
So
then,
we
have
a
little
more
substitution
going
on
here,
and
you
know
I'm
just
showing
you
these
kind
of
nitty-gritty
details
to
explain
that.
There's
a
lot
that
happens
in
a
template
that
needs
to
be
set
up
correctly.
That
is
going
to
be
dynamic
that
you
need
to
sort
of
like
plug
in
variables
into
right.
So
I
think
one
of
the
important
things
in
infrastructures
code
is
there's
definitely
a
development
element
to
building
out
the
right
templates.
C
It
often
helps
to
start
with
blueprints
and
templates
from
the
cloud
providers,
or
you
know
from
folks
like
myself
and
eric.
You
know
where
we
kind
of
do
some
of
the
experimentation
we
work
with
you
and
you
know
we
give
you
something
that
we
think
is
going
to
work
well
for
you
and
you
know,
get
kind
of
the
details
in
the
right
order
and
then
we
move
over
to
the
parameters,
and
this
is
really
where
you
say.
B
C
C
So
that's
the
version
of
node.js
that
we
are
aiming
for
on
our
linux
platform
and
that's
really
pretty
much
it
in
terms
of
the
parameters
that
we'll
be
working
with
all
right.
So
we
are
targeting
azure,
app
service,
sorry
app
service
as
our
environment,
where
we'll
be
deploying
and
we're
gonna
look
at
that
next,
so
that's
that's
kind
of
the
text
on
the
screen
version
of
this
right.
C
Let's
see
how
that
looks
over
in
the
azure
portal,
so
this
is
the
resource
group,
the
resource
group
in
azure,
for
this
demo
days,
application
and
the
resource
group
is
really
a
umbrella
term
or
encompassing
concept
for
everything
that
will
be
deployed
and
provisioned
for
this
particular
application,
and
it's
just
how
we
kind
of
organize
things
together
in
terms
of
cloud
resources
right.
So,
if
you
think
about
you,
know
your
home
setup
right,
like
maybe
your
laptop,
your
desktop,
your
monitors,
everything's
in
one
room
right,
it's
the
office
right.
C
So
it's
the
resource
group
is
the
office.
So
this
is
really
the
the
collection
of
resources,
and
you
know
one
pointer
to
them
or
one
way
to
refer
to
them
all
in
one
place,
and
then
you
can
see
the
subscription
id
in
there
and
you
can
see
some
of
the
resources
under
there
so,
for
example,
the
node
application.
C
So
this
is
our
production
node
application
and
it
shows
you
the
url
where
it's
deployed,
and
then
it
shows
you
what
service
plan
it's
on.
You
know
all
these
details
that
you
need
to
manage
and
provision
and
keep
your
infrastructure
running
and
operating
smoothly.
You
get
some
metrics
live
there.
So
as
requests
come
in,
you
can
see
how
this
changes,
how
your
response
time
to
customers
is
going
like
when
somebody
requests
the
application,
you
know.
Is
it
responding
within
the
slas
that
you
set
for
your
customer
right
like?
C
Are
there
any
alarms
that
need
to
go
off
and
you
think
you
need
to
troubleshoot
and
so
on?
So
that's
sort
of
the
level
at
which
we'll
keep
this
I
mean.
Essentially,
this
is
a
deployment
of
our
application.
There
are
multiple
deployments
we
can
do
and
that's
one
thing
that
we'll
see
live
in
a
few
minutes
here
and
essentially
we
can
deploy
multiple
versions
of
this
app
because,
like
we're
talking
about
our
deployments
and
our
infrastructure
are
templatized
right.
C
I
know
how
to
handle
this.
I
know
what
you're
asking
me
for.
I
know
how
to
provision
this
you're
going
to
get
a
new
set
of
infrastructure,
and
that's
what
you
see
here
right.
So
we
have
one
provision
for
the
main
node
app.
We
have
a
review.
We
have
another
review
app.
We
have
another
review
app
and
we
can
keep
doing
this
right
like
cloud
resources
are
elastic
and
scalable
right.
C
So
essentially,
if
I,
if
I
had
multiple
changes,
that
I
was
pushing
through
my
project
pipeline
at
the
same
time,
I
could
scale
out
and
have
these
all
reviewed
separately.
I
could
constrain
it
where
I
can
only
have
one
deployment
of
a
review
at
the
time
right,
like
that's
all
stuff,
that
I
can
control
through
my
pipeline
built
out
and
github
actions
in
this
case,
and
all
of
these
things
are
running.
C
So
I
was
talking
about
the
server
farm
right
like
if
you
want
to
see
like
that's
kind
of
the
stuff
that
was
visualized
for
the
server
farm
here,
and
so
all
of
them
are
referencing
the
same
server
farm,
but
I
have
multiple
parallel
app
deployments
and
each
of
these
can
be
slightly
different
or
majorly
different.
Depending
on
what
I'm
trying
to
do.
You
know
I
don't
have
to
keep
redeploying
to
prod
to
see
changes.
B
Well,
I've
got
a
question:
yeah
see
aj
if
we
got
anything
out
in
chat,
that'd
be
awesome.
I've
got
a
question
for
you,
so
you
know
one
of
the
things
that
I
always
felt
as
a
little
bit
of
a
pain
point.
Maybe
this
is
a
personal
pain
point.
Maybe
you
all
have
felt
this
as
well,
but
you
know
first
time
through
using
whatever
cloud
console,
there's
a
lot
of
questions
to
answer
right
to
fire
up,
even
with
something
like
a
app
service
here,
where
a
lot
of
that
work
is
done
by
the
cloud.
B
There's
still
a
lot
of
questions
to
fill
out
right,
the
form
there's
a
number
of
choices
subscription
id
all
these
other
pieces.
What
I
love
and
looking
at
at
some
of
these
templates
here,
I'm
recognizing
these
keys.
Oh,
I
answered
that
question
or
I
answered
that
question
manually
whatever
and
I
like
so.
Does
this
mean
if
getting
that
using
a
technique
like
this
one?
C
Exactly
that's
the
beauty
of
having
templates
right
like
so.
We
we
get
it
right
once
and
then
we
just
leverage
the
power
of
that
continuously
right
like
and
and
here's
the
big
thing
right
like
speed
is
an
important
part
of
today's
software
development
process.
Right
and
speed
is
built
on
trust
right,
and
so,
if
a
team
can
trust
each
other
and
they
can
trust
their
processes,
they
can
trust
their
infrastructure.
C
They
can
go
faster
without
worrying
about
things
breaking
or
changing
from
under
them,
and
they
can
focus
on
the
things
that
bring
the
most
value
to
their
customers
right.
So
you
know,
for
example,
if
this
was
a
web
app
like
an
e-commerce
store
and
they
want
to
give
you
new
functionality
in
terms
of
shopping
carts
or
how
the
products
are
displayed
right.
They
don't
necessarily
want
to
worry
about
how
the
infrastructure
is
getting
deployed
under
the
covers
right.
They
get
it
right.
Once
we
have
an
e-commerce
web
app
it
gets
deployed.
C
We
know
how
that
happens.
We
can
validate
it
before
it
goes
to
production.
Our
designers
can
go
in
and
log
in
and
take
a
look
and
say
that's
what
we
wanted
it's
all
like
clicking
through,
like
we
expected.
Let's
just
work
on
those
pieces:
let's
not
worry
about
provisioning
infrastructure
or
sort
of
clicking
buttons
to
deploy
things
and
waiting
for
things
to
show
up,
and
things
like
that.
So
you
know
the
the
trust
is
built
on
speed
and
speed
is
enabled
by
automation,
right,
which
is
a
great
segue.
C
So
let's
open
up
the
provision
infrastructure,
one
as
an
example
and
I'll
show
you
what
it
looks
like
on
the
inside.
So
we
have
the
name,
which
is
what
will
show
up
in
the
actions
tab
for
this
workflow,
and
then
we
have
events.
So
this
on
keyword,
it
says
here
are
the
events
that
I
support.
This
is
what
will
trigger
me
to
run
so
one
is
called
workflow
dispatch
and
I
kept
that
in
there
purely
for
kind
of
demo
purposes,
testing
purposes.
C
This
is
just
the
manual
trigger
and
I'll
show
you
the
button
in
a
second
as
well
and
then
push-
and
this
is
the
important
one
right
so
essentially
anytime.
New
code
is
pushed
to
this
branch,
which
is
main,
which
is
our
default
branch,
which
is
our
production
branch
and
on
the
bad
infrastructure,
and
this
is
kind
of
what
we've
been
looking
at
all
along
right,
like
there's,
a
directory
in
here
called
infrastructure,
which
has
all
our
templates
and,
and
so
what
this
all
together
says,
is
anytime.
C
Changes
are
pushed
to
infrastructure
files
on
the
default
branch.
I
need
to
run
right
and
what
that
means
is
it'll
trigger
a
reprovisioning
of
infrastructure
based
on
changes
made
to
the
files
in
here.
So-
and
this
is
production
right-
it's
a
pretty
big
deal,
so
the
way
that
we
make
changes
to
this
will
be
pull
request
based
right.
So
you
know,
because
we
want
to
make
sure
to
validate
those
changes
before
they
ever
make
their
way
to
where
they
could
affect
production,
and
you
know
we
also
might
want
to
schedule
things.
C
We
might
not
want
to
be
continuously
updating
production
infrastructure
right.
So
that's
why
this
piece
is
just
about
infrastructure
provisioning,
it's
not
about
the
application
deployments,
because
we
might
be
doing
you
know
10
or
20,
or
you
know
how,
like
maybe
100
application
deployments
a
day,
but
we're
less
likely
to
be
changing
our
infrastructure.
At
that
rate,
like
usually,
infrastructure,
takes
a
little
bit
longer
to
either.
You
know
go
out
of
date
where
we
need
to
update
it
or
just
like
you
know,
we
change
how
we
want
to
deploy.
C
It's
a
longer
cycle,
it's
a
different
modality
right.
So
that's
why
this
is
decoupled
from
the
application
deployment.
And
so
when
we
look
through
this,
we
see
some
familiar
names
again
so
azure
login,
and
you
see
that
this
is
using
the
azure
login
function.
So
this
is
actually
something
you
can
go
and
take
a
look
at.
C
If
you
look
at
the
github
marketplace
so
on
the
marketplace,
there's
an
actions,
category
right
and
everything
on
here
is
available
for
you
to
look
at
and
try
out
and
here,
if
we
type
in
azure
and
take
a
look,
you'll
see
that
there's
a
lot
of
stuff
provided
by
the
azure
team
right.
We
can
click
on
azure
as
the
as
the
publisher
and
take
a
look
at
all
the
variety
of
things
that
they
provide.
So
one
of
the
things
is
azure
cli
or
azure
login
right
so
azure
login.
C
C
So
in
the
settings
tab
of
my
repo,
I
have
the
secrets
category
and
so
you'll
see.
I
have
these
repository
secrets,
which
means
they
are
secret
variables,
secret
data
that
is
available
only
to
stuff
within
this
repository.
So,
if
you
think
of
actions,
you
know,
actions
that
run
in
the
scope
of
this
repository
can
reference
these
using
the
secret
syntax,
which
we'll
see
in
a
second-
and
I
can
update
this.
C
C
It's
secret,
but
there's
instructions
out
there
on
the
azure
documentation
website
on
how
you
generate
these,
and
then
you
also
have
your
azure
subscription
id,
which
again
is
a
series
of
letters
and
numbers.
It's
like
a
good
looking
string
that
I
also
updated
in
here,
and
so
both
these
things
have
to
be
valid
and
have
the
right
permissions
kind
of
like
with
any
sort
of
credentials,
api
keys
and
things
like
that,
and
so
going
back
over
to
my
workflow.
That's
what
we
have
here.
C
So
we
have
a
bunch
of
environment,
variables
and
secrets
right
in
terms
of
our
variables
that
we
plug
into
these
workflows
and
the
way
that
that
works
is,
for
example,
for
login
right.
I
provide
this
credential
variable
based
on
secrets.azure
credentials
and
you'll,
see
that's
the
variable
name
from
the
secrets
menu
that
we're
looking
at
right.
And
so
what
happens?
Is
this
action
the
code
here?
C
So
then
I
check
out
the
code
onto
the
runner
and
it
now
has
all
the
source
codes,
so
both
the
application
and
the
infrastructure
on
there,
and
then
I
have
this
resource
group
check
or
create,
and
this
is
where
we
get
into
some
infrastructure
as
code
patterns
right
like
so,
we
want
to
have
an
azure
resource
group
right
and
we
define
that
name
here
right
so
demo
days
note
app
rg.
In
our
case,
we
already
have
it
right,
so
we
don't
want
to
actually
create
it
again.
C
We
don't
want
to
go
through
the
sort
of
the
downtime
or
the
rotation
time
that
it
takes
to
bring
down
the
resource
group
and
create
again.
So
that's
why
here,
we've
done
a
little
bit
of
like
conditional
coding
and
say
if
the
az
group
exists-
and
this
is
where
we're
using
azure
cli
by
the
way,
which
is
another
marketplace.
C
Action
and
we
can
specify
the
version
and
then
we
can
specify
our
commands
right
like
that
in
a
block
here,
and
so
we
say
if
ac
group
exists
and
it
has
the
name
of
our
preferred
azure
resource
group,
then
just
say
it's
already:
there
don't
create
it.
If
it's
not,
then
create
it
using
this
create
command
and
make
sure
it's
in
east
us,
because
that's
our
preferred
location-
and
this
is
something
again
that
I
could
have
plugged
in
here-
through
either
secrets
or
through
environment
variables.
C
So
the
group
that
we
either
just
created
already
had
the
azure
resource
group,
which
is
where
we
deploy
all
our
stuff
to.
As
you
can
see,
and
then
we
also
say
this
is
the
web
app
name
that
we
want
and
here's
that
parameterized
magic
that
we're
talking
about
where
if
this
name
was
different
right,
so
this
name
could
be
demo
day's
note
app.
It
could
be
node
app
review
one.
It
really
could
be
anything
abcdef,
one,
two,
three,
four
five
right
like
as
long
as
it's
a
valid
name,
combination
of
characters.
C
It
keeps
referencing
this
infrastructure
directory
that
we
have
and
our
infrastructure
json
files,
but
it
is
not
actually
going
through
and
doing
anything
with
the
application
directory
right,
so
that
was
sort
of
an
extensive
tour
through
this,
but
I
just
wanted
to
show
you
you
know
it's
all
in
the
code
again,
you
know
you
know
we
have
infrastructure's
code.
We
also
have
automation
as
code
right
like
this,
isn't
something
that
I
went
into
a
portal
and
had
to
click
through
in
order
to
generate
this
is
all
code
that
can
be
changed.
C
It
can
go
through
the
same
pull
request,
process
right,
so
we're
gonna,
take
a
look
at
two
more
we're
gonna
go
a
little
faster
just
because
you
know
we'll
recover
the
major
pieces,
so
we're
just
gonna
see
how
these
are
different.
So
this
one
is
the
companion
to
the
infrastructure,
one
see
how
it
says:
I'm
ignoring
infrastructure,
so
any
changes
anywhere
other
than
infrastructure.
C
That's
my
responsibility
right,
like
that's
what
it's
saying,
and
so
it's
going
through
it's
building
the
node.js
app
it's
assuming
that
you've
made
a
change
to
the
app,
so
it
needs
to
rebuild
it.
Reinstalling.
The
dependencies
and
then
it's
packaging
all
that
up
and
creating
this
deployment
artifact
for
us
and
then
at
the
end
of
it
all,
we
are
again
doing
our
login
into
azure,
because
this
is
a
completely
separate
session
and
completely
separate
run
from
our
infrastructure.
Provisioning
right.
C
So,
for
example,
you
know
we
want
to
deploy
to
demo
days
node
app
from
our
production
environment.
So
that's
what
the
variable
would
be
here
and
then
we
give
the
web
app
package
path,
which
is
you
know,
application.
So
everything
in
slash
application
is
our
deployment
code
right.
So
you
know
that's
where
we
want
to
grab
the
application
from.
So
you
see
the
web.
App
name
is
demo
days,
node
app,
the
package
path
is
application
and
our
runtime
node
js
version
is
14.
C
like
anything
within
14
is
good
for
us,
so
we
say
14.x
and
then
one
more
and
this
one
is
the
one
that
combines
both
these
things
right.
So
so
far
we
are
talking
about.
We
want
to
separate
it
out.
We
want
to
separate
out
doing
our
infrastructure
provisioning.
We
want
to
separate
out
our
code
deployment
right,
but
what,
if
we
want
to
actually
do
those
things
at
the
same
time
in
the
same
iteration?
Why
would
we
want
to
do
that?
C
Well,
we
talked
about
that
concept
of
review
apps
right,
so
we
talked
about
the
fact
that
hey
infrastructure
change
code
change
right
like
in
order
to
continue
to
keep
the
trust
on
the
team.
We
want
to
make
sure
that
that's
reviewable
infrastructure
changes
need
to
be
reviewed.
Code
changes
need
to
be
reviewed
right.
How
do
we
enable
that?
How
do
we
see
that
the
infrastructure
changes
and
the
code
changes
work
together
before
we
introduce
them
into
our
production
environment,
where
our
customers
are
using
the
product
right?
C
So
that's
where
we
can
orchestrate
the
moving
pieces
that
we've
seen
before
our
building
blocks
into
one,
and
so
here
we
just
go
through
building.
So
we
build
the
app
we
package
the
app
and
then
we
provision
and
deploy
a
review
app
and
here
you'll
see
we're
getting
into
environments
which
we'll
see
in
a
second
live.
So
you
see,
we
have
an
environment
called
review
and
that's
a
github
concept.
C
So
github
has
this
concept
of
you
can
specify
what
environment
you're,
targeting
with
your
deployments
with
your
jobs,
you
know
so
we
call
the
environment
review
and
the
url
is
actually
going
to
be
dynamic,
so
the
url
is
going
to
be
based
partly
on
our
web
app
name.
So
you
know
demo
days,
node
app
and
then
we're
gonna
have
this
review
to
indicate
in
the
url
that
it's
a
review
version
and
then
we're
gonna
use
the
pull
request
number.
C
C
We
know
that
azurewebsites.net
is
the
hosting
url
for
the
azure
app
service
websites,
and
so
we
keep
going
down
it's
a
lot
of
familiar
stuff,
we're
packaging
up
the
application,
we're
packaging
up
the
infrastructure
templates
and
then
we're
logging
into
azure
once
again,
because
this
again
is
a
whole
different
workflow
right,
like
we
don't
have
our
login
from
the
previous
ones
and
then
we
again
go
into
the
cli.
We
create
a
resource
group
if
we
need
to.
C
But
you
know
by
this
point,
it
should
already
exist
since
this
pull
request,
and
then
you
know
we're
going
in
and
running
our
deployment,
and
this
is
again
where
you
know
the
names
of
things
a
matter
right
like
we
are
plugging
in
parameter
names.
So
we
have
this
app
name
that
we
constructed
using
this
syntax
dynamically.
C
So
we're
passing
that
in
instead
of
like
a
pre-configured
name
and
then
you
know
we're
providing
our
azure
subscription
id
out
of
secrets,
we're
providing
our
azure
resource
group
and
then
we're
deploying
it
and
we're
deploying
it
with
that
dynamically
created
app
name
and
we
are
saying
slash
application.
Everything
from
slash
application
is
in
our
package
and
that's
what
the
application
is
represented
by.
So
that's
everything
that
we're
doing,
and
so
how
does
that
look
live?
Well,
we
talked
about
actions
and
actions
running
right,
so
this
is
where
our
actions
run.
C
You'll
see
that
there's
three
different
workflows.
So
we
talked
about
provision
infrastructure
using
arm
templates.
We
talked
about
provision
and
deploy
review
app.
We
talked
about
deploy
app
to
production
right.
So,
let's
give
it
a
spin.
We
are
going
to
work
our
way
through
creating
a
request
like
this,
a
pull
request
which
looks
like
this
visually,
and
I
will
show
you
where
I'm
going
in
I'm
going
to
do
this
entirely
from
the
web
ui
just
because
you
can
github
has
a
very
nice
web
editor
if
you
haven't
looked
at
it
before.
C
C
We
would
have
the
main
branch
protected,
but
since
it's
a
demo
it's
turned
on
for
eric
and
myself.
Sorry.
So
here,
I'm
just
gonna
say
adding
hello
as
my
branch
name
and
I'm
gonna
click
the
propose
change
button,
which
is
going
to
take
me
over
to
creating
the
pull
request
based
on
that
branch.
So
you
see
the
branches
there,
adding
hello,
adding
a
hello
message.
C
You
know
studio
and
that's
eric
and
that's
this
way
eric
gets
a
notification
that
that's
what
I'm
doing.
I
can
add
some
labels
right,
so
enhancement
is
a
good
one.
So-
and
this
helps
just
like
in
terms
of
metadata,
to
explain
why
I
am
creating
this
change
right.
So
now
we
see
that
my
pull
request
is
in
place
and
it
says
this
branch
has
not
been
deployed
right.
C
So
the
repo
is
aware
that
there
is
a
few
environments
that
I'm
using
and
it
knows
that
those
environments
can
be
deployed
to
from
actions
just
because
in
my
actions
you
saw
I
had
the
keyword
specified
for
environment
and
I
provided
some
urls,
and
now
you
see
that
the
first
step
in
my
provision
and
deploy
review,
app
workflow
has
started,
and
this
is
the
one
that
is
keyed
off
by
pull
requests
right
so
just
to
revisit.
While
this
runs,
let's
just
revisit
that
real
quick
now
that
we're
seeing
it
in
action.
C
So
if
you
go
in
here,
this
is
the
workflow
that's
being
triggered
and
the
reason
it's
being
triggered
is
you
know,
there's
a
pull
request
key
in
here
and
it
says
any
pull
request
that
is
targeting
the
main
branch,
so
basically
anybody
who's
trying
to
propose
changes
to
production
through
the
main
branch.
This
is
where
I
want
you
to
kick
in
and
go
to
action
right.
So
that's
what
is
happening.
We
can
see
this
in
multiple
ways.
We
can
see
this
over
here
it's
running
and
you
see
that
eric's
come
in.
C
He
got
the
thing
he
came
in
and
said
looking
good,
he
approved
it
and
so
the
approval's
there
right
so
now
we're
just
waiting
on
the
workflow
to
complete,
and
you
see
that
we
can
look
at
details
through
here.
So
we
we
can
click
on
that
and
we
go
to
the
checks
view
within
pull
requests
right,
because
actions
are
actually
configured
as
checks,
and
this
gives
us
this
line
by
line
view
of
what
is
happening
inside
of
the
action
I
clicked
on.
C
So
I
guess
maybe
I
did
that
a
little
bit
too
quick,
but
here
I
clicked
on
this
here,
and
that
brings
me
into
the
action
that
workflow
running
and
so
as
it's
running
you
see
that
I
already
completed
this
and
right
you
get
your
so
we
talk
about
pipelines,
everybody
who's
talked
about.
Cicd
has
heard
pipelines
in
some
form
of
shape
right.
So
this
is
a
visualization
of
pipelines
right.
So
we
see
that
the
build
node
app
step
of
the
pipeline
has
completed
if
this
failed.
C
C
Exactly
right,
so
you
know
we
can
all
live
in
our
dreams
right.
So
then
suppose
there
was
something
wrong
with
this
we'd
get
a
red
x
here.
I'd
have
to
go
back
to
the
drawing
board,
see
what
was
wrong
with
the
change
they
proposed
right
so
and
then,
since
that
passed,
we
are
now
going
to
provision
and
deploy
and
it
is
deploying
to
previews
giving
us
this
nice
little
progress
bar
showing
that
you
know
it's.
C
C
It's
going
to
show
you
how
it's
checking
out
the
source
code
and
so
on
and
so
forth.
You
know
and
we'll
get
through
the
actual
uploading
of
the
arm
templates,
and
then
we
are
going
to
go
through
the
actual
provisioning
of
the
code
as
well.
So
this
is
just
the
building
part
right
like
this
is
where
we
we're
compiling
and
sort
of
putting
together,
artifacts
right,
and
then
this
next
step,
that's
running
and
you'll,
see
that
it
takes
a
longer,
because
you
know
we're
actually
interacting
live
with.
C
Said
that
a
few
times
now
right,
so
this
is
where
it's
happening
in
action
and
then
we're
going
through
we
are
setting
up
see.
This
is
going
to
be
our
dynamic
url.
That's
where
it's
being
configured
and
constructed
and
put
into
the
environment,
for
this
run
and
then
again
we're
using
the
cli
to
go
through
and
see.
If
we
have
a
resource
group
resource
group
exists
like
we're
talking
about
so
we're
good
there.
C
We
do
our
cli
script
here
to
run
through
the
provisioning
of
the
infrastructure.
You
see,
there's
a
lot
of
json,
and
this
is
the
json
that
we
were
configuring
right
like
so
in
our
infrastructure
folder
we
were
constructing
this
json
that
now
gets
sent
over
to
azure
and
azure,
recognizes
it
and
uses
that
to
run
the
commands
to
construct
our
infrastructure
and
then
the
last
but
not
least,
step
is.
We
are
deploying
our
web
app
and
you
see
that
it's
all
completed
right.
C
So
we
completed
the
job,
and
so
we
see
that
the
location
is
given
to
us
of
where
it
is,
I'm
not
going
to
click
it
here,
because
I
want
to
show
you
something
else
right
so,
and
I
know
we
are.
We
are
at
the
top
of
the
hour
here.
So,
let's,
let's
get
to
the
to
the
cool
part
right.
So
here
you
come
back
here.
The
link
is
right
there
for
you.
You
click
that
link.
You
go
over
there,
hello
demo
days,
there's
our
change
check
out
the
url
review
for
this
is
our
review
app.
C
You
know
we
go
over
to
our
production
version.
It's
still
stable,
it's
still
intact.
We
haven't
made
any
changes
we
go
over
here.
We
take
a
look
and
you'll
see
that
the
new
environment
has
been
provisioned
review,
for
this
is
where
we
can
see
the
url
as
well.
It
gets
populated
in
here
as
well.
We
click
on
that
same
place
right.
So
then,
if
it
looks
good
to
us,
everything
is
great
right
like
what
can
we
do
with
that?
C
Well,
we
approved,
based
on
what
we
saw
in
here
and
just
to
show
you
one
more
thing,
these
environments,
that
we're
talking
about
right.
So
we
have
our
production
environment.
It
shows
you
that
it
was
deployed
to
14
hours
ago.
This
shows
you
that
another
environment
was
deployed
to
inside
or
sorry
in
in
review.
We
also
deployed
right,
we
just
deployed
this
is
the
traceability
eric
was
talking
about,
and
so
I
can
go
and
view
the
deployment
through
here
right.
C
So
it
looks
good,
no
matter
how
many
times
I
look
at
it,
it
looks
great.
So
what
can
I
do?
I
can
go
in
here
and
I
can
say
all
right:
let's
merge
this
thing
so
then,
when
I
merge
and
I'm
good,
I
just
delete
the
branch
high
confidence
high
crust,
high
speed,
like
we
were
talking
about
using
automation
and
infrastructure,
provisioning
and
guess,
what's
happening,
this
golden
dot.
C
That
represents
that
another
workflow
has
been
kicked
off
and
if
we
go
in
here
we
see
that
merging
has
triggered
deploying
the
app
to
production
right
and
so
the
workflow
we're
talking
about
before
again
it's
building
the
node
app.
It
should
just
revalidate
what
we
already
validated
that
the
code
will
work
right,
so
it's
going
to
run
through
that
for
the
production
version.
C
If
you
need
to
pull
in
production
dependencies,
that's
where
it
happens,
and
then,
as
the
last
step,
it's
going
to
deploy
the
web
app
to
production
in
azure
and
then
we'll
see
our
change
live
over
on
azure,
and
so
this
is
pretty
much
it.
You
know
like.
We
can
definitely
hang
around.
I
know
we're
just
a
little
bit
over,
maybe
our
initial
time
we
can
hang
around.
B
Okay,
that
is
quite
cool
and
quite
problem
problem-solving.
It
addresses
many
many
pain
points,
certainly
that
I've
felt
in
my
career
and
for
many
of
our
customers
as
well.
Hey.
We
got
a
couple
questions
in
the
chat.
One
of
them,
though
I
think
we
could
show.
Can
you
take
us
to
just
look
at
the
deployments
we
can
do
that
for
maine
or
for
or
for
pre-production
either.
One.
B
Asked
here,
how
can
I
tell
that
that
the
infrastructure
itself
committed
to
head
is
what's
in
use
with
the
latest
deployed
instance
of
the
app
and
there's
a
couple
of
different
ways
to
sort
of
do
this?
But,
though,
but
I
think
one
way
that
if
any,
you
really
had,
we
just
look
at
if
you
just
take
us
up
to
the
top.
And
let's
look
at
the
deployments
here.
I'm
just
yeah.
C
Sure,
okay,
sure,
so
when
we
go
over
here
right
there's
a
few
things
we
can
look
at
so,
like
I
said,
there's
environments
right,
so
environments
can
show
you
when
production
changed
last
right,
so
we
can
see
where
the
change
came
from,
like
which
branch
and
everything-
and
we
can
look
at
the
deployment.
We
can
look
at
the
activity
log
in
general
right
like
what
happened
in
production,
what
happened
in
review,
and
so
we
can
trace
back
any
infrastructure
changes
that
way
right
and
the
other
part
to
it.
C
Of
course
is
we
also
have
the
actions
themselves
right,
so
we
know
that
in
our
system
the
only
thing
that
can
provision
infrastructure
to
production
is
this
workflow.
So
we
can
look
at
all
the
workflow
runs.
We
can
see
that
last
it
completed
14
hours
ago
right,
so
we
can
click
on
that.
We
can
click
on
that
see
how
it
ran.
C
We
can
see
what
commit
triggered
this
run
right
like
we
have
this
link
here,
we
can
see
the
change
that
was
made
right
in
this
case
it
was
essentially
a
no-op
just
you
know
something
to
trigger
it.
Just
adding
no
js
right,
but
this
will
give
you
the
full.
You
know
I
mean
that's
the
beauty
of
github
right,
like
you
have
your
source
in
one
place,
you
have
the
automation
in
the
same
place.
You
can
cross-link
between
them.
C
You
can
reference
things
using
urls
and
these
nice
visual
cues
around
sort
of
what
changed
from
what
who
changed
that
very
important
when
they
changed
it.
In
this
case,
even
the
commit
was
verified,
meaning
the
signature
on
the
commit
is
a
valid
signature
to
my
certificates
on
my
machines
and
all
that
kind
of
stuff.
So
this
will
give
you
the
traceability
right
and
there's
so
many
approaches
you
can
take
to
getting
to
the
same
point.
You
can
also
go
into
infrastructure.
C
C
You
can
do
this
and
you
know
the
other
part
to
it
is
if
you
protect
your
main
branch
right
like
if
you
don't
allow
commits
directly
to
it,
then
the
other
thing
you
can
get
is
this
pull
request
history,
where
you
can
see
what
happened
through
pull
requests
like
when
it
happened?
Who
approved
that?
What
were
the
review
comments
right
and
that's
that's
how
you
also
build
up
the
trust?
That's
how
you
also
solve
your
problems
in
one
place
using
code
using
automation.
Is
you
know
you
suddenly
plug
into
the
powerful
github
flow?
C
Where
you
can
collaborate
you
can
assign
reviewers.
You
can
have
conversations
on
top
of
the
code
changes.
You
can
add
checks
of
any
sort,
like
suppose
linting
the
json
or
linking
your
javascript
code,
and
you
know
it
all
gets
sort
of
put
that's
the
hub
part
of
github
right
like
it's
all.
In
one
place,
we
work
together
in
one
place.
We
work
where
others
can
see
it.
There's
no
surprises,
there's
no
secrets
unless
they're
credentials
right
and
that's
that's
kind
of
how
I
work
and
that's
why
I
think
we
love
it.
B
B
Looking
at
that
right,
column,
environments,
let's
see,
what's
going
on
sure,
a
convention
that
productionist
production
reviews
review
or
whatever
you
choose
again,
that
you
have
that
flexibility
to
name
those
as
you
see
fit.
But
looking
through
that
list,
you
are
seeing
the
history
of
every
deployment
there
and
the
advantage
of
using
this
sort
of
the
the
architectural
model
here
that
we
are
with
infrastructurous
code
with
a
a
new
environment
here
per
deployment.
Is
we've
got
history
of
all
of
those
deployments?
B
There
are
other
ways
to
do
it
where
you
can,
you
know,
see
just
the
most
recent
and
so
forth,
but
again
the
way
that
if
guinea
has
put
this
together,
we've
got
the
advantage
having
all
that
history,
but
in
this
case
where
I
look
down
at
that
activity,
log,
so
adding
hello
here.
Those
are
our
branch
names
here,
those
actually
link
to
a
specific
commit,
specific
event
id.
So
we
can
see
exactly
what's
happening.
C
Yes,
exactly
we
can
navigate
around
between
these
things,
because
these
are
all
github
concepts
right,
like
so
github
models.
So,
for
example,
this
one
is
the
pull
request
right
when
we
go
to
pull
request.
Pull
request
is
one
to
n
number
of
commits
right,
so
we
can
navigate
those
commits
see
where
they
were
introduced
into
another
branch.
We
can
also
check
out
the
repository
and
look
at
that
locally
on
the
command
line.
There's
different
ways.
C
We
can
reconstruct
the
graph
there,
but
if
we
want
to
stick
to
the
ui,
you
know
we
have
this
deployments
view.
We
have
the
pull
request
view.
We
have
the
actions
workflow
view
they
all
in
unison,
say
the
same
thing:
they're
different
views
into
the
data
right
so
and
then
last
piece
here
for
the
folks
stuck
around
or
those
watching
it
later
on.
Here's
the
production
version-
and
you
see
it's
updated
because
we
merged
the
production
and
it's
deployed
on
our
production
infrastructure.
So
hello,
demo
days.
B
Let's
do
one
more
quick,
quick
one
here
I'll.
I
can
take
this
one
again
very
quickly,
so
darshan
had
just
asked.
We
were
talking
about
secrets
in
it
about
sort
of
access
there
are
there.
Are
there
more
ways
to
access
secrets
other
than
from
the
command
line?
And
the
answer
to
that
is
so
secrets
are
accessed
a
couple
of
ways
they
can
be
set
in
the
github
ui
in
the
web
browser,
as
we've
seen
they
can
be
set
by
api.
B
We
expose
those
to
an
api
they
can
be
set,
but
those
are
right
only.
They
can't
be
read
that
way,
so
they
seem
super
secret.
Keep
in
mind.
Their
job
is
to
be
able
to
be
exposed
to
actions
runners.
So,
yes,
we
try
and
make
them
sort
of
hard
to
come
by.
We
make
them
easy
to
change
rotate
as
needed,
but
keep
in
mind
to
work
the
secret
to
be
able
to
be
used
on
a
runner
agent.
The
secret
has
to
be
able
to
be
passed
into
that
runner
agent.
B
We
do
a
lot
of
work
on
in
terms
of
the
the
the
runner
and
the
command
line
and
log
scrubbing.
So
we
don't
display
those,
but
the
secrets
there.
If
you
really
want
to
be
a
a
sherlock
holmes
style
actor
here
and
get
a
copy
of
the
secret
they
get
passed
on
to
a
runner.
The
runner
can
log
those
echo
those
do
various
things
with
them,
yeah
so
again,
that's
and
that
is
nature
of
that's
sort
of
the
nature
of
engineering.
B
B
That
does
quite
a
good
job
for
isolating
those
sorts
of
passwords.
Again,
you
don't
typically
need
to
worry
about
that
necessarily
for
for
test
style
infrastructure
again
depending
on
your
world,
but
particularly
for
production
infrastructure.
That
can
make
an
awful
lot
of
sense,
and
then
I
you
know
we
had
an
awesome
general
question,
which
guinea
I
think
that's
going
to
be
we're
going
to
have
to
we're
going
to
have
another
a
whole
other
session
on
that
one
about
what
about
security.
C
B
B
There
are
many
many
many
facets
of
that
again
if
you're
working
with
github
for
your
application
flow,
protected
branches
approvals
code
owners,
if
you
need
to
sort
of
slice
and
dice
who
can
approve
what
all
of
those
are
mechanisms
that
can
help,
you
make
sure
that
you're
getting
the
approvals
you
need
at
the
code
level
by
the
teams,
you
need
to
approve.
That's
only
one
aspect
of
it.
Obviously,
there's
logging
review
and
a
whole
whole
variety
of
stuff
here,
but
I
think
for
today
leave
it
at
that.
C
Getting
I
think
we
covered
everything
we
showed
the
moving
pieces.
We
showed
the
engines
that
power
everything
we
showed
how
we
can
do
set
up
just
one
pattern
that
we
can
apply
here
right,
hopefully,
folks
are
interested.
We
are
going
to
have
a
few
more
sessions
to
follow
up
here
in
june
on
infrastructures
code.
You
can
see
more
hovers
present
on
how
github
does
infrastructure
is
code
and
some
interesting
partnership.
Collaboration
sessions
so
definitely
tune
in
next
time,
and
if
this
sound
is
interesting,
that's
gonna
be
interesting
to
you
as
well.
C
B
You
everyone
and
if
you
need
to
talk
to
the
get
up
team
about
any
of
this
for
work,
use
that
qr
card
we,
our
enterprise
sales
team,
will
be
happy
to
give
you
a
chat.
Who
knows
might
even
be
me
see
you
guys,
thanks
for
joining
us
have
a
great
morning
afternoon,
wherever
you
are
time
zone
wise,
we'll
see
you
next.