►
From YouTube: CD Direction walkthrough
Description
A walkthrough of our direction for continuous Delivery
https://about.gitlab.com/direction/release/continuous_delivery/
A
Awesome
so
today
we're
gonna
go
through
the
continuous
delivery
direction,
so
we'll
just
go
through
the
direction
page
and
stop
me
whenever
you
want.
If
you
have
any
questions
or
you
want
to
discuss
anything
so
continuous
delivery
is
the
category
it's
one
of
the
main
focuses
of
release
is
definitely
the
next
step
that
people
take
after
continuous
integration,
and
this
is
our
motto.
Many
teams
are
reporting
that
the
development
velocity
is
stuck
and
we're
trying
to
help
them
out
we're
trying
to
make
everything
easy
fast,
automatic,
reliable,
repetitive,
etc.
A
A
So
continuous
delivery
is
really
where,
when
you
have
already
a
ci
pipeline
ready,
you
have
cd
that
has
some
kind
of
artifact
that
is
ready
to
be
delivered
at
any
time,
so
you
can
take
that
artifact
and
just
deploy
it,
but
you
don't
have
to,
whereas
continuous
deployment
actually
takes
that
artifact
and
pushes
it
to
your
production
in
an
automatic
fashion.
So
everything
is
just
pushed,
including
the
deployment
stage.
A
Some
companies
will
never
be
in
continuous
deployment
because
of
some
compliance
or
regulations
that
require
some
manual
intervention
in
the
pipeline,
so
they'll
be
their
pipeline
will
end
in
conditions.
Delivery,
they'll,
have
a
manual
action
and
push
something
to
to
deployment
many
times
that
has
to
do
with
with
a
list
of
approvals
whether
it's
qa
approvals
stakeholder
approvals.
A
You
need,
like
security
teams,
to
sign
off,
maybe
as
things
progress
and
we
have
like
automatic
run
books
and
still
you
can
see
all
the
box
ticks
they
can
reach
continuous
deployment,
but
that's
the
main
difference.
The
main
difference
is
the
fact
that
not
every
build
that
finishes
the
cd
pipeline
actually
reaches
production.
B
A
Pipeline
is
code,
infrastructure
is
code,
the
code
is
code,
the
deployment
is
code
and
when
we
think
about
the
big
picture-
and
this
is
something
that
I've
talked
with-
both
the
pm
and
configure-
and
the
pm
and
verifying
pipeline
authoring-
what
we
envision
is
to
give
our
users
ultimate
flexibility
to
to
use
whatever
coding
language
they
want
to
provision
that
coding
and
and
the
whole
process.
However,
they
want
including
the
infrastructure
and
then
just
deploy
it
to
any
target
they
want,
and
it
can
be.
A
So
the
configure
team
is
now
working
on
a
new
kubernetes
agent
that
has
a
manifest
yaml
in
some
repo.
It
doesn't
have
to
be
the
same
repo
as
your
ammo
file,
and
that
does
all
you
know
the
infrastructure
stuff
for
you,
terraform
or
whatever
you
want
ansible,
whatever
you're
using,
and
then
we
could
leverage
that
to
also
figure
out
the
deployment
at
the
end
of
the
day
and
deploy
it
to
aws
to
the
cloud
to
vm
to
physical
device
whatever.
A
Basically,
we
just
need
to
understand
from
the
configuration
of
the
user,
something,
and
then
we
can
just
do
that.
Everything
automatic,
of
course,
in
this
spirit
of
iteration,
that's
going
gonna
take
some
time
and
at
the
moment,
when
we
talk
about
auto
devops
I'll,
explain
a
little
bit
about
what
we're
doing
there
so
deployment
with
auto
devops.
The
reason
we
put
this
under
the
cd
direction
page
is
because
auto
devops
is
kind
of
a
joint
effort
between
different
stages
inside
git
lab.
A
So
if
anyone
wants
to
see
you
know
the
main
focus,
we
can
see
the
category
page
here,
but
specifically,
what
our
teamwork
is
working
on
is
auto,
deploy
or
the
auto
deploy
job
as
part
of
auto
devops,
and
so
today
we
actually
have
two
ways
of
deploying
with
auto
devops
or
how
to
deploy,
and
this
is
really
exciting,
because
this
was
a
large
effort
of
the
of
the
release
team
to
get
to
this
stage.
But
a
year
ago,
if
you
used
auto
devops,
you
had
to
be
a
kubernetes
user.
A
A
We've
actually
opened
up
autodevops
for
non-kubernetes
targets
specifically
to
users
that
are
deploying
to
aws,
and
when
I
mentioned
how
you
know
how
we're
iterating
and
figuring
out
what
users
are
deploying
to
what
we
did
was
we
introduced
a
keyword
called
auto
devops
deployment
target.
You
don't
have
to
use
auto
device
to
use
this
keyword,
but
it
kind
of
tells
us
where
you
want
to
deploy
to
so
specifically
kubernetes
or
specifically
aws
ccs
or
fairgate
or
aws
cc2
and
in
the
future.
Probably
s3
and
other
cloud
platforms
as
well
will
join.
A
So
the
user
tells
us
what
where
they
want
to
deploy
to,
and
we
just
pull
up
the
template
that
is
needed
in
that
case
according
to
what
they
configured.
So
it's
minimal
configuration
of
the
user.
We
kind
of
need
to
know
how
to
connect
to
aws.
So
we
need
to
know
you
know
the
aws
token
and
and
the
secrets
that
are
accompanied
as
part
of
the
pipeline
and
they
tell
us
the
target
and
we
just
connect
the
dots.
So
you
can
enjoy
auto
devops.
A
Even
if
you're
not
not
using
kubernetes,
okay,
so
in
the
what's
next
and
why
this
is
usually
the
section
where
it
talks
specifically
for
the
single
milestone.
That's
coming
up,
so
this
one
is
specifically
talking
about
13.6,
so
it
will
be
updated
very
shortly
after
we
released
13.6,
but
we
have
a
post-deployment
monitoring,
epic,
I'm
going
to
open
that
up
here
and
just
talk
through
that
a
little
bit
so
that
anyone
who's
watching
this
video
will
understand
what
we're
talking
about
so
post
deployment.
Monitoring
is
a
really
interesting
concept
where
we
want.
A
We
want
the
users
to
know
more
about
what's
happening
after
they
deploy
something,
so
it's
kind
of
right
after
the
cd
bit,
and
this
is
using
a
lot
of
monitor
capabilities.
So
this
is
what
I
said.
We
work
work
closely
together
with
other
stages,
so
we
talked
about
configuring,
auto
devops
and
now
we're
talking
about
monitor
in
post-deployment
monitoring.
The
idea
is
that
if
there's
some
critical
alert
that
happens,
you
want
to
take
action.
A
The
minute
you
see
this
alert
coming
in
into
play,
so
you
can
either
do
this
manually
or
automatically,
but
you
can
make
take
a
quick
decision
on
what
you
can
do.
So
what
can
you
do
it?
For
example,
if
I
see
that
there's
something
really
going
really
really
poorly
with
my
roll
out,
let's
say
I'm
doing
canary
roll
up,
I'm
starting
to
roll
out
and
all
of
a
sudden,
I
see
all
these
hdp
errors
or
cpu
usage
is
exploding
or
something
really
bad
is
happening.
A
I
want
to
scale
down
the
roll
out
or,
if
I'm
not
using
advanced
deployments,
then
I
want
to
roll
back
to
the
previous
deployment.
Just
want
to
take
really
quick
action
before
I
do
a
hotfix
or
anything
before
anyone
tries.
This
is
the
problem
just
make
sure
my
my
users
are
not
impacted
by
this,
so
the
idea
is
that
we
connect
alerts
to
our
environments
and
to
the
deployments
so
that
the
sres
and
the
developers
know
what's
going
on
and
and
they
can
do
that
so
manually
would
be.
C
A
A
Of
course,
this
doesn't
solve
100
of
the
problems,
but
it's
a
really
really
good
start.
So
this
is
the
epic.
So
I'm
going
to
talk
about
the
vision
and
then
we'll
talk
about
individual
issues.
So
the
idea
is
here:
we
see
a
deploy
board,
but
this
is
not
dedicated
only
to
kubernetes
users.
This
is
also
available
on
the
environment
page.
So
even
if
you're,
not
a
kubernetes
user,
you
can
use
it
in
case.
You
see
some
kind
of
error.
A
You
see
error
rate
exceeded
whatever,
whatever
your
threshold
is.
This
appears
now
on
the
deploy
board
and
you
can
take
action
here.
You
can
already
see
a
rollback
that
happens
with
a
commit
shot,
so
you
have
also
the
information
for
compliance
or
for
audit
log
capabilities,
or
if
you
want
to
do
it
manually,
you
can
you
know
press,
abort
or
roll
back
manually,
and
that
will
just
do
that
same
thing.
A
In
case
you
see
some
kind
of
error
on
the
other
board
and
then
in
terms
of
the
merge
request
you
would
see
there
was
a
deploy
to
production,
but
there
was
a
rollback.
The
reason
there
was
a
rollback
was
because
there
was
an
error,
and
this
was
the
commit
that
rolled
back.
So
that's
like
the
big
vision,
that's
not
yet
where
we're
at,
but
that's
where
we're
heading.
A
So
in
this
we're
making
a
lot
of
progress
here
and
you
can
see
first,
the
first
iteration
that
we
did
here
was
to
actually
show
these
alerts
on
the
on
the
alert
page.
So
this
is
what
it
looks
like.
You
can
now
see
the
severity
of
the
alert
and
the
alert
itself,
and
when
you
click
view
details
you
can
it
opens
up
to
the
to
the
alert
itself.
B
A
A
You
got
a
notification,
you
need
to
do
something
about
it,
and
so
the
next
iteration
that
we
did
was
was
in
the
previous
milestone,
and
that
was
adding
the
link
to
the
environment,
to
the
alert,
because
sometimes
you
get
a
lot
of
alerts
and
you
have
a
lot
of
environments
and
it's
really
hard
to
differentiate
what's
coming
from
where.
So,
if
you
want
to
take
action
on
something,
it's
important
that
you
know
this
is
production.
A
Here's
the
mockup,
so
we
added
the
setting
that
users
can
define
whether
they
want
to
use
default
automatic
rollbacks
and
in
case
any
critical
alert,
is
raised.
It's
going
to
trigger
an
automatic
rollback
in
the
future.
What
we
want
to
do
here
is
allow
the
users
to
define
exactly
which
thresholds
and
which
alerts
will
initiate
a
rollback
and
not
any
critical
alert
but
specific
ones,
because
we
think
it
needs
to
be
more
granular
but,
as
we
said,
we're
iterating
on
it.
So
that's
gonna
come
in
the
near
future
and
another
thing
that
we
noticed.
A
A
A
Okay,
so
whoever
is
used
to
seeing
the
deployment
can
see
here
the
pipeline
and
kind
of
if
the
deployment
was
successful
or
failed.
If
you
remember,
there's
a
badge
that
says
success
or
fail,
we
don't
have
any
way
to
see
that
on
the
environment
page
today,
which
is
really
kind
of,
doesn't
give
us
enough
enough
observability.
So
we're
going
to
add
here
just
the
same
badge
as
you
can
see
in
the
deployment.
So
you
would
see
if
this
is
success
or
fail.
A
This
is
the
issue.
It
was
actually
already
completed
this
week,
so
any
user
that
wants
to
deploy
to
ec2
can
and
the
way
that
we're
doing
this-
and
this
is
really
interesting-
is
we're
kind
of
looking
at
auto.
Deploy
as
a
microservice
architecture,
in
the
sense
that
we're
building
small
atomic
docker
images
that
do
single
operations,
so
you
can
take
those
images
and
pull
them
into
your
yaml
file
and
just
use
them.
A
A
Let
me
show
you
here
three
different
docker
images
that
we
supplied
one:
it
does
the
provisioning
using
cloud
formation,
the
other
one
pushes
in
artifacts
as
three
and
the
other.
The
third
one
actually
does
the
deploy
to
ec2.
So
each
one
of
these
docker
images
can
be
used
independently
in
your
yaml
file.
A
C
A
Do
any
adws
cli
action
directly
from
the
gitlab
yamo?
If
that's
what
you
want,
if
not,
we
also
supply
full
gitlab
cimo
templates
like
this
one,
that
does
all
these
different
steps
for
you.
And
lastly,
we
connected
that
to
the
auto
devops
flow,
which
allows
you
to
use
auto
devops
pipeline
and
does
this
automatic
for
you,
so
it
will
also
add
the
sas
testing
auto,
build
stages,
review,
apps,
etc.
So
we
kind
of
did
this
really
really
iteratively
and
it's
very
repetitive,
so
we
create
a
docker
images
image
that
does
something
small.
A
B
A
Yeah,
it's
really
really
a
great
feature,
but
when
thinking
about
it
we
also
need
to
support
manual
rollback
and
the
reason
is
because
some
customers
simply
don't
want
everything
to
be
automatic
for
one
of
two
reasons:
a
they
have
to
have
some
kind
of
manual
gates
on
any
deployment
to
production,
whether
it's
because
of
compliance
or
some
other
reason
or
two
their
pipeline-
just
isn't
mature
enough
to
do
it
automatically.
So
they
would
need
manual.
So
we
still
need
to
support
both
of
them.
But
I'm
super
excited
about
this
epic.
A
A
A
Now
this
is
actually
a
really
old
estimation
of
the
maturity
level
and
we
have
a
research
issue
for
jobs
to
be
done
to
rebase
the
maturity
level
of
of
cd,
and
the
reason
is
that
we're
in
such
a
disrupt,
disruptive
state
and
dynamic
state
and
technology
keeps
changing
that
it's
really
hard
to
keep
up
with
the
word
complete
at
any
given
moment,
because
there's
always
something
new
coming
out.
So
what
I
want
to
do
is
actually
re
rebase
the
maturity
level
make
sure
that
we're
we
are
incomplete
or
we're
not
incomplete.
A
A
A
I
don't
remember
the
term,
but
the
idea
is
that
you
have
segregation
of
duties.
I
think
is
the
term
where
there's
different
permissions
for
each
type
of
action,
so
maybe
cia,
the
ci
team
is
not
the
cd
team
and
then
you
could
have
different
permissions
on
who
can
write
the
ammo
and
who
can
run
the
ammo
so
in
some
some
day
in
the
future.
That's
what
I
envisioned
to
have,
but
at
the
moment
we're
just
extending
the
same
gitlab.
B
A
A
A
Sometimes
it's
really
important
to
limit
that
and
then
a
lot
of
our
customers
were
asking
for
such
a
solution,
and
so
we
created
this
concept
of
resource
groups,
which
is
a
keyword
that
you
add
to
the
yaml
file,
and
then
that
is
locked
that
specific
resource
group
is
locked
until
the
job
is
complete
and
and
is
given
a
flag
of
unlocking
it,
and
that
makes
sure
that
only
one
consecutive
deployment
is
done
at
any
given
time
now,
there's
a
lot
of
extensions
that
we
can
do
there.
So
at
the
moment,
it's
as
we're
talking.
A
C
A
A
So
there's
quite
a
few
requests
around
that
group
deploy
tokens
is
another
one
allow
only
forward
deployments
is
something
that
we
that
we
added.
What
would
happen
was
sometimes
you
have
slow
deployments
and
and
and
fast
deployments,
and
sometimes
an
old
deployment
took
really
really
a
long
time
to
deploy
and
it
would
override
some
a
fast
newer
deployment,
and
so
you
would
be
left
with
a
an
older
deployment
after
the
newer
deployment,
which
was
really
bad.
A
A
It's
kind
of
self-explanatory
group
deploy
keys.
So
a
lot
of
group
actions
that
were
asked
because
everything
that
we
did
was
usually
on
a
project
level
and
also
the
release
management
side.
There's
a
lot
of
things
to
bring
to
the
group
level.
It's
it's
a
group
effort
and
I
think
we're
going
to
see
more
of
that.
A
A
So
the
idea
here
was
that
sometimes,
when
you
fork
a
project-
and
you
want-
let's
say
even
in
gitlab-
if
we
have
community
contribute
contributors,
contributors
that
want
to
check
their
pipeline
or
their
new
code
on
our
code,
you
don't
really
want
to
let
that
happen,
because
there
might
be
some
malicious
code
there.
But
on
the
other
hand,
you
won't
really
know
that
the
code
is
working
until
you
actually
try
it
out
on
the
parent
right.
A
So
there's
a
lot
of
requests
around
this
and
the
first
thing
that
we
we
did
deliver
on.
This
was
allowing
users
to
ask
for
maintainers
in
the
parent
project
to
run
it
for
them.
So
this
enforces
actually
a
maintainer
to
do
a
code
review
to
really
verify
that
there's
no
malicious
code
there
and
then
go
ahead
and
run
it
in
the
parent.
A
So
that's
kind
of
an
extension
of
the
yamos
and
everything
that
has
to
do
with
keywords
and-
and
things
like
that
are
in
this
area.
Then
we
have
cloud
deployment.
So
what
I
have
here
is
linked
I've
linked
epics,
underneath
these
epics
are
like
a
bunch
of
issues,
so
feel
free
to
click
through
them
and
ask
me
any
questions
in
cloud
deployments.
A
A
What
I
am
going
to
do
is
I'm
actually
writing
a
blog
post
about
what
we
did
in
aws
and
really
inviting
the
community
to
contribute
for
other
cloud
providers
that
they
wish
to
see
there
as
well
in
a
similar
fashion.
So
creating
these
docker
images
that
can
be
used
and
templates
and
then
we
can
connect
it
to
auto
devops.
A
So
I
think
that
blog
post
will
probably
be
published
early
december
and
and
we
can
and
maps
out
everything
that
we
did
in
terms
of
aws
but
there's
still
quite
a
ways
to
go
in
terms
of
our
streamlining
aws.
So
I
mentioned
that
we
have
we've
added
the
templates
and
we've
added
some
things
to
to
to
auto
devops
and
we've
added
these
images.
But
there's
also
other
things
that
that
we
want
to
do
so.
For
example,
success,
codes
and
stuff
like
that.
A
We
want
to
bring
them
into
the
gitlab
logs.
We
want
to
make
it
as
easy
as
users
for
pos
as
possible
to
stay
within
gitlab
and
not
have
to
juggle
around
between
different
tools
to
figure
out
if
their
deployment
was
successful.
So
we
want
to
bring
that
information
inside
and
inside
gitlab
inside
the
blogs
make
it
easier
for
users
to
understand
when
something
goes
wrong
and
they
need
to
fix
the
code.
B
A
More
success,
codes
templates
for
s3-
we
don't
have
yet
so
there's
still
a
lot
of
work
here,
also
auto
devops
kind
of
need
to
be
a
little
bit
fine-tuned
like
destin,
says,
to
work
smoothly
with
the
aws
targets
and
so
on.
So
there's
still
quite
a
lot
of
work
around
native
deployments
native
cloud
deployments
and
when
we
add
additional
targets
as
well,
we
also
would
need
to
address
multiple
cloud
deployments,
which
is
a
huge
trend.
That's
going
on
now,
and
I
see
that
as
a
main
focus
of
next
year.
A
Observability
so
we
talked
about
post-deployment
monitoring,
there's
also
a
think
big
session.
That's
linked
here
in
the
direction.
If
anyone
wants
to
go
ahead
and
watch
that
as
well
and
actionable
ci
cd
metrics.
I
actually
think
this
is
a
really
bad
link,
because
I'm
going
to
replace
this
with
the
dora
4
metrics
epic
and
instead
of
this
one,
because
I
think
it's
just
better
laid
out
so
I'll
just
say
a
few
words
about
dora
4,
and
I
will
make
a
note
for
myself
to
update
this
as
the
direction
page.
A
Is
one
of
the
this
is
already
a
industry
standard
people
want
to
know
that
their
investment
in
devops
is
working
out
and
they
want
to
know
that
they're
improving
over
time
and
so
there's
four
metrics
that
have
been
decided
as
the
industry
standard
to
figure
out.
If
your
team
is,
is
actually
improving
over
time
in
terms
of
your
devops
capability,
one
of
them
is
deployment
frequency
and
what
they
really
want
to
know
is
how
often
we
deploy
to
production
lead
time
for
changes
which
actually
means.
How
long
did
it
my
code?
A
A
Maybe
we
can,
you
know,
highlight
hey.
Did
you
know
that
we
have
this
feature?
This
can
help
you
out,
like
just
suggest,
to
the
user,
about
all
these
capabilities
that
they
may
or
may
not
know
about,
and
change
failure
rate
is
also
something
that
we
took.
A
get
lab
take
on
so
change
failure
rate
is,
is
degraded
service,
so
what
we
decided
to
count
here
is
actually
how
long
it
took
for
an
incident
to
get
resolved
so
we're
again
leveraging
monitors
incidence
response
and
that's
how
we're
counting
these
metrics.
A
A
A
You
want
to
know
how
many,
mrs,
the
team
is
doing
compared
to
other
teams,
and
this
is
interesting
data
for
any
team
leader,
but
also
for
the
team
themselves,
we're
all
in
the
edge
of
my
mindset
where
we
want
to
improve,
constantly
improve,
and
we
want
to
see
all
these
metrics
improve
over
time.
So
we
want.
We
want
this
to
be
both
approachable
for
the
team
so
on
a
project
level,
but
also
on
a
group,
an
instance
level
for
the
execs
so
really
really
interesting.
Stuff.
Here.
A
And
I'm
pretty
sure
that
we
also
have
a
recording
on
that,
which
I
will
link,
take
an
action
item
to
link
on
the
direction
page
as
well,
because
I
think
these
videos
are
really
help
you
understand
better
and
then
we
have
auto
deploy
stuff.
So
that's
like
the
fourth.
The
fourth
bucket
is
around
how
we
improve
auto,
deploy
both
for
kubernetes
and
non-kubernetes
users,
and
I
do
want
to
say
that
auto
deploy
is
not
a
main
focus
of
the
team.
A
We
will
leverage
it
when
it's
easy.
So
if
we
create
templates
for
any
cloud
deployment,
we'll
most
likely
connect
it
to
the
auto
doubles
flow
and
try
to
make
it
work
together
with
a
pipeline.
But
I
don't
see
us
currently
investing
lots
of
time
with
adding
additional
databases
or
other
managed,
apps
or
or
anything
around
that.
So
it's
really
important
for
me
to
to
mention
that,
because
I
think
as
important
as
to
say
what
we
are
working
on.
It's
also
really
important
to
say
what
we're
not
going
to
be
working
on.
A
So
if
anything
breaks
we're
going
to
fix
it-
and
we
had
quite
a
few
of
those
in
the
past
two
milestones
where
kubernetes,
upgraded
and
helm
did
some
end
of
life.
So
we
needed
to
respond
quickly
and
we
will
do
that,
but
we're
not
going
to
go
and
actively
try
to
connect
additional
sources
at
the
moment
to
that.
A
A
I
don't
see
that
happening
in
the
near
future,
but
I
do
see
us
and
the
community
supplying
small
docker
images
similar
to
what
we
did
for
aws,
but
it
probably
won't
do
anything
imaginable
and
imaginable
to
human
mankind.
Okay,
what
we
do
want
to
focus
on
is
having
really
good
working
examples,
so
people
can
understand
how
they
can
customize
the
images,
the
templates
and
just
connect
it
and
make
it
work
for
their
specific
use
cases.
A
What
we
can
learn
from
harness-
and
they
have
some
really
interesting
stuff-
that
I've
also
talked
with
the
pm
from
pipeline
authoring
about
and
also
from
configure
the
the
idea
is
that
they
visualize
the
pipeline
that
they
create
and
basically
deployments
they're
pretty
repetitive
jobs
that
you
can.
You
know,
create
a
pool
and
just
pick
that
pick
whatever
you
want
when
you're
doing
the
deployment,
so
you
can
see
here
they,
the
workflow
that
they
chose,
is
blue,
green
or
canary
deployment.
A
So
we
they
make
very
basic
building
blocks
and
then
they
create
the
pipeline
via
the
ui
and
the
verify
team
is
working
on
a
visual
editor.
So
I
see
this
tying
very
closely
together
we're
going
to
wait
and
see
what
they
come
up
with
and
see
how
we
can
build
and
contribute
on
top
of
that
for
the
cd
part.
A
A
A
A
So
that's
something
that
I
really
really
liked
and
you
can
also
get
to
the
analytics
section
from
that
same
page
and
understand
what's
going
on
and
we
kind
of
have
all
this
data
but
they're
scattered
around
gitlab.
So
I
think
consolidating
it
would
be
really
helpful
for
our
users
and
then
the
concept
is
is
really
the
same.
They
have
like
it's
cookie
cutter
for
any
any
cd
pipeline.
You
have
the
deploy,
you
have
a
verified,
the
deployment
is
fine,
and
then
you
have
a
cleanup
stage.
A
A
Yeah,
so
what
we
can
learn
from
spinnaker
and
similar
to
the
other
ones.
You
can
see
like
a
lot
of
screenshots
here
on
what
it
looks
like
in
spinnaker
and
there's
a
lot
of
things
again
that
we
do
support.
So
here
you
can
see
like
a
deploy
freeze,
so
they
added
deploy
freeze
to
the
pipeline
and
you
can
see
whether
or
not
you
can
deploy
it
this
time
and
sometimes
there's
a
manual
override.
A
A
And
what
I
really
liked
about
them
was
how
they
everything
that
you
have,
for
example,
in
in
the
cloud,
is
really
accessible
from
here.
I
can't
find
the
exact
screenshot
at
the
moment,
but
oh
here
you
can
see
like
all
information
exactly
what's
going
on,
you
can
click
on
it.
You
can
get
to
production,
you
can
get
to
the
aws
console
everything's,
just
really
approachable,
and
I
really
like
that
because
it
just
makes
it
easier
to
work.
A
So
when
we
talk
about
automatic
rollback
in
the
post-deployment
monitoring,
it
rolls
back
to
a
space
to
the
last
successful
deployment
here
they
allow
you
to
both
select
not
only
the
last
successful
deployment,
but
you
can
choose
like
a
specific
version
that
will
always
roll
back
to
so
that's
configurable
in
all
the
customer
interviews
that
I
did.
People
were
always
using
the
last
one,
so
I
don't
see
us
doing
that
in
the
near
future,
but
maybe
that'll
be
something
that
comes
up.
A
C
B
A
So
you
can
figure
that
in
the
system,
but
what
happens
if
you're
at
75
or
80.
So
that's
like
this
gray
area,
where
you
get
a
manual
intervention,
so
you
get
like
a
notification.
Hey
cpu
is
at
80.
What
do
you
want
to
do
and
then
you
can
take
action
in
that
case
in
that
sense,
and
that's
really
really
interesting,
and
I
think
it's
it's
a
great
thing
to
do
and
maybe
that's
something
we'll
pursue
after
we
finish
the
post-deployment
monitoring
mvc.
A
A
New
waypoint
is
something
that
hashcorp
just
introduced
last
month
and
it's
really
neat
because
it's
kind
of
that
concept
that
I
told
you
in
the
beginning,
where
the
developer
doesn't
really
care
what
what
the
infrastructure
is
or
where
they're
deploying
to
they
just
want
things
to
work,
and
this
just
makes
it
really
neat
to
choose
we're
actually
also
partnering
with
them.
So
you
may
still
do
a
deployment
via
gitlab
connect
to
waypoint.
So
there's
going
to
be
a
lot
of
options
here
to
integrate
with
waypoint
as
well.
A
Okay,
then
we
have
an
analyst
section
in
analysts.
There's
there's
a
few
areas
where
we
appear-
and
this
is
a
very
disruptive
space,
so
analysts
keep
changing
their
minds
and
what
what
they're
looking
at,
but
we
were
mentioned
as
in
the
cdra
wave
as
strong
performers,
which
was
great
because
it
was
a
huge
lead
from
the
previous
analyst
report
that
we
had
and
also
progressive
delivery
in
itself
has
analysts
that
are
focused
just
on
that
area.
A
But
as
we
have
a
combined
release
team
now,
I
think
that
this
is
all
going
together.
Release
orchestration
together
with
with
automation
and
continuous
delivery.
They
all
tie
in
really
nicely
together
and
I
think
we'll
have
a
really
nice
story
to
tell
to
analysts.
I
actually
got
off
the
phone
with
an
analyst
yesterday
regarding
developer
experiment,
experimentation
tools
and
everything
is
very,
very
tied
in
closely
here.
A
B
A
Well,
that's
a
great
question,
so
there's
so
many
features
that
it's
really
hard
to
say
where
we're
leading
I'm
gonna
take
spinnaker
for
for
an
example,
spinnaker
we
kind
of
support
almost
the
same
features
as
they
do,
but
they
approach
cd
differently.
They
approach
it
as
a
first-class
citizen,
whereas
we're
like
another
stage
in
the
ciamo,
and
so
it's
a
different
approach
in
that
everything
is
super
accessible.
It's
really
easy
to
do
stuff,
there's
a
lot
of
observability.
A
A
I
think
we
still
have
to
figure
out
the
cd
portion,
I'm
pretty
sure
that
people
would
prefer
to
have
one
tool
to
manage
everything
if
you're
already
building
your
ci
pipeline.
Why
not
do
this
to
department,
but
we
have
to
make
it
super
easy
and
accessible
to
do
all
these
things.
So
today,
for
example,
deploying
to
the
cloud
you
have
to
be
super
technical,
you
have
to
really
know
what
you're
doing
if
you're,
if
you're
just
getting
started.
I
don't
think
it's
easy
enough.
A
So
we
we
need
to
make
a
lot
of
improvements
there
also
spinnaker.
I
don't
know
how
familiar
you
are
with
it,
but
it's
it's
a
netscape
tool.
They
built
it
internally
and
then
they
saw
that
it
went
really
well
and
so
they
decided
to
sell.
It
also
has
the
it's
an
external
tool
and
when
you
think
about
it,
netflix
does
an
amazing
job
in
devops.
A
Think
about
the
amount
of
deployments
they
have
their
their
geographical
spread,
their
the
amount
of
experiments
they're
doing
at
any
given
time,
they're
just
doing
an
amazing
job
and
they
built
this
tool
for
them.
So
a
lot
of
customers
are
looking
at
them
and
saying
wow.
Netflix
has
a
really
complex
architecture.
If
this
is
working
for
them,
this
will
probably
work
for
my
simple
application
right.
So
so
there's
also
that
notion
and
they
also
have
like
fun
cool
stuff.
A
But
like
microsoft,
first
of
all,
github
action
is
really
powerful
and
you
can
really
find
a
lot
of
actions
there
that
you
don't
have
to
create
from
scratch
where
in
gitlab
you
we
don't
have
that
many
options,
but
also,
I
think,
microsoft
as
an
offering
to
enterprises.
For
example,
they
come
in
with
really
compelling
pricing
options,
so
they
can
tell
you
here,
take
take
develop
azure
devops
for
free,
if
you
sign
up
for
a
thousand
users
on
microsoft,
365
365
right.
A
So
they
have
these
bundling
opportunities
because
they
have
so
many
products
that
that
is
just
really
compelling
in
terms
of
price
that
the
user
have
to
pay
at
the
end
of
the
day
or
I've
heard
that
they
also
like
give
you
free
storage
on
azure,
if
you're
a
large
enough
customer.
So
this
in
the
end
of
the
day,
is
worth
money
right.
So
so
it's
kind
of
a
different
approaches.
B
B
A
A
A
So
that's
really
annoying
people
and
it
broke
a
bunch
of
their
scripts.
So
that's
like
the
top
customer
issue
that
we're
working
on
and
then
top
internal
customer.
If
I'm
not
mistaken,
this
was
from
the
delivery
team,
but
don't
take
my
word
for
it.
For
it
we
can
check
this
out
later,
is
adding
a
maximum
commits
before
merge.
So
sometimes
it
really
it
it's
a
rebasing
nightmare.
If
you
have
a
ton
of
commits
before
before
you
merge-
and
this
is
just
going
to
make
that
easier,.
A
And
then
top
vision
items
so,
as
I
mentioned
also
in
our
conversation,
this
has
been
the
main
focus
of
the
team
this
year
and
also
next
year,
which
is
natively
supporting
hyper
cloud
appliance.
This
is
becoming
a
basic
operation
and
we
just
need
to
make
this
really
simple
for
any
user
to
deploy
to
any
cloud
or
multiple
clouds,
and
I
think
that's
going
to
be
our
main
focus
as
a
team
in
2021,
and
I
got
through
the
whole
page
in
under
an
hour
and
I'm
so
proud
of
myself.