►
From YouTube: Technical Bootcamp - AutoDevOps and GitLab CI
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
A
Everything
in
get
lab
ci
starts
with
a
yaml
file,
and
that
is
a
declarative,
configuration
format
we
use
to
define
jobs
and
the
rules
for
triggering
those
jobs.
Now
the
gitlab
ci
file
lives
within
the
repository
itself.
Now
this
may
be
a
bit
different
from
other
ci
systems,
where
the
ci
and
cd
platform
is
housed
and
executes
in
a
separate
system.
A
Within
this
same
system,
we
can
also
potentially
avoid
unannounced
breaking
changes
and
that
can
catch
teams
off
guard
and
generally
cause
problems.
What
we're
looking
at
here
is
a
sample
ci
file
and,
as
I
mentioned
before,
gitlab
ci
is
very
feature
rich,
so
we
won't
get
into
all
of
the
capabilities
today.
A
So
what
we
see
here
is
a
very
simple
job.
Each
job
is
a
unit
of
work.
It
has
several
components
like
the
name
of
the
docker
image
and
the
commands
that
will
be
run
in
that
docker
image.
Docker
is
a
first
class
citizen
within
gitlab
ci,
and
you
don't
have
to
use
it,
but
it's
very
handy
for
portability
and
consistency
and
what
you
see
here
is
actually
a
valid
ci
file.
If
we
took
these
four
lines
and
put
them
in
a
file,
it
would
work.
A
Here's
a
slightly
more
advanced
job,
it's
called
compile
and
it
specifies
the
stages
it
should
be
run
in
stages,
basically
give
you
an
order
of
operations
to
run
your
jobs
in
we've
also
defined
some
conditions
under
which
this
job
should
be
run,
and
some
artifacts
that
will
be
generated
that
we
may
want
to
use
later
now.
In
this
case,
this
is
just
an
overview.
We're
not
going
to
be
going
into
conditions
and
artifacts
as
part
of
this
video,
but
I
just
want
to
show
something
slightly
more
advanced.
A
A
You
can
even
create
a
separate
git
repository
just
for
ci
files
and
reference
them
from
other
projects.
This
comes
in
handy
when
you're
wanting
to
keep
automation,
centralized
and
consistent
across
a
large
organization
here,
we're
referencing
the
included
sas
cis
file,
which
enables
static
application
security
scanning
on
our
jobs.
Automatically
rules
give
us
conditional
behavior,
in
this
case
I've
added
an
if
statement
that
triggers
the
job.
Only
if
we're
in
a
merge
request
here,
we
have
an
auto
devops
ci
pipeline
you'll,
see
a
build
stage.
A
Multiple
tests
and
scans
being
run
a
review,
app
being
deployed,
das,
scan
performance
scan
and
even
additional
jobs
that
we
can't
see
here.
This
is
all
generated
automatically
as
we'll
see
in
the
future
lab
yaml,
and
this
approach
to
ci
may
be
new
for
you,
in
addition
to
the
ci
files
that
come
bundled
with
your
installation
of
git
lab.
We
also
host
many
example:
ci
files
and
repositories
on
gitlab.com,
and
these
files
are
open
for
you
to
use
in
your
own
projects
or
even
contribute
back
to.
A
We
have
a
page
that
links
to
many
of
these
repos
in
our
documentation
and
it's
a
great
starting
point.
Depending
on
your
programming
language,
the
infrastructure
you
deploy
to
or
your
security
concerns,
so
with
very
little
effort,
you
can
have
a
ci
pipeline
that
automates
many
of
your
tedious
tasks.
A
The
merge
request
screen
will
probably
be
the
most
common
place,
you'll
utilize
pipelines
on
each
commit
that
triggers
a
new
pipeline.
The
merge
request
screen
updates
to
show
that
pipeline
and
gives
visibility
into
the
status
of
each
job.
Typically,
the
same
pipeline
is
run
after
the
merge
is
complete
just
to
ensure
quality
and
verify
the
outcome
of
the
merged
branch.
A
So
the
natural
progression
from
continuous
integration
is
continuous
deployment
and
deployment
of
environments
are
first-class
citizens
within
gitlab.
This
makes
it
easy
to
monitor,
manage
and
connect
to
terminal
of
various
environments.
Here
I
can
see
two
running
environments,
a
production
and
a
staging,
as
well
as
health
statuses
of
pods.
Within
that
deployment.
A
A
A
Kubernetes
is
a
huge
part
of
gitlab,
just
like
docker,
it's
a
first-class
citizen.
If
you're
running
workloads
on
kubernetes,
regardless
of
cloud
provider,
you'll
be
able
to
easily
take
advantage
of
more
advanced
features
of
gitlab,
it's
also
very
easy
to
deploy
commonly
used
apps
like
nginx,
ingress,
cert
manager
or
prometheus
straight
from
the
ui.
A
The
integration
works
with
existing
clusters
or
will
provision
new
clusters
on
amazon,
eks
or
google
gke.
It's
really
just
a
matter
of
entering
the
credentials
to
get
connected
almost
instantly,
and
this
allows
your
organization
to
get
started
using
kubernetes
very
quickly.
We
discussed
having
review
apps
and
those
were
used
for
dynamic
scans
and
performance
testing,
and
it's
common
that
those
review
apps
might
need
a
database
or
a
regis
storage,
and
if
you
had
a
large
number
of
review
apps,
that
would
be
a
very
useful
scenario
for
utilizing
kubernetes.
A
So
if
you're
new
to
ci
or
just
new
to
gitlab
and
want
to
take
advantage
of
many
of
the
capabilities
quickly,
you
can
utilize
auto
devops.
This
is
best
used
for
database
driven
web
apps
running
ruby
on
rails,
django,
node.js
or
similar
to
get
started.
You
only
need
to
connect
to
your
kubernetes
cluster,
ensure
autodevops
is
enabled
in
your
project
and
add
code
to
your
repository.
A
Autodevops
will
containerize
your
application
via
docker
run
any
existing
unit
and
integration
tests
perform
code,
scans
security
license
scans
and
provision
a
review,
app
it'll,
also
handle
deployments
and
more
without
you
having
to
write
any
automation,
it's
pretty
cool.
Now,
let's
get
into
our
lab
2,
auto
devops.