►
From YouTube: Sponsored Lightning Talk: Step into the Lab: An intro to GitLab CI/CD - Parker Ennis GitLab
Description
Sponsored Lightning Talk: Step into the Lab: An intro to GitLab CI/CD - Parker Ennis GitLab
Speakers: Parker Ennis
In this lightning talk, hear Parker Ennis explain how the GitLab DevOps platform can automate your application and infrastructure deployments - across multiple kubernetes environments, multiple clouds, using different deployment strategies - all from a single application requires no integrations (and hey, we integrate well with others too).
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
But
you
know
enough
of
the
the
little
historical
lesson
right.
That's
just
a
passion.
What
I
really
want
to
point
out
at
the
highest
level
is
these
goals
that
you
see
on
the
screen
right
and
and
how
important
they
are
to
your
business
in
in
your
day-to-day.
If
you're
a
developer,
you
know
writing
code
and
working
on
developing
features.
A
The
other
thing
I
want
to
point
out
is
the
diagram
over
on
the
right
gitlab
flow,
and
that's
our
opinionated
take
on
how
devops
should
work
for
the
entire
life
cycle,
which
we
cover
again
that
you
know.
Of
course,
cicd
plays
an
instrumental
role
all
the
way
from
when
you're,
creating
your
issue,
committing
changes
on
a
feature,
branch
or
running
automated
builds
and
tests
reviewing
those
changes
and
getting
the
feedback
right
then.
A
Is
is
based
on
the
fact
that
we
want
to
unify
teams
and
leverage
that
automation
and
the
best
practices
so
that
you
can
deliver
better
software
faster
and
so
in
the
past
we
may
have
had
something
like
a
need
for
a
phd
in
tools
and
automation.
You
have
reactive
teams,
you
have
plug-in
pain
and
suffering
right
and
fragility
at
any
scale
when
you're
trying
to
to
execute
these
workloads.
A
A
I
think
of
three
big
pillars
here
when
I
think
of
continuous
delivery
with
gitlab
unified
deployment
and
monitoring
strategies,
so
the
ability
to
visualize
what's
going
into
production?
What
are
you
deploying?
Where
are
you
deploying
and
then
who
are
you
deploying
it
to,
but
also
monitoring
the
performance
of
your
deployments
and
having
that
ability
to
roll
back
based
on
performance
and
those
insights
all
in
one
place
a
single
application?
A
So
you
can
see
status,
know,
know
the
health
of
your
deployments
and
environments
and
then
visualize
all
those
things
very
easily,
then
also
think
of
any
cloud
anytime
anywhere
right.
So
you
know
not
just
multi-cloud
deployment
right,
no
favoritism
ultimate
flexibility
is
what
I
think
of
with
gitlab,
and
we
support
deployments
of
your
applications
to
multiple
different
targets,
whether
it's
virtual
machines,
kubernetes
clusters,
which
have
a
inherently
higher
learning
or
steep
learning
curve
right
or
various
cloud
providers
like
the
the
ones
we
hear
about
all
the
time,
aws
azure
gcp
amongst
others.
A
He
said
that
a
progressive,
progressive
delivery
ensures
the
strength
and
flexibility
of
a
system
through
numerous
creative
experimentations.
We
hear
a
lot
nowadays
about
developer
experimentation
and
developer
experiment
or
developer
experience
and
good
thing,
get
lab
excels
and
empowering
developers
to
be
their
best
right.
But
at
the
end
of
the
day
I
think
of
it
is
we
want
to
ship
faster
and
smaller
increments
right.
It
all
goes
back
to
those
building
blocks
of
ci.
A
So
let's
explore
some
of
these
strategies
right,
whether
it's
incremental
rollouts,
which
are
which
are
supported
to
roll
out
changes
to
your
application,
with
the
ability
to
release
those
production
changes
only
to
a
portion
of
your
kubernetes
pods
and
mitigate
that
risk.
You
can
do
that
by
manually
triggering
triggering
or
timing.
A
Those
rollouts
and
those
timed
rollouts
behave
in
a
similar
way
right,
except
that
each
job
is
defined
with
the
delay
in
x,
amount
of
minutes,
for
example,
before
it
deploys
right,
giving
you
more
control
over
how
you
deliver
and
when
and
then
blue
green
right.
It's
also
known
as
ab
deployments
or
red
black
deployments,
a
similar
technique
and
pretty
popular
these
days
still
to
reduce
that
risk
of
downtime
and
overall
mitigation
of
risk
when
you're
deploying.
A
So
you
can
combine
that
with
something
like
incremental
rollouts
and
minimize
the
impact
of
a
potential
issue
growing
and
getting
bigger
and
then
canary
deployments,
one
of
the
most
popular
for
sure,
where
a
small
portion
of
your
fleet
or
your
servers
is
updated
to
the
newest
version.
First
and
foremost,
and
then
you
know
this
subset
or
the
canaries
is
then
tested
and
rolled
out
to
the
rest
of
the
fleet.
So
there's
an
early
indication
of
any
danger
if
it
would
be
there
and
then
I
also
wanted
to
touch
on
feature
flags
right.
A
I
can't
I
can't
talk
about
everything
and
everything's
not
included
on
the
page,
but
feature
flags
are
important.
They
can
use,
they
could
be
used
to
enable
a
feature
to
be
tested
even
before
it's
completed
or
ready
for
release
right
be
able
to
move
fast
iterate.
These
are
things
we
need
to
be
able
to
do.
A
A
Then,
of
course,
a
plug
for
door
right
very
popular
today,
we've
got
one
out
of
the
four
live
right
now
with
lead
time
for
changes,
as
you
can
see,
they're
planned
for
our
june
22nd
major
release
of
gitlab
14.0
and
then
the
the
the
other
two
are
on
the
roadmap,
and
so
I
encourage
you
to
check
out
that
link
where
it
says
and
plenty
more.
If
you're
curious
about
more
details,
finally
got
about
a
couple
minutes:
a
little
under
two
minutes
left
for
get
ops.
A
A
It's
not
a
single
product
or
plugin
or
platform
right
git,
ops,
workflows
are
something
that
help
teams
manage
it
infrastructure
through
processes
they
already
use
in
application,
development
and
best
practices
at
that,
such
as
version
control,
collaboration,
compliance,
nci
cd,
and
it
applies
these
things
to
infrastructure
automation.
So
when
you
think
infrastructure
is
code,
you
know
github
goes
far
beyond
that.
It's
almost
like
xac.
A
Instead,
iac
everything
is
code,
the
infrastructure,
config
policy,
basically
any
operation,
that's
defined
as
code
and
there's
a
lot
of
power
in
storing
the
desired
state
that
you'd
like
and
get
in
having
that
version,
control
and
then
merge
requests.
These
are
our
agents
of
change
right,
also
known
as
a
pull
request
in
in
other
areas
or
change
requests
if
you'd
like,
but
we
call
them
merge
requests
here
at
gitlab
and
that's
essentially
our
audit
trail
of
what
was
changed.
A
What
and
where
right
many
can
contribute
it's
giving
you
that
gating
and
that
collaborative,
feel
and
you've
got
a
single
source
of
truth
and
then,
let's
transition
to
ci
cd.
Very,
very
quickly,
you
know
how
do
we
reconcile
iac
and
get
ups
right?
You
know
if
gitops
is
automating
the
infrastructure
and
updates
using
your
git
workflow
that
new
code
comes
in
is
merged
and
the
ci
cd
pipeline
enacts
that
change
in
an
environment,
so
any
configuration
drift,
etc.
A
Getting
in
front
of
the
things
that
you
need
to
worry
about,
that
happens,
but
git
ops
is
very
different
than
iec,
because
there's
no
version
control
requirement
with
just
infrastructures
code.
It
lacks
the
change
approvals
and
the
automation
isn't
necessarily
mandated.
So
we
like
to
think
of
good
ops
as
infrastructure
as
code
done
right,
and
I
wish
I
had
more
time
to
go
into
it.
But
but
that's
all
we
have
time
for
today.
A
So
I
encourage
you
to
check
it
out
some
resources
which
you
can
find
right
here
when
this
is
distributed,
and
please
do
reach
out
to
me.
I
can
talk
about
this
for
hours,
but
I
really
appreciate
your
time
and
I
hope,
you're
staying
safe,
happy
and
healthy
and
I'd
love
to
hear
from
you.
You
can
see
in
the
bottom
right
there,
my
email
or
reach
out
to
me
on
linkedin,
and
we
can
dive
into
any
of
this
more
if
you'd
like
take
care.