►
From YouTube: Introduction to GitLab CI/CD
Description
Come learn about what CI/CD is and how it can benefit your team. We will cover an overview of CI/CD and what it looks like in GitLab. We will also cover how to get started with your first CI/CD pipeline in GitLab and the basics of GitLab Runners.
A
Okay,
we're
gonna
go
ahead
and
get
started
again
thanks
everyone
for
joining
us.
My
name
is
Taylor
Lund
I'm,
a
member
of
the
customer
success
team
here
at
gitlab,
we're
happy.
You
joined
us
today.
Today's
session
is
going
to
focus
on
an
intro
to
get
lab
CI
CD
before
I.
Kick
it
over
to
my
colleague
Rasheed
we're
going
to
go
through
a
couple
of
housekeeping
items.
A
First
off
this
webinar
is
being
recorded,
so
you
can
look
for
that
recording
to
come
through
into
your
inbox
here
in
the
next
couple
of
days,
along
with
the
deck
for
any
questions
that
come
up
throughout
the
session.
Please
go
ahead
and
put
those
in
the
Q
a
portion
of
your
Zoom
window.
We
will
answer
those
throughout
the
set
session
and
Rasheed
will
be
able
to
answer
a
few
towards
the
end
and
without
further
Ado
I
will
kick
it
over
to
Rasheed.
Who
is
a
member
of
our
customer
success
team
as
well?
B
Thank
you
Taylor
and
again.
My
name
is
Rasheed
and
yeah
I've
been
here
about
eight
months
and
I'll,
be
presenting
to
you
some
foundational,
beginner,
Concepts
and
usage
around
gitlab,
CI
CD,
so
I
guess
just
to
kick
it
off
here.
The
things
that
are
going
to
be
out
of
scope
are
going
to
be.
You
know,
kind
of
detailed
set
up
and
configuration
on
that.
You
can
take
our
one
day,
CI
CD
course
for
this
in-depth
usage
and
best
practices
for
project
management.
That's
another
one
day.
Project
management
course
available
as
well
and
system.
B
Initial
setup
and
management
is
also
available
with
our
one
day
system,
administrator
training.
B
So
our
agenda
today
is
going
to
be
what
is
CI:
CD
gitlab
cicd
overview,
gitlab
CI,
CD
setup,
gitlab,
cicd,
Runners
and
Q
a
and
we'll
go
over.
You
know
all
four
of
those
and
end
with
the
Q
a
to
a
few
questions
from
the
from
the
chat.
B
So
what
is
gitlab
a
gitlab
is
a
single
platform
that
supports
all
10
stages
of
the
the
dev,
the
devops
lifecycle,
as
established
by
Gartner,
and
it
Bridges
Dev
and
Ops
with
the
gitlap.
It's
also
a
git
repository
manager
as
well,
and
it
integrates
it's
a
fully
integrated
software
development
platform
that
enables
your
team
to
be
transparent,
fast,
effective
and
and
cohesive.
From
the
discussion
of
a
new
idea
to
production
all
on
the
same
platform.
B
It's
a
web-based
devops
lifecycle
tool
and
it
provides
you
know,
a
git
repository
manager
Wiki.
It
has
the
issue
tracking
security
pipeline
features
and
it
has
an
open
source
license
and
it's
also
developed
you
know
developed
by
it
by
gitlab
with
gitlab
you
get
the
complete
platform
developed.
You
know
basically
delivered
in
one
single
application.
It
empowers
teams
to
work
together
efficiently
and
you
know:
build
scalable
end-to-end
automation
through
gitlab,
and
you
can
you
know
just
so.
You
can
see
everything
that
matters.
You
can
see
it
all.
B
On
one
platform,
the
current
technology
stack
just
to
in
mind,
keep
in
mind
it
uses
a
gold
Ruby
on
Rails
and
vue.js
follows
open
core
development
model.
Where
the
core
functionality
is
released
under
the
open,
open
source
MIT
license,
while
additional
functionality
is
under
a
proprietary
license,
it's
a
web-based
lifecycle
tool
that
provides.
You
know,
you
know
again,
those
those
features
are
previously
mentioned,
and
it
goes
you
know
it
empowers.
You
know
again.
Scalable
internet
automation,
foreign.
B
So
continuous
integration,
it's
a
development
practice
where
you
know
devs
integrate
code
into
shared
repositories.
Frequently,
each
integration
can
then
be
verified
by
an
automated
pipeline
that
tests
code
before
merging
to
the
main
branch
CI
you
know
with
CD
CD
is
kind
of
an
overloaded
term.
It's
it's
continuous
delivery,
so
there's
continuous
delivery,
which
is
the
practice
of
keeping
your
code
base
Deployable
at
any
point.
B
So
so
that's
just
you
know
it's
something
where,
with
within
gitlab
gitlab,
actually
does
it
monthly
through
monthly
releases
on
you
know,
20
second
of
each
month
that
go
to
self-managed
customers
through
you
know
that
would
be
the
continuous
delivery
portion
of
it.
But
as
each
merge
request
is
approved,
each
feature
is
automatically
implemented
into
gitlab.com,
so
that
would
then
be
the
continuous
deployment
stage.
So
it's
something
that's
done
continuously
and
synergistically
together
on
on
the
gitlab
side.
B
So
we
do
both
delivery
and
deployment
just
just
as
we
see
here
and
what
that
does.
It
leads
to
faster
time
to
Market.
You
know,
as
far
as
being
able
to
work
together
to
automate
each
phase,
the
team
is
able
to
have
you
know
developers
integrate.
You
know,
you
know
regression
testing
into
their
daily
work
that
provides
higher
quality.
You
know
when
developers
have
automated
tools
that
can
discover
regressions
within
minutes.
B
You
know
it
frees
them
up
to
focus
on
things
like
user
research,
higher
level
testing
activities,
exploratory
testing,
you
know,
there's
things
to
kind
of
Ensure
the
overall
holistic
nature
of
the
whatever
the
product
that
they're
working
on
at
the
time,
and
this
ensures
that
quality
is
built
into
the
product
and
services
from
the
beginning
and
that
you
know
in
term
Lord
in
turn,
it
lowers
the
cost
by
you
know
you
know.
So.
B
By
investing
in
build
tests,
deployment
and
environment
automation
you
know
causes,
then
you
know
just
reduced
significantly
and
also
results
in
happier
teams
to
do
the
the
less
painful
you
know
you
know
and
reduce,
reduces
team
burnout.
B
So
why
use
CI
CD
well
with
cicd
a
lot
of
the
common
complaints?
Are,
you
know,
brittle
tools
for
some
environments,
where
you
know
we're
spending
too
much
time,
maintaining
and
updating
these
tools
and
actually
creating
new
features
or
or
the
slow
modernization
where
they
want
to?
You
know
want
to
leverage,
microservices
and
and
Cloud
native
deployment,
but
spend
too
much
time
putting
out
fires.
So
here
you
know
with
cicd
it
encourages
collaboration
across
all
departments
and
makes
co-creation
and
management
easy
as
well
as
provides
the
following.
B
You
know
specific
benefits
that
we
see
here
on
this
on
this
slide
and
that
is
detecting
errors
quickly.
Reducing
integration
problems,
you
know
smaller
problems
are
easier
to
digest
and
insurance
problems.
Don't
compound.
Ci
also
allows
teams
to
develop
faster.
You
know,
through
the
automation,
more
confidence
among
the
developers
and
that
allows
for
less
bottlenecking,
and
then
we
go
back
around
to
the
leftward
and
CD
CD
actually
ensures
every
change
is
releasable.
This
lowers
the
risk
of
each
release
allowing
releases
you
know
to
be
boring.
You
know,
there's
no,
no
big
events
that
are
happening.
B
You
know,
as
far
as
the
releases
is
something
that
you're
already
expecting
to
to
be
automatically
tested
and
deployed.
Accordingly,
CD
delivers
value
quickly
and
more
often
so
you
get
fast
feedback
on
what
your
end
users
care
about
foreign.
B
B
Because
of
this
many
organizations,
you
know
it,
they
end
up
with
workflows
that
are
too
complicated
and
not
clearly
defined,
and
so
and
and
so
they're
not
integrated
with
the
the
issue
tracking
systems
that
they're
working
with.
B
Therefore,
here
we're
proposing
the
gitlab
flow,
it
combines
feature
driven
development
and
feature
branches
with
issue
tracking
the
gitlab
flow
is
is
a
clearly
defined
set
of
best
practices.
You
know
to
simplify
the
the
branching
strategy,
it
allows
for
production
in
stable
branches,
bug,
fixes
and
hop
fixes.
B
You
know
patches
of
Cherry
Picked
from
the
main
and-
and
we
recommend
you
know,
teams
to
follow
the
get
lab
flow
process
while
using
gitlab,
because
it
just
allows
for
you
know
again
best
practices
and-
and
you
know,
you're
able
to
you-
know
kind
of
easily
get
get
in
getting
get
in
flow,
with
the
merge
requests
being
the
core
of
the
project.
B
B
The
feature
Branch
represents
the
source
code
pattern
where
you
know
essentially
developer,
opens
the
branch
and
begins
working
on
new
features
and
that
work
is
soon
integrated
into
the
main
branch
and
we
We
Begin
by
creating
a
discrete
unit
of
work,
that
we
call
an
issue
and
you
could
think
of
that
as
like
a
ticket.
B
So
we
assign
the
issue
to
a
team
member,
and
so,
if
you
see
here
from
that
issue,
we
spawn
it
up
to
a
feature
branch,
and
you
can
think
of
this,
as
you
know,
think
of
it
as
a
parallel
line
of
the
development
developers
moved
to
the
branch
and
to
interact
with
the
request.
B
Gitlab
provides,
updates
and
notifications
on
the
state
of
your
issue
automatically.
So
you'll
see
every
step
of
the
way.
If
you,
if
you
work
with
a
feature
Branch
for
more
than
a
few
hours,
it's
best
practice
to
share
the
result
with
your
immediate
team.
So
it
may
not
be.
B
It
may
not
be
ready
to
be
merged,
but
feedback
is
definitely
welcome,
and
so,
when
your
team,
let's
see
when
your
team
makes
comments
on
the
merger
quest
in
general
or
you
know,
or
on
specific
lines,
that
you
know
the
merger
Quest,
it
can
be
used
as
a
as
a
code
review
tool
and
and
so
that
way,
no
separate
tools
should
be
needed
when
you're
comfortable
with
your
work
and
the
comments
are
made,
you
can
assign
it
to
someone
who
knows
the
most
about
the
code
base
or
someone
who
has
permission
to
merge
into
the
main
branch.
B
We
have
code
review
and
conflict
resolution
built
into
the
platform
you
know
to
for
merge
conflicts.
So,
as
you
can
see
here,
you
know
we're
seeing
the
the
flow
from
an
issue
over
to
production
and
so
the
commit
kicks
off
in
automated
continuous
integration
pipeline.
So
once
that
commit
is
made,
the
the
CI
pipeline
runs
and
then
it
moves
on
to
the
security
scan
and
the
advantages
that
developers
have
visibility
into.
What's
going
on,
you
know
in
the
cycle.
B
And
once
we
move
over
to
the
review
app,
we
can
actually
you
know
view
what's
normally
on
localhost.
You
know
on
you
know
in
in
the
you
know
all
integrated
into
the
pipeline
and-
and
you
can
have
discussions
around-
that
approve
changes
and
then
once
the
issue
is
closed,
then
the
an
emergency
is
is
merged
in
the
pipeline.
The
CD
pipeline
runs
and
then
from
there
we'll
get
security
scans
and
be
able
to
actually
view
different
results
in
the
security
dashboards
foreign.
B
So
after
your
team
creates
code
in
in
this,
this
slide
here
is
the
the
verify
stage,
you'll
be
using
gitlabs,
automated
testing
and
Reporting
capabilities,
and
this
ensures
high
quality
gitlab
lets.
You
use
continuous
integration
to
automate
the
bills,
the
integration
and
verification
of
your
code.
Various
types
of
tests
give
your
team,
you
know
fast
feedback
on
the
on
the
code
quality
together,
it
continues
to
delivery
and
deployment.
You'll
get
insight
about
every
commit
and
you'll
be
able
to
deliver
high
quality
code
faster,
and
you
know,
references
to
this
information
will
be
provided.
B
You
know,
after
the
after
the
webinar
as
well
foreign.
So,
let's
consider
the
following
example
of
gitlab:
cicd
basic
workflow:
let's
assume
that
you've
discussed
the
code
implementation
in
an
issue
and
you
and
work
directly.
You
know
locally
on
your
proposed
changes
after
you
push
your
commits
to
a
feature
branch
in
the
remote
repository
and
gitlab.
The
cicd
pipeline
set
for
your
project
is
triggered,
which
then
runs
automated
scripts
and
those
can
be
sequentially
or
in
parallel,
and
that
allows
you
to
build
and
test
your
app
preview.
B
The
changes
per
the
merge
requests
with
review
apps.
You
know,
as
I
mentioned
earlier,
as
you
would
know-
and
this
is
what
you
would
normally
see-
on
the
Local
Host
after
you're
happy
with
your
implementation
and
get
that
reviewed
you,
then
you
know
again
just
get
that
merged
into
the
default
branch
and
gitlab
cicd
deploys
your
changes
automatically
to
the
production
environment
and,
finally,
you
and
your
team
can
easily
roll
it
back
if
anything
goes
wrong.
B
So,
if
you
see
here
on
this
slide,
gitlab
CI
CD
is
capable
of
doing
a
lot
more,
but
this
particular
workflow.
You
know
kind
of
exemplifies,
gitlab's
ability
to
track.
You
know
the
entire
process
without
the
need
for
any
kind
of
external
tools
to
deliver
your
software,
so
Mo
and
and
what's
most
useful,
is
that
you
can
actually
visualize
all
those
steps
through
the
gitlab
UI.
B
So,
just
to
kind
of
have
more
of
an
overview.
Gitlab
encompasses,
you
know
the
entire
software
development
life
cycle.
You
know
it
adds
automated
testing
building
and
deployment,
and
it's
fully
integrated
into
gitlab.
It
runs
in
multiple
stages,
has
manual
deploys
environments
and
variables,
it's
also
very
scalable,
you
know
it
can
tests
can
be
run
on
distributed
or
on
separate
machines.
It
can
add,
as
many
as
you
like,
jobs
can
run
in
parallel.
They
run
in
parallel.
Actually,
the
jobs
are
running
parallel
and
testing
results.
B
So
now
that
we
know
kind
of
what
a
full
workflow
is,
let's
look
at
you
know
the
CI
CD
pipeline,
specifically
so
when
the
pipeline
is,
is
triggered.
That's
what
a
commit
is
made
directly
to
the
server.
When
you
push
from
your
local
machine
to
the
server
local
commits,
you
know
local
commits
do
not
you
know
trigger
CI,
CD
pipelines
or
CI
pipelines.
B
This
is
only
when
it's
pushed
to
the
server
or,
if
you
push
it
from
the
local
server,
you
know
into
the
into
the
gitlab
server,
build
the
build
test
phase
and
that's
where
unit
tests,
integration,
tests,
SAS
and
Das
scanning
live
and
and
with
the
review
stage,
the
review
and
staging
section.
You
know
we
at
this
point.
You
know
your
code
would
go
through
code
review
and
approval
process.
B
Once
the
change
is
approved,
it's
merged
into
the
default.
Branch
then
push
to
the
environment.
You
want,
and
that's
typically,
you
know
the
staging
or
the
production,
the
gitlab
pipeline.
It's
it's
a
fundamental
building
block
for
continuous
integration.
You
know
delivery
and
deployment,
and-
and
with
this,
as
you
see
here,
the
pipeline
will
be
created
when
a
new
push
is
made.
B
So
when
the
push
is
made
the
pipeline,
you
know
it's
immediately
run
when
there's
a
git
lab
Runner,
that's
idle
or
it's
put
into
a
queue
if
all
available
Runners
are
being
used
by
someone
else
or
a
different
process.
B
Continuous
integration
is
built
in
and
works
to
integrate
your
code,
and
you
know
by
the
team
by
you,
know
the
code,
that's
provided
by
the
team
in
the
shared
repository
and
developers,
you
know,
share
the
code
and
the
merge
requests
and
the
request
triggers
the
pipeline
building,
testing
and
validation
process,
the
the
new
code
with
the
for
the
new
code
price
and
merging
the
changes
you
know
within
your
Repository
with
continuous
delivery
CD.
B
We
ensure
that
the
delivery
of
CI
validated
code
to
your
application,
via
structured
deployment
pipelines
together,
CI
and
CD
help
your
team
deliver
faster
results.
So,
with
with
these
automated
processes
in
place,
you
know
it
allows
your
team
to
have
all
all
those
different.
You
know
automated
processes
built
into
their
workflow
and
CI
and
CD.
You
know
they
must
work
together.
B
You
know
to
kind
of
help
your
team
build
effectively
and
are
you
know,
they're
critical
for
the
software
development
cycle
and
automatically
you
know,
CI
CD
will
build
your
application
run
unit
and
integration
test
provide,
live
previews
and
with
the
review
apps
and
it
can
deploy
to
multiple
environments,
like
you
know,
staging
in
a
production,
environment
and
also
you
know,
it
also
supports
Advanced
features
like
canary
deployments,
foreign
and
here
on
the
next
slide.
We're
going
to
be
talking
about
the
main
concepts
of
Pipelines.
B
So
pipeline
is
a
comprised
of
jobs
and
stages,
jobs
Define.
What
we
want
to
accomplish
in
our
pipeline,
for
example,
if
job
the
jobs
that
compile
a
test
code-
that's
something
that
you
know
we
want
to.
You
know
trigger
within
the
pipeline.
Those
would
be
considered
the
jobs
and
they're
executed
by
Runners.
Multiple
jobs
in
the
same
stage
are
executed
in
parallel.
B
If
there
are
enough
concurrent
Runners
stages,
on
the
other
hand,
those
those
Define
what
and
how
to
run
jobs,
for
example,
stages
that
run
tests
after
stages
that
compile
the
code.
You
know
that's
something
that
you
would
set
up.
You
know
with
them
using
a
stage,
so
it's
it.
It
again
defines
how
and
when
to
run
specific
jobs.
If
all
jobs
in
the
states
succeed,
the
pipeline
moves
on
to
the
next
stage,
so
the
stages
actually
are
kind
of
the
the
way
you
move
the
pipeline
forward.
B
If
any
job
in
the
stage
fails,
the
next
stage
is
usually
not
executed,
and
the
pipeline
ends
early
depending
on
how
you,
how
you,
you
know,
configure
that
particular
pipeline
by
default,
a
pipeline
will
have
three
stages.
It's
the
build
test
and
deploy
that
are
usually
the
the
defaults.
B
Let
me
see
so
down
here
at
the
bottom.
You'll
actually
see
that
you
know
it's.
A
typical
pipeline
might
consist
of
maybe
four
stages,
something
like
you
know
a
build
stage
which,
with
a
job,
that's
called,
build
or
compile,
and
then
you
have
the
test
stage
and
that
you
know
it
has
jobs
that
are
like.
You
know
the
test
coverage
test
integration
test
unit.
B
You
have
the
staging
stage
with
the
with
the
job
called
staging
and
the
canary
stage
with
the
job
called
Canary,
and
then
you
have
the
you
know
the
production
stage
at
the
end
with
you
know,
with
that
job,
that's
particular
you
know
it's
named
production.
This
is
kind
of
like
an
example
of
how,
like
a
a
CI
pipeline,
may
look
in
the
UI.
B
So
there's
different
ways
that
you
know
there
are
different
conditions
in
which,
like
we
can
trigger
gitlab
pipelines.
One
of
those
can
be
pushing
your
code
to
the
repository
running
it
manually
in
the
UI,
and
then
you
can
be
scheduling
it
to
run
later.
You
can
schedule
your
trigger
and
it
could
be
triggered
by
an
upstream
Pipeline
and
you
can
use
the
API
to
launch
the
pipeline
with
trigger.
B
B
This
is
the
gitlab
CI
yaml
file,
so
this
yamla
file
provides
instructions
to
the
pipeline.
It's
going
to
be
the
bread
and
butter
of
configuring,
those
pipelines
they're
located
in
the
root
directory
of
the
project,
Repository,
and
so
here's
a
you
know
very
basic
example
of
a
ciml
file
which
it's
again
it's
written
in
yaml,
syntax
and
I'm,
storing
the
root,
but
it's
also
Version
Control,
with
along
with
the
rest
of
the
code
in
the
gitlab
CI
file.
B
You
can
Define
the
scripts
that
you
want
to
run
other
configuration
files
and
templates
you
want
to
include
you
can
do
dependencies
and
caches
the
commands.
You
want
to
run
in
secrets
and
those
that
you
want
to
run
in
parallel
can
be
included
here
as
well,
the
location
of
it.
You
know
if
you
look
here
at
the
location
where
you
want
to
actually
deploy
those
applications
to.
B
You
can
actually
specify
those
in
these
ciml
files
as
well,
and
you
can
also
you
know,
determine
whether
or
not
you
want
to
run
the
scripts
automatically
or
trigger
them
manually.
B
And
so,
if
you
look
at
this
file
here,
you
know
it's
here's
just
a
few
sections
to
specify
the
jobs
and
stages
of
the
pipeline,
and
so
the
top
section
there
defines
the
stages
for
the
pipeline
themselves,
and
you
see
there.
The
stages
as
build
and
deploy
in
the
middle
section
represents
the
build
job.
B
You
can
see
that
the
stage
there
it's
it's
defined
as
building
it's
also
followed
by
a
script
for
the
job
and
and
an
only
statement
there
as
well
in
that
bottom,
section
you'll
see,
represents
the
deploy
job
and
it's
specified
as
deployed
and
there's
also
an
environment
variable
listed
there
and
and
also
an
only
statement,
there's
many
other
different
types
of
sections
and
and
types
that
you
can
include
inside
of
a
yaml
file.
B
B
So
gilab
pipeline
configuration,
you
know,
is
several
different
references,
so
we
have,
let
me
see
you
can
locate
keywords
again
in
the
on
the
docs
file
of
our
website,
the
docs
keyword,
the
actual
keywords,
are
available
there
in
detail
and
description
for
each
one,
and
that
provides
you
know,
configuration
options
and
and
just
a
different
keywords
that
are
available
for
each
of
those
job.
Behaviors.
B
And
then
so,
here's
stages
separate
jobs
in
The
Logical
sections.
While
jobs
perform
the
actual
tasks
by
default,
there
are
four
stages
we
have
build,
tests
review
and
deploy,
and
all
jobs
run
in
parallel
stages
are
used
to
separate
jobs
in
The,
Logical
sections
stages
to
find
per
job
and
relies
on
stages
which
is
defined
globally
use.
B
You
can
use
a
stage
to
Define
which
job
which
stage
a
job
runs
and
and
the
jobs
of
the
same
stage
are
executed
in
parallel,
and
that's
you
know,
subject
to
whatever
specific
conditions
that
you
may
include
there
stages.
So
here
we
see
stages,
they
separate
jobs
in
logical
sections,
while
jobs
perform
those
actual
tasks,
a
pipeline
configuration
here
begins
with
job
in
our
most
fun.
It's
the
most
fundamental
element
of
the
CI
ammo
file,
the
yaml
file
triggers
scripts,
which
do
the
work
to
create
your
first
pipeline.
B
You
can
start
with
whatever
build
tests
or
deploy
commands
you
you
currently
use.
This
figure
shows
this
figure
here
shows
how
you
can
execute
scripts
in
a
pipeline
in
multiple
multiple
ways
and
a
pipeline
configuration
begins
with
jobs,
they're
defined
with
constraints.
So
if
you
see
here,
they're
they're
defined
using
those
different
constraints,
top
level
elements
or
have
all
you
know
arbitrary
names,
they're
up
there
at
the
top
and
they're
not
limited
to
how
many
can
be
defined.
B
If
you
see
there
the
script
keywords,
it's
the
only
required
keyword
that
the
job
needs
and
it's
a
shell
script.
That's
it!
It's
actually
executed
by
the
runner.
B
Here's
a
very
basic
example
of
gitlab
CI
ammo
file,
which
is
written
in
yaml,
syntax
and
stored
in
the
root
of
the
project
and
Version
Control,
like
I,
said
with
the
rest
of
the
code.
This
this
file
just
has
a
few
sections
to
specify
jobs
and
stages
of
the
pipeline.
B
Let's
take
a
look
at
each
one
here,
so
here
you
can
see
that
they're
specified
as
test
and
deploy,
and
you
also
see
you
also
notice
that
each
stage
contains
a
script
as
well
and
there's
many
other
sections
and
types
of
content
you
can
include
inside
of
the
yaml
files
and
and
again
for
this
course
we're
just
kind
of
covering
just
the
basic
basic
level,
but
again
our
full
day.
Ci
CD
course
does
go
into
more
detail
and
then
there's
a
very
large
library
of
documentation
available
on
on
using.
B
Using
images
to
run
jobs
in
a
pipeline,
are
you
know,
that's
something
that's
going
to
be
very
integral
integral
in
your
implementation.
B
You
can
run
to
cicd
jobs
anywhere,
but,
however,
you
want
you
want
an
easily
repeatable
and
reliable
environment
for
your
build,
and
so
the
easiest
way
to
achieve
this
is
with
containers.
An
image
is
used
to
specify
a
Docker
image
that
you
know
be
used
for
the
job
again
for
for
detailed
usage
around
Docker.
Definitely
take
a
look
at
the
docker
integration
documentation.
B
The
image
keyword
can
be
used
in
a
global
scope
or
inside
your
job
definition
as
a
local
image
or
in
local
scope.
So
here
in
this,
in
this
slide,
you
see
we're
using
Ruby.
So
it's
the
image
followed
by
the
actual
the
name
of
the
image,
and
you
see
there
again.
This
is
deployed
from
it's
pulled
from
Docker
Hub
by
default,
and
so
also
keep
in
mind
that
the
image
tag
will
be
used
globally
for
every
job
unless
a
job
has
its
own
specific
image
tag.
B
Services
keyword
allows
us
to
augment
our
base
image
with
additional
functionality
here,
we're
calling
the
postgres
layer
to
add
a
database
service
to
our
base
image
Services
can
be
used
in
both
Global
and
local
as
well.
You
know,
for
you
know,
as
the
actual
image
keyword
and
variables
are
Global
and
local
and
allow
us
to
Define
yaml
variables
that
have
an
order
in
the
variable
ion
the
variable
hierarchy.
Additional
images
may
be
needed
so
Services.
You
know
the
services
keyword
actually
pulls
additional
images
from
Docker
Hub,
but
can
also
be
pulled
from
the
container
registry.
B
It
then
ties
together
with
the
base
image,
to
form
a
single
container,
and,
and
so
that's
something
that
you
know
it's
pretty
pretty
good
to
keep
in
mind
for
kind
of
tying
together
different
projects,
and
this
is
an
example
here.
If
you
want
to
see
settings,
CI,
CD
and
variables,
you'll
be
able
to
actually
Define
and
see
those
there.
Each
project
can
define
a
maximum
of
200
variables
as
of
as
of
now
but
just
be
sure,
to
put
variables
after
the
images
and
services
section.
B
B
Here's
another
example
here
where
we
actually
see
the
the
image
or
using
a
kubernetes.
You
know
with
the
sorry
we're
using
kubernetes
with
the
latest
container
and
the
services
you'll
see
is
postgres
and
we
have
three
setups
for
the
stages
as
your
CD
build
test
and
deploy,
and
then
we
have
deploy
code
and
so
deploy
code
that
deploys
the
code
as
part
of
the
deploy
stage
and,
as
you
can
see,
we're
well
all
the
set.
All
the
configurations
are
all
in
one
file.
B
B
So
here
you'll
see
that
the
environment
keyword
it
defines
it
defines
where
the
app
is
deployed
and-
and
it's
defined
by
those
three
parts
here.
So
we
have
the
the
name
of
it,
which
is
production.
B
It's
called
it's
called
production,
this
particular
environment,
and
it
creates
a
section
for
this
stage
here
by
using
the
the
when
we
can
Define
when
it's
run,
and
here
in
this
case
it's
actually
actually
manual,
but
there's
also
status
like
on
success,
on
failure
in
all
ways,
so
on
success
executes
only
when
all
jobs
prior
to
that
stage
succeed-
and
this
is
the
default
on
failure
executes
only
when
at
least
one
job
from
the
prior
stage
fails
and
then
also
always
executes
the
jobs,
regardless
of
the
status
of
the
jobs
from
prior
stages.
B
B
We
released
an
improved
rules,
syntax
that's
more
powerful
than
only
an
except,
but
in
in
this
case
you
know
we'll
see
here.
That
only
is
the
the
name
of
the
branch
that
we're
executing
on.
In
this
case,
it's
all
branches
and
except
is
then
set
to
main.
You
know
again
to
just
kind
of
prevent
changes
to
Maine
with
this
particular
deployment.
B
So
rules
is
the
rules
is,
is
actually
it
replaces
only
an
except
and
but
cannot
be
used
in
conjunction
with
it.
So
it's
it's
it's
if
you
attempt
to
use
both
you'll
get
an
error,
but
to
go
over.
What
rules
is
it's
basically
only
an
except
so
rules
does
many
of
the
things
that
only
accept
does,
but
it's
just
more
granular,
so
we
have
only
accepted
only
in
except
a
great
for
simple
job
rules.
B
However,
you
may
encounter
complex
situations,
so
in
this
case
rules
is
the
you
know
the
option,
as
you
can
see
the
rules
section
of
the
example
where
we're
showing
the
same
rules
the
slide
before,
but
this
time
with
the
rules,
instead
of
only
accept
so
rules
are
evaluated
in
order
until
the
first
match.
So
if
you
see
here
when
matched
you
know,
the
job
is
either
included
or
excluded
from
the
pipeline,
depending
on
the
configuration,
if
included,
the
jobs,
also
has
certain
attributes
that
are
added
to
it.
B
We
cover
more
of
this
in
the
advanced
workshops.
It's
just
kind
of
give
you
a
quick
overview
of
the
different.
The
different
Concepts
and
features
here
available
rules
are
evaluated
in
order
into
the
first
match
once
they're
matched
the
job
is
either
included
or
excluded
from
the
pipeline,
and
so
just
just
to
give
you
an
example.
There.
B
So
the
before
script
and
the
after
script,
the
before
script
and
after
script,
those
are
kind
of
used
for
it
they're
going
to
use
more
for
housekeeping.
So
the
before
script
runs
in
the
environment.
You
know
the
build
environment
sets
up
after
the
script
rooms
the
building
environment
cleans
up,
so
you
can
do
like
a
cleanup
and
a
build
a
setup.
This
is
only
necessary
in
situations
where
you're,
not
using
containerization
number
before
script.
B
Keywords
used
to
define
an
array
of
commands
that
should
be
run
before
each
job,
but
after
artifacts
are
restored.
Scripts
specified
in
before
scripts
are
concatenated
with
any
scripts
specified
in
the
main
script
and
they're
executed
together
in
a
single
shell,
it's
possible
to
override
it
globally
defined
before
script.
If
you
define
it
in
a
job,
the
after
script.
Keyword
here
is
used
to
define
any
array
of
commands
that
run
after
each
job,
including
failed
jobs
if
a
job
times
out
or
is
canceled.
B
The
after
script
commands
are
not
executed,
scripts
specified
in
the
app
script
or
are
executed
in
a
new
shell,
separate
from
any
from
from
any
before
script
or
script.
Scripts.
B
Foreign
going
over
cash
and
artifacts
cash
is
used
to
pass
information
between
jobs
and
stages
by
storing
project
dependencies,
so
gitlab
Cici
provide
cicd,
provides
a
caching
mechanism
that
can
be
used
to
save
time
when
your
jobs
are
running.
Caching
is
about
speeding
the
time
a
job
is
executed
by
reusing
the
same
content
of
the
previous
job.
If
caching
is
enabled
it's
shared
between
pipelines
and
jobs
at
the
project
level
by
default.
B
So
just
to
you
know,
to
get
more
detail
into
that.
Like
cash,
for
example,
is
for
storing
project
dependencies
cash
can
increase
the
speed
of
a
given
job
in
subsequent
pipelines,
and
you
can
you
can
store
download
independently
dependencies,
so
they
don't
need
to
be
fetched
from
the
internet
again.
Dependencies
include
things
like
npm
packages,
Ben
go
vendor
packages
and
so
on.
You
can
configure
a
cast
to
pass
intermediate,
build
results
between
stages,
but
you
should
use
artifacts
for
that
particular
use
case.
B
Instead,
though,
so
with
artifacts,
you
use
those
use
for
stage
results
that
are
passed
between
stages,
artifacts,
that
are
files
that
are
generated
by
a
job,
so
they
can
be
stored
and
uploaded.
B
You
can
fetch
and
use
artifacts
and
jobs
in
later
stages
of
the
same
pipeline.
You
can't
create
an
artifact
and
job
in
one
stage
and
use
this
artifact
in
a
different
job
on
the
same
stage,
but
this
data
is
not
available
in
different
pipelines,
but
can
be
downloaded.
You
know
from
the
UI.
B
So
here
we'll
see
that
the
the
actual
cash
is
added
here
with
the
path
and
then
under
in
the
actual,
build
it.
Seizure
will
see
the
the
artifacts
on
success
and
it
shows
the
path
as
well.
B
In
gitlab,
we
use
tags
to
select
a
specific
Runner
from
the
list
of
all
the
runners
that
are
available
for
your
project.
When
you
register
a
runner,
you
specify
the
runner's
tags,
for
example,
Ruby
postgres
deployment
and
gitlab
CI
tags
are
not
the
same
as
gig
tags,
so
the
CI
tags
are
associated
with
Runners,
while
the
git
tags
are
associated
with
marketing
specific
commits.
B
In
the
example,
we
only
execute
the
job,
our
Runners
that
have
Ruby
and
test
tags.
B
So
gitlab
CI
yaml
files
are
instructions
for
your
jobs,
the
gitlab
runners,
the
agent
that
actually
runs
those
jobs
to
use
the
git
last
CI
CD
you
or
your
gitlab
admin.
You
have
to
first
Define
a
pipeline
within
the
yaml,
which
is
the
gitlab,
the
dot,
gitlab
ciml
and
then
install
and
configure
the
runner.
The
yaml
file
is
the
pipeline
definition
file,
so
think
of
it.
Think
of
the
yaml
as
the
brains
and
the
runner
as
the
body.
B
The
gitlab
runner
is
an
application
agent
and
it's
written
in
go
and
it'll
run
the
jobs
specifying
the
yaml
using
an
API
to
communicate
with
gitlab.
The
gilab
admin
can
configure
shared
Runners
to
run
on
multiple
projects,
and
you
can
set
up
your
own
project
as
well
in-depth
configuration
it's
actually
covered
in
the
in
the
Hands-On
gitlab
CI
CD
course.
B
So
the
runner
architecture,
so
gitlab
Runners,
can
be
installed
on
any
platform
where
you
build
go
libraries,
including
Linux,
Mac,
OS
Windows,
you
know
FreeBSD
bare
metal,
you
can
even
put
it
on
your
personal,
laptop
workstation
and
Docker.
Get
lab
Runner
can
test
any
programming,
language,
including.net,
Java,
python,
C,
PHP
and
others.
Typically,
these
are
created
by
your
admin
and
made
visible
in
the
gitlab
UI
for
certain
tasks
and
jobs
in
a
good
lab.
B
B
Specific
Runners
are
you
know
for
when
you
have
different
teams
sharing
an
instance,
but
they
need
to
have
their
own
runners
in
their
own
network.
For
example,
if
you
have
multiple
customers
in
an
instance,
shared
Runners
can
be
used
for
any
project
in
the
instance.
Typically,
this
is
used
in
the
case
where
everybody
in
the
instance
is
part
of
the
same
organization.
Shared
runs
are
available
to
every
project
project.
B
In
the
gitlab
instance
and
they're
also,
the
cube
there's
a
cue
that
prevents
projects
from
creating
hundreds
of
jobs
and
using
all
available
shared
Runner
resources,
and
so
there's
a
usage
out
of
Q
algorithm
Rhythm
assigned
specific
Runners
are
used
when
you
want
to
use
Runners
for
specific
jobs.
So
you
can
set
up
specific
rooms,
be
used
with
multiple
projects.
B
It
must
be
enabled
for
each
project
explicitly.
B
So
sometimes
you
know
tags.
You
know
you
work
with
tags.
You
know
they
ensure
that
each
job
is
done
is
using
the
correct,
Runner,
so
tags.
Allow
you
to
select
a
runner
from
a
pooling
algorithm
tag.
Runner
will
only
be
selected
to
run
jobs
with
specific
tags,
so
here
you'll
see
that
you
can
actually
specify
which
tags
we
see
the
windows
tag
there.
So
gitlab
CI
tags,
you
know
again,
they're
not
the
same
as
git
tags
and
they're
just
associated
with
the
runners,
foreign
Ted.
B
When
you,
we
have
to
be
careful
with
some
sensitive
information
and
prevent
Runners
from
revealing
sensitive.
You
know
information,
so
you
can
protect
Runners
that
so
that
they
won't
reveal
that
information
when
a
runner
is
protected.
The
runner
picks
jobs
created
on
the
protective
branches
and
protected
tags
only
and
ignores
all
other
jobs,
so
gilab
recommends
protecting
the
runner
if
it
contains
deploy,
keys
or
other
sensitive
capabilities,
and
so
you
know
that's
that's
a
pretty
straightforward
process
to
set
up
there
and
I
just
want
to
make
you
aware.
B
So
this
slide
here
represents
a
newly
created
Runner.
There
are
additional
Runner
configuration
options
in
the
runner
section,
and
so
this
is
just
kind
of
to
give
you
an
idea
of
what
what
it
would
kind
of
look
like
to
set
one
up
here.
This
one
it
doesn't
accept.
Let
me
let
me
pull
it
and
see
so
you
can.
Actually
this
one
right
here
is
allows
you
to
run
untagged
jobs,
and
you
can
lock
into
the
current
project.
B
So
with
shell,
these
are
different
executors.
So
with
shell,
it
allows
you
to
directly
run
commands
as
if
writing
them
in
the
terminal
itself
or
the
command
prompt,
and
then
the
docker
machine
scales
up
Runners,
with
any
executor
on
demand.
Typically
in
Cloud
deployments,
kubernetes
runs
as
a
pod
and
a
kubernetes
cluster
and
can
also
feature
Auto
scaling,
and
then
the
doctor
executes
inside
of
a
Docker
image,
which
is
the
most
common
way
to
run.
B
And
this
slide
here
it
kind
of
represents
a
less
common
executive
list.
So
there's
actually
a
list
more
extensive
lists
on
the
documentation.
But
here
you'll
see
there's
virtual
box,
which
is
the
base
VM
for
Runner.
Parallels
can
be
used
as
well
as
SSH,
which
is
similar
to
Shell,
but
not
as
many
features
bash
only
and
no
caching.
B
So
it
does
allow
you
to
run
and
execute
on
the
machines
you
might
want.
You
might
not
want
to
install
a
runner
on.
B
All
right
and
I'm
gonna,
we
pass
it
on
to
Taylor
for
Q
a
and
we'll
go
from
there.
A
Awesome,
thank
you.
Rasheed
yeah
I
just
opened
up
a
feedback
poll
we'd
love
to
get
your
feedback
on
today's
session.
Just
a
couple
of
of
quick
questions.
There
should
only
take
a
minute
and
as
we're
doing,
that,
I
will
start
jumping
into
some
of
the
questions
that
came
through
and
pose
those
to
you
Rasheed
first,
one
that
came
up
in
the
case
of
an
environment
that
doesn't
use
Docker
and
just
uses
standard
VMS.
B
Okay,
that
that
sounds
like
you
would
need
to
use
the
expect
rule
keyword
so
the
within
the
documentation.
There
is
a
lot
of
a
lot
of
the
references
to
the
different
keywords.
Let
me
see
foreign.
B
How
it
works
here,
it
would
actually
be
the
the
expect
statement.
So
I'll
I'll
be
providing
that
as
well
with
the
with
the
in
the
Q
a
chat.
A
Right
next,
one
that
came
up,
can
you
please
share
the
presentation?
Slides
I
can
take
that
one.
Yes,
those
will
be
sent
out
with
the
recording,
via
email,
with
the
email
that
you
used
to
register
in
the
next
day
or
two
next
one
here.
Can
you
give
reference
or
templates
of
gitlab
ci.yaml
to
cover
all
these
CI
pipeline
steps
for.
B
Sure,
there's
actually
a
resource
called
guided
Explorations,
and
this
is
something
that's
actually
a
repo
that's
available,
and
here
it
just
has
a
lot
of
the
scaffolding
projects
here,
they're
available
in
different
types
of
ciml.
B
You
know
configurations
and
there's
also
the
gitlab,
the
gitlab
CI
examples,
as
well
as
the
auto
devops
documentation
as
well
yeah.
Let
me
kind
of
pull
that
up.
Just
to
you
know
make
you
aware
of
the
different
resources
that
you
have
available
to
you
so
here
with
gitlab
examples.
You'll
also
see
a
lot
of
different
projects
here
that
contain
ciml
files
that
you
can
use
to.
Then
you
know
kind
of
accelerate
your.
You
know
your
your
adoption
of
different
features
of
gitlab
foreign.
A
Just
a
couple
more
here
does
pipeline
support
deployment
to
physical
destinations
like
servers
directly
without
kk8
stalker.
B
Yes,
yes,
you
can
deploy
gitlab,
you
know
you
can
use
gitlab
to
deploy
to
any
type
of
infrastructure
and
we
definitely
have
a
lot
more
information
available
on
our
on
the
documentation.
But
that
is
something
that
you
have
available
to.
You
is
the
you
know
the
the
the
the
way
that
you
know
the
actual
motability
of
git
lab
and
being
able
to
deploy
anywhere.
You
want
that's
something
that's
available,
that's
built
in,
for
you.
A
Great
last
one
that
I'm
seeing
here
is
the
is
the
location
of
the
saved
artifacts
located
on
the
docker
image
used
for
the
build
or
somewhere
else.
B
B
So,
underneath
artifacts,
it
actually
is
a
section
here
for
where
the
caches
are
stored
and
it'll.
Give
you
more
information
on
on
how
to
you
know
kind
of
see
where
each
particular
situation
you
know
leads
you
as
well
as,
like
you
know,
all
the
different
types
of
things
associated
with
caching
and
job
artifacts,
as
well
as
pipeline
artifacts.
So
that's
going
to
be
all
within
the
documentation
as
well.
A
Awesome
I
think
we
got
through
all
of
them.
Thank
you,
Rasheed
and
thanks
again
everyone
for
joining
us
today.
We
we
were
grateful
to
be
with
you
for
an
hour
or
so
here
and,
like
I
said
we
will
be
sharing
out
this
presentation
and
the
deck
here
in
the
next
couple
of
days
with
that
have
a
good
rest.
Your
day,
everybody.