►
From YouTube: Getting started with GitLab CI/CD
Description
Recorded using GitLab v13.0
Technical Bootcamp Prerequisite 3
A
Hi
everyone,
my
name,
is
Kurt
2sec
I'm,
a
solution
architect
with
gitlab
and
today
I'm
going
to
be
going
over
getting
started
with
get
lab,
CI
and
CD.
As
many
of
you
know,
gitlab
is
a
DevOps
platform
that
covers
the
entire
software
development
process
and
today
we're
gonna
be
focusing
on
the
verify
and
release
stages.
Now
you
may
have
seen
this
diagram
before,
but
we're
gonna
talk
about
what
fills
in
some
of
these
automated
build
and
test
bubbles.
A
There
are
many
different
ways
of
running
git
and
implementing
CI
and
CD,
but
this
approach
is
our
opinion.
The
best
way
to
implement
a
smooth
running,
DevOps
lifecycle,
everything
in
get
labs
CI
starts
with
a
yellow
file
and
that's
a
declarative
configuration
format
that
we
use
to
define
jobs
and
the
rules
that
trigger
those
jobs
and
the
get
lab
CI
file
lives
within
the
repository
itself.
This
is
a
different
approach
from
other
CI
systems,
where
the
configuration
is
housed
and
execute
in
a
different
system.
A
Our
belief
is
for
something
to
be
true,
DevOps,
that
the
developers
and
the
operators
should
be
as
close
together
as
possible,
because
this
allows
those
groups
to
make
changes
and
decisions
together
within
the
same
system
and
potentially
avoid
unannounced
breaking
changes
that
can
catch
teams
off
guard
and
generally
cause
problems.
This
is
a
sample
CI
file
get
labs.
Ci
is
very
feature-rich,
so
we
won't
be
getting
into
all
of
the
capabilities
today.
A
The
file
is
named,
dot,
get
lab,
CI
ml
and
that's
a
reserved
name
that
sits
at
the
root
level
of
the
project
and
get
lab
will
know
to
read
that
file
at
every
commit
and
apply
the
appropriate
jobs
based
on
the
rules
defined
in
that
file.
Each
job
is
a
unit
of
work
and
it
has
several
components:
the
name
of
the
job,
the
docker
image
and
the
commands
that
will
be
run
within
that
docker
image.
Docker
is
a
first-class
citizen
within
gitlab
CI.
A
You
don't
have
to
use
it,
but
it's
very
handy
for
portability
and
consistency
and
what
you
see
is
actually
a
valid
CI
file.
If
I
only
had
these
four
lines
in
my
gitlab
CI
ml
file,
it
would
work,
and
it's
really
that
easy-
it
doesn't
take
much
to
get
up
and
running
here's
a
bigger
job
that
builds
a
go
project.
In
this
case.
It
identifies
the
stage
it
should
be
running
and
the
stage
is
basically
the
order
of
operations.
We've
also
identified
some
conditions
under
which
it
should
run
and
some
artifacts
that
will
be
generated.
A
This
is
just
an
overview,
so
we're
not
going
to
be
going
into
conditions
and
artifacts
I
just
want
to
show
some
things
that
are
slightly
more
advanced
now.
A
pipeline
is
multiple
stages
that
run
in
sequence,
and
you
can
define
the
stages
as
a
list
in
the
order
you'd
like
them
to
run.
You
can
also
include
various
CI
files,
and
this
is
a
very
useful
feature,
since
we
can
include
files
from
other
projects,
remote
locations
or
CI
files
that
come
bundled
within
gitlab.
A
You
can
even
create
a
separate
git
repository
for
CI
files
and
then
reference
them
from
other
projects.
This
comes
in
handy
when
wanting
to
keep
automation,
centralized
and
consistent
across
your
entire
organization.
Here
we're
referencing
the
included,
SAS
CI
file
and
that
enables
static
application
security
scanning
on
our
jobs
automatically.
A
This
is
a
pipeline
overview.
We
can
see
the
branch
in
the
commit
that
it
ran
against
and
we
can
see
the
stages
and
the
individual
jobs.
Under
these
stages.
We
have
quite
a
few
jobs
under
test
and
we
can
configure
all
of
these
to
allow
failure
or
run
asynchronously
depending
on
the
needs
of
the
project.
Pipelines
can
be
triggered
in
multiple
different
ways.
The
most
common
is
via
git
commit.
A
However,
you
can
kick
off
pipelines
to
run
based
on
a
given
schedule,
be
a
call
to
the
API
or
manually
by
clicking
a
button
within
the
application.
With
all
this
flexibility,
gitlab
is
more
than
just
a
CI
tool
for
source
code.
It's
a
full
automation,
platform,
ya
Milland.
This
approach
to
see
I
may
be
new
to
you.
A
So,
in
addition
to
the
CI
files
that
come
bundled
in
your
installation
of
git
lab,
we
host
many
examples:
CI
files
and
repositories
on
get
lab
comm
and
these
files
are
open
for
you
to
use
for
your
own
projects
or
to
contribute
to.
We
have
a
page
that
links
to
many
of
these
repos
in
our
documentation.
This
is
a
great
starting
point.
Depending
on
your
programming
language,
the
infrastructure
you
deploy
to
or
your
security
concerns
with
very
little
effort.
You
can
have
a
CI
pipeline
that
automates
many
tedious
tasks.
A
The
merge
request
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.
The
natural
progression
from
CI
is
CD
and
deployment
environments
are
first-class
citizens
with
India
lab.
This
makes
it
very
easy
to
monitor,
manage
and
connect
to
a
terminal
of
various
environments.
A
Here,
I
can
see
two
running
environments,
production
and
staging,
as
well
as
the
health
status
of
pods
within
those
deployments.
This
is
the
CI
plan
log
that
shows
the
history
of
the
pipelines
that
have
run
from
here.
You
can
view
the
details
on
what
specific
pipelines
were
triggered
and
their
status.
You
can
also
reach
for
jobs,
download,
artifacts
and
view
the
logs
for
more
details.
The
configurable
Operations
dashboard
is
very
useful
for
managers
or
DevOps
engineers
to
get
an
at-a-glance
view
of
pipelines
and
their
statuses
from
various
projects.
A
This
report
can
be
tailored
to
show
details
on
different
projects
across
an
entire
group.
Kubernetes
integration
is
a
huge
part
of
gitlab
and
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
the
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.
The
integration
works
with
existing
clusters
or
will
provision
new
clusters
on
Amazon
eks
or
Google
gke.
A
It's
really
a
matter
of
entering
the
credentials
to
get
connected
almost
instantly.
This
allows
your
organization
to
get
started
running
kubernetes
very
quickly.
If
you
have
a
large
number
of
development
builds,
that
would
be
a
very
useful
scenario
for
utilizing
kubernetes.
Even
if
you're,
not
using
kubernetes
in
production,
you
can
still
use
it
for
review
apps
staging
environments
and
take
advantage
of
the
many
useful
management
features
to
streamline
those
efforts
and,
if
you're
new,
to
CI
or
just
new,
to
get
lab
and
want
to
take
advantage
of
many
of
the
capabilities
quickly.
A
You
can
utilize
Auto
DevOps.
This
is
best
used
for
database
driven
web
apps
running
Ruby
on
Rails,
Jango,
nodejs,
or
something
similar
to
get
started.
You
only
need
to
connect
to
your
kubernetes
cluster
and
sure
Auto
DevOps
is
enabled
in
your
project
and
add
code
to
the
repository
Auto
DevOps
will
containerize
your
existing
application
via
docker
run
any
existing
unit
and
integration
tests
perform
code,
quality
security
and
license
scans
provision.
A
review
app
handle
your
deployments
and
more
without
having
to
write
any
automation.
It's
pretty
cool.
A
In
today's
lab,
we're
going
to
add
automation
to
our
project
will
create
a
new
get
lab
CI
mo
file.
Within
our
repository
we
use
a
template
to
populate
that
file
and
then
we'll
make
a
small
change
just
to
understand
how
it
works
now,
I'm,
starting
with
a
merge
request,
because
I
want
to
use
a
proper
get
flow
for
this
change.
So
the
first
thing
we
want
to
do
is
open
our
web
IDE.