►
From YouTube: Intro to GitLab Webinar
Description
Are you new to GitLab? Watch the webinar to learn more about what GitLab is, how it benefits you, and the recommended workflow to allow you to get the most out of the platform.
A
Hi
everyone
we
are
going
to
be
starting
in
a
moment
which
is
going
to
give
everybody
one
minute
or
so,
to
join
Sutherland
and
we're
going
to
start
with
us.
A
Perfect
I
think
we're
good
to
go.
It's
one
minute
past
the
hour,
so
I
think
we're
good
to
get
started.
So
my
name
is
graphic
shoppingkov,
I'm,
strategic
customer
success
manager
here
at
gitlab
and
a
couple
of
housekeeping
notes
here.
There's
a
q,
a
section
that
you
can
use
throughout
this.
A
The
good
Arc
so
feel
free
to
ask
any
questions
and
we're
going
to
be
writing
a
couple
polls
at
the
end
to
see
if
this
session
was
useful,
I've
got
Vlad
from
social
architect
team
who
will
be
helping
out
throughout
the
session,
so
he'll
be
in
charge
of
answering
all
your
questions,
so
yeah
feel
free
to
ask
as
many
as
you
can.
We
also
have
Michael
joining
so
he's
our
manager
of
Enterprise
team.
A
So
here's
a
yeah
here's
two
cents
about
the
housekeeping
notes
in
terms
of
how
we're
going
to
do
the
webinar.
So
we're
going
to
go
through
the
foundational
Concepts
and
the
usage
of
gitlab,
how
things
are
organized
terminology,
navigating
the
UI
and
the
fundamentals
for
tracking
work,
we're
also
going
to
cover
command
the
gitlab
4
for
a
feature:
Branch
development,
workflow
and
also
I'm,
going
to
give
you
a
bit
of
a
developed
history
for
you
to
understand
how
it
has
developed
over
the
years
and
how
gitlab
came
to
the
tool.
A
Around
their
projects
and
yeah
accomplish
what
they're
set
to
do
so
also,
we
usually
have
more
webinars
that
we
are
presenting
in
the
future
and
they
usually
include
introduction
to
cicd
Advanced,
cncd,
defsecops
and
compliance.
So
at
the
end,
I
will
share
link
for
you
to
kind
of
stay
up
to
date
on
our
schedule
and
if
you
want
to
join
more
of
those
you'll
be
free
to
do
so.
So
I
think
we
are
good
to
get
started.
A
A
So
what
you
see
here
is
a
typical
do-it-yourself,
the
whops,
I
suppose
stage
and
all
organizations
how
this
kind
of
kind
of
set
up
where
they
are
seeing
inherent
kind
of
problems
that
come
with
us
right.
So
each
particular
stage.
Source
core
management
builds
staging
and
production.
They
represent
I,
suppose
again
different
stages
in
how
teams
Collide
collaborate
with
each
other,
and
that
brings
a
number
of
problems.
Delay
is
an
errors.
A
Multiple
handoffs
complexity
risks
lack
of
control
at
the
compound
matters
worse,
it
could
be
absolute
nightmare
for
managing
upgrades
and
all
these
separate
tools
and
Technology
Stacks.
So
each
has
their
own
patching
mechanism.
They
have
separate
databases
and
passwords,
and
if
you
fall
behind
an
upgrades,
you
know
we
realizing
the
full
value
and
they
can
also
pull
the
security
risk.
So
keep
that
in
mind
when
we
go
through
the
four
phases
of
devops
as
to
and
yeah
how
gitlab
solves
our
problem.
A
So
now
we
have
four
stages
here
and
at
the
end,
we
have
the
four
station
Deluxe
platform,
which
is
kind
of
gitlab.
So
phase
one
is
salad
devops.
So
in
this
phase
each
department
or
team
they
built
or
purchase
their
own
tools
in
isolation
from
the
other
teams
which
they
optimized
for
their
own
narrow
objectives,
so
without
explicitly
coordinating
with
others.
So
this
leads
to
sell
devops
environments
that
causes
problems
when
teams
try
to
work
with
each
other
they're,
not
really
sure
what
other
teams
are
using.
A
So
there's
a
very
little
collaboration.
So
it's
very
common
for
organizations
at
this
level
of
maturity
to
have
multiple
duplicate
effects
of
tooling
source
card
management.
Cicd
and
this
chaotic
environment
slows
down
collaboration
and
knowledge
or
stops
it
all
together
completely.
So
now
companies
realize
hey,
they
need
for
Less
chaos.
The
more
Harmony
draw
organizations
to
the
second
phase
of
fragmented,
the
Best
in
Class
The
Works,
not
another
name
for
that
standardized
to
chain.
So
it's
slightly
better
where
companies
relies
right,
they
standardize
on
the
same
tool
chain
across
organizations.
A
Typically,
there
was
one
preferred
to
for
each
stage
which
there's
many
teams
within
same
function
called
collaborate
better,
but
tools,
weren't
connected
between
stages
right,
those
are
still
separate
tools,
one
Asana
Jenkins.
What
have
you
they're
all
different?
They're?
Not
don't,
have
Integrations
built
in
by
default,
so
that
leads
to
our
third
stage,
and
this
is
do-it-yourself
devops
again
accusations.
A
They
try
to
remedy
this
by
mileage,
integrating
the
Rocks,
Point
Solutions
and
you
know,
building
and
maintaining
Integrations,
but
that
again,
what
happens
if
that
person
needs
that
build
the
integration
or
they're
off
it's
it's
a
lot
of
efforts
and
it's
a
complex
workflows,
that's
slow
down
development
process
and
overall
cycle
time,
so
that
really
didn't
address
overall
problem.
So
now,
why
am
I
telling
you
on
this?
A
Because
gitlab
is
a
one
devops
platform
and
the
true
potential
of
the
boss
can
be
realized
with
it
and
is
being
so
so
it's
a
single
application
with
one
user
interface,
a
unified
data
store.
It
includes
every
stage
on
devops
lifecycle
and
brings
together
development
operation
in
screenings.
In
one
platform,
it
allows
all
these
groups
to
collaborate.
The
plan
build
secure
and
deploy
software.
So,
as
a
result,
this
improves
business,
velocity
efficiency
security
and
allowing
you
to
deliver
softly
faster
now
in
terms
of
how
this
is
done.
A
So
what
makes
a
develop
spark
from
a
platform.
So
what
you're,
seeing
here
on
this,
that
infographic
is
at
the
top
you
having
all
those
personas
that
are
using,
let's
say,
gitlab
right
developers.
A
They
are
compliance,
team
security
operations,
another
map
out
to
gitlab
platform,
and
then
then
they
lay
them
up
to
I,
suppose
those
stages
and
below
that
you're
seeing
different
companies
that
represent,
for
example,
those
stages
as
well
so,
for
example,
create
will
be
done
by
GitHub
Jenkins
verify,
and
what
have
you
so
gitlab
offers
all
those
Solutions
within
one
Law
Firm
without
having
to
switch
to
another
application.
So
what
problems
does
that
solve
it's
emulating
manual
handouts.
Remember
the
picture
that
I've
shown
you
at
the
very
start
right.
A
It's
exactly
that
problem
the
results,
so
you
can
automatically
enforce
compliance
and
governance
across
entire
web
life
cycle
of
onboarding
team
members
is
much
faster
and
moving
between
Politics,
as
teams
are
needed
again.
They're
spending
your
time
on
resources,
building
customer
value
instead
of
Integrations
right
essentially
so,
and
the
entire
company
collaborates.
Any
single
source
of
tools
and
sort
of
Truth
is
what
we
call
and
the
entrance
ability.
So
everyone
can
see
what
the
other
teams
are
doing,
which
I
think
is
pretty
awesome
now
a
little
bit
more
about
how.
A
But
then
they
work
sequentially
one
after
the
other
right
and
probably
work
from
one
team
to
the
other
and
again
that
limits
organizations
from
truly
realizing
the
value
of
the
devops.
Where
teams
need
to
work
together
and
have
a
single
conversation
from
the
very
Inception
to
production
and
also
around
smaller
deliverables.
So,
in
a
traditional,
sequential
devops
approach,
each
phone
twin
is
running
in
silos
and
using
their
own
tools
and
again
they
may
be
a
little
bit
optimized
with
a
lot
of
hands-off
and
friction
so
yeah.
A
That's
what
we're
trying
to
solve
and
move
to
concurrent
devops
and
and
once
they
they
move
to
according
to
Ops
model.
This
approach
offers
way
to
get
teams
to
work
together
at
the
same
time
and
again,
collaborate
in
a
single
kind
of
pane
of
glass,
so
to
speak
so
a
little
bit
more
about
terminologies.
A
Now
that
we've
covered
a
bit
of
history
and
now
we
know
what
devops
has
gone
through
now,
let's
talk
about
I,
suppose
gitlab,
but
before
we
do,
there's
a
lot
of
terminology
that
I
wanted
to
cover
before
we
get
to
that.
So
you
don't
get
confused
because
some
of
the
things
are
no
industry
without
the
terms,
for
example,
will
be
a
project
right
project
is
a
core
building
block,
we're
working
organized,
and
it's
also
known
as
a
repository.
A
The
group,
for
example,
is
a
collection
of
projects
and
subgroups
in
the
lab,
folders,
essentially,
and
also
known
as
projects
out
there.
Issues
are,
if
they're
part
of
a
project
and
it's
the
fundamental
kind
of
a
planning
where
each
team
documents
use
cases,
description
approach
all
that
stuff
and
it's
also
known
as
story
or
narrative.
A
Epic,
are
just
a
collection
of
related
issues
across
by
theme.
Merge
requests
are
what
is
known
as
the
pull
requests.
It's
the
linkage
between
the
issue
and
the
actual
column
changes
I
give
up
late.
We
use
labels
to
talk
and
track
work,
board,
bordered
and
used
to
visually
list
those
projects
and
issues
so
for
better
kind
of
a
work.
Preparation
and
Milestones
are
just
deliberates
organized
by
I
suppose
in
a
kind
of
a
cohesive,
and
they
are
also
known
as
release
and
Sprints
and
last
one
is
roadmap.
I
think
that's
known
to
everybody.
A
It's
a
visual
representation
of
the
various
advics
for
the
groups.
So
let
me,
if
you're
not
familiar
with
that
it'd,
be
interesting,
maybe
to
take
a
picture
of
that
if
you've
never
seen
those
before
and
then
take
a
look
as
we
go
through
the
rest
of
the
presentation
now
so
gitlab
recommended
I,
suppose
workflow
right
so
I've.
Given
you
an
overview
of
git
live
in
history,
it's
time
to
kind
of
dig
right
into
our
recommender
workflow
across
all
stages
for
manage
all
the
way
to
covering.
A
So
we'll
start
from
South
Coast
management
plan
stage
where
we're
grouping
our
issues
by
by
common
theme,
then
we
have
a
milestone
and
usually
we've
decided.
We
would
like
to
finish
this
so
then
we're
creating
an
issue
and
as
we
we
go
down
we're
signing
this
issue
at
this
point,
we're
now
going
to
work
on
a
feature
Branch
at
the
top
and
the
work
will
happen
to
emerge
requests,
as
you
might
remember,
a
pull
request
as
well.
A
So
the
code
is
written,
the
work
is
done,
developer
pushes
the
code,
and
this
is
the
second
stage
where
automated
build
code
code
testing
is
done
scanning.
All
these
degree
scans
around
then
called
version
and
review
happens
after
and
is
they
I
suppose
any
code
problems
or
any
security
vulnerabilities
that
are
found?
Then
the
feedback
is
immediately
then
given
back
to
developer
in
the
view
and
emerging
files,
so
then
developer
again
fixes
the
code
addresses
vulnerabilities
and
then
it
goes
through
approval
and
also
there's
an
ability
to
have
a
UI
review.
A
App
is
a
is
an
ability
to
kind
of
launch
for
your
application
and
it
controls
formats
where
you
are
then
able
to
really
confirm
your
changes
so
be
very
useful
for
q18,
for
example,
once
you've
usually
checked
everything
the
grant
you've
approved
it,
it
then
is
merged
into
Main
and
released
and
deployed.
So
this
is
I
suppose
recommended
for
devops
seems
to
follow
this
flow,
but
not
necessarily
that
you
will
see
this
in
your
company
necessarily
that
you'll
be
using
this
day-to-day.
So
this
is
just
kind
of
best
practices.
A
A
What
we're
seeing
in
industry
is,
they
are
discounting
for
code
in
production,
rather
it's
already
too
late,
it's
already
too
costly.
It
is
it's
not
a
way.
It's
not
a
good
way
to
do
this.
It's
too
late,
so
shift
to
Mac
is
especially
important
for
developers
as
they're,
typically
again,
the
farthest
removed
from
the
customer,
and
there
was
an
interesting
article.
I
read
that
highlighted
impossibility
for
developers
to
learn
anything
once
somebody
helps
with
them
for
something
they
broke
six
months
ago
right.
A
So
that's
why
moving
security
and
testing
is
early
in
the
software
developer.
Life
cycle,
I
think,
is
really
important
and
we
all
should
be
getting
feedback
in
minutes
not
months
or
weeks.
So
I
don't
think
it's
even
for
me.
If
I
get
feedback
six
months
later
on
something
I
did
it's
not
very
productive.
So,
let's,
let's
move
feedback,
suppose
no
sense
as
early
as
possible.
It's
a
good
bye
to
anybody.
So
now
before
we,
we
show
the
couple
more
slides
before
we
show
you
gitlab,
I
suppose
and
how
it
works.
A
Just
wanted
to
talk
about
hierarchy
because
you're
going
to
be
seeing
a
lot
of
groups
and
projects
and
issues
and
I'm
going
to
be
confused
most
likely.
If
not
that's,
awesome,
so
guitar
projects
are
housed
within
groups.
That's
what
you're,
seeing
at
the
very
top,
then
from
that
you
have
kind
of
subgroups
and
other
players
down
the
projects
within
projects.
A
You
have
issues
right
so
how
all
works
like
permissions,
for
example,
I
inherited
down
from
the
top
level
groups,
so
you
would
add
users
with
Elite
permissions
and
give
them
higher
permissions
at
the
subgroup
or
kind
of
project
level,
and
we
use
labels
and
Milestones,
usually
at
the
top
level,
so
they're
available
to
all
subgroups
and
projects.
So
keep
in
mind
that
when
you're
going
to
be
switching,
let's
say
if
you're
playing
on
your
own
or
you're
using
it
loud,
not
all
functionalities
available
at
the
group
level
or
at
the
project
level.
A
So
I'm
going
to
highlight
that
as
well.
I
think
that's
the
last
slide
in
terms
of
the
workflow
I
know
there's
a
lot
of
talking
here,
but
hopefully
it's
helpful
in
case
you're.
Thinking
hey.
How
can
I
use
all
those
stages?
How
can
I
use
gitlab?
What
would
be
an
actual
example
of
work
and
that's
what
it
is?
There's
a
lot
of
text
here,
I'm
going
to
try
my
best
to
walk
you
through
this,
so
it'll
start
with
creating
And
discussing
a
new
issues.
So
if
you've
seen
the
workflow
before
that
are
shown.
A
Basically,
it
starts
like
that
a
team
member
create
an
issue
inside
get
lab
for
a
new
feature,
they'll
be
implementing.
So
the
team
member
applies
a
label
discussion
to
the
issue.
Then
various
team
members
are
going
to
discuss
it
by
entering
comments
into
you
should
write
as
collaboration
happens,
then
this
will
appear
on
the
Project's
issue
dashboard
and
the
discussion
list
I'm
going
to
show
you
the
how
we
use
boards
as
well.
Other
labels
in
the
project
could
include
backhand
rather
than
working
on
staging
ready
and
production.
A
Now
the
code
question
happens
in
emerge
requests.
The
back-end
team
starts
working
on
the
issue
and
then
changes
the
label
to
back
end
to
reflect
the
startups.
Everyone
knows
that
hey.
This
has
now
moved
to
backend
machine.
The
assign
developer
starts.
Writing
the
code
and
assigns
the
issue
to
themselves
and
changes
the
label
to
working
on
again.
Everybody
else
developers
start
at
work,
then
developer
Grace
commit
pushes
they
come
into
a
feature
Branch
then
the
back
end
team
removes
back
end
and
working
on
label
announced
the
front
line.
A
Basically,
the
loss
would
be
yeah
either
production
label
and
it
then
is
merged
into
production,
so
long
story
short.
This
is
a
camera,
for
example,
so
how
it
could
be
used
now.
So
we've
done
a
bit
of
a
history,
and
now
we
talked
about
the
best
practices.
So
what
does
this
look
like
in
gitlab?
Finally,
I
can
show
you
something
so
here
what
you
see
here
is
a
top
level
group
and
you
can
see
all
the
subgroups
and
projects
underneath
this
group.
A
So
now
this
comes
in
handy
that
you
know
what
a
group
is
that
within
groups,
you've
got
projects
within
projects,
you
have
issues
and
so
on
and
so
forth.
So
here
you
can
see
that
groups
have
three
dots
icon.
Where
projects
have
the
book
icon.
On
the
left
hand,
side,
you
can
see
all
the
errors
you
can
navigate
within
this
group.
A
So
if
you're
going
to,
let's
say,
go
to
a
project,
then
all
of
the
kind
of
settings
on
the
left
hand
side
will
also
change
so
now
hoop
epics.
So
if
you're
going
left
on
side,
you
go
to
the
epics
app.
You
click
on
the
lists
and
you
will
see
a
number
of
epics
that
were
already
created
here.
In
this
example
so
chose
a
reminder.
An
epic
again
is
a
collection
of
related
issues
across
different
groups
and
projects
to
help
you
organize
by
theme
right
and
that's
one
way
to
do
this.
A
Also,
you
can
search
for
epics
using
keywords
or
filtering
by
label
right.
So,
for
example,
confidential,
then
label
meant
priority
right
everything
you're
seeing
on
the
screen.
You
can
choose
any
anything
you
like
so
author
label
Milestones.
So
this
is
a
really
good
way
to
search
so
whether
it's
a
portfolio
or
capability
or
feature
or
singular
story
use
an
epic
to
capture
a
description,
business
case
or
any
other
important
data
to
describe
the
large
body
of
work.
A
So
each
epic
has
a
title
and
a
body
of
the
descriptions
you
can
see
here
and
you
can
set
a
manual
start
and
end
date.
You
can
also
inherit
from
issues
within
the
Apex
as
well,
and
you
can
apply.
Labels,
as
you
can
see,
is
on
the
right
on
the
right
hand,
side.
So
we've
got
devops,
secure,
composition,
analysis,
section
category
and
what
have
you
so
issues
or
epics?
It
can
also
be
confidential.
You
can
see
participants
below
who
is
taking
part
in
the
conversations
here
so
and
a
number
of
options
now.
A
So,
as
you
scroll
down
to
the
Epic
page,
you
can
see
a
section
where
we
break
down
a
large
Epic
into
discrete
logical
pieces
for
individual,
so
independent
tracking
with
child
ethics
and
issues.
These
are
all
hierarchical
and
dynamic.
You
can
click
to
expand.
These
Apex
are
designated
by
a
stack
of
papers,
issues
I
designated
by
single
sheet
of
paper
icon.
So,
as
you
might
be
aware,
gitlab
has
three
tiers,
which
is
free
premium
and
ultimate,
and
child
epics
are
only
available
in
Ultimate.
A
So,
if
you're
preparing
customer,
then
you
will
be
able
to
see
issues
that
are
linked
to
Epic.
The
health
status
there
at
the
top.
The
green,
yellow
and
there
are
numbers-
are
just
basically
designate
how
many
issues
are
on
track
and
needs
attention
or
at
risk.
So
we
have
11
green
one,
yellow
and
zero
right.
A
Two
wishes
so
we're
Yeah.
So
basically
we
are.
How
do
you
know
if
you're
in
a
group
or
or
a
subgroup
or
in
a
project
left
hand
side
at
the
very
top?
Are
below
distribution?
You'd,
see
subgroup
information
so
immediately
that
way,
you
know
you
are
in
a
subgroup,
so
you
click
on
issues.
You
go
in
the
lists
and
this
is
a
list
of
all
issues
within
this
particular
group.
A
A
Now,
a
little
bit
more
about
how
we
search
here
again,
where
in
the
issues
in
the
list,
that's
just
an
example
of
doing
a
search
using
both
label
and
a
milestone,
a
filtering
by
a
scope
label
and
the
upcoming
milestone
for
gitlog
right.
So
we
have
15.6,
and
then
we
have
labeled
devops
plan
right.
So
this
can
be
combined
with
other
parameters,
including
order
assignee.
What
have
you
and,
as
you
add,
additional
Source
parameters
or
adjust
the
Sorting?
The
URL
in
your
browser
will
be
updated
with
the
appropriate
query
string.
A
So
you
can
see
the
same
exact
query
in
searching
by
bookmarking
on
page
or
even
share
it
exactly
with
somebody
so
which
could
be
helpful
so
here
defining
user
stories
using
issues.
So
this
shows
the
details
of
a
given
issue
with
title
and
description
as
well
as
metadata
on
the
right.
So
right
above
the
title,
we
have
status
open
or
closed
when
the
issue
was
created,
you
can
hover
over
to
see
the
exact
date
and
time
as
well.
A
In
the
regional
author
of
the
issue,
with
the
role
in
the
project
within
the
description
ratio,
you
can
use
mark
it
down,
perform
Archer
texts,
create
sections
order
and
Order
lists
checklists
that
can
track
tasks
needed,
but
they
should
be
closed.
A
couple
key
points
to
highlight
on
the
right-hand
side
in
the
highlighter
area.
As
you
can
see,
assignees
ethics
issue
belongs
to
different
labels.
Milestones
issue
weights.
A
A
In
terms
of
collaborating
and
if
we
scroll
down
on
the
issue,
we'll
see
the
associated,
merge,
requests
and
related
issues
and
discussions,
you
could
have
further
conversations
and
can
add
mention
other
users
to
bring
their
attention
or
requests
and
their
action
on
an
issue.
So
each
issue
or
comment
can
be
reacted
via
MLG
and
yeah.
We
use
this
feature
at
gitlab
track
support
from
team
members,
community
members
and
our
customers
on
issues
that
we
have
the
most
upvotes
so
thumbs
up
to
help
influence
our
product
privatization.
A
It's
not
a
bad
way
to
do
this.
There's
collaboration,
there's
a
three
ways
that
you
can
collaborate
within
gitlab,
so
that
will
be
at
mentioning
somebody
on
an
issue,
an
emerging
Quest
and
then
commenting
on
a
line
of
code
which
you're
going
to
see
a
little
bit
later.
A
So
nothing
side,
we've
seen
related
issues,
issues
that
are
blocking
the
current
issue.
Related
merger
requests
and
clickable
links
on
the
right
hand,
side
we're
seeing
discretion
areas,
compensation
at
mentions-
and
these
generate
notifications
for
those
members
when
their
attention
is
needed.
Most
common
alert.
We
have
this
lab
is
email.
So
you
can
also
note
that
all
emails
from
the
system
will
have
a
classification
Banner
on
emails.
If
that's
desired,.
A
A
You
could
have
multiple
boards
and
switch
between
them
easily.
So,
if
you're,
seeing
the
name
of
the
board
is
triage,
so
if
you
would
have
clicked
on
that,
you
would
have
seen
a
number
of
other
options
that
you
can
click
through.
You
can
create
a
list
and
you
can
put
any
different
kind
of
labels
depending
on
your
workflow
so,
and
this
particular
board
is
at
the
group
level
and
shows
issues
of
all
the
projects
underneath
this
group.
A
So
merge
requests
are
super
powerful
and
you
get
the
complete
view
of
all
aspects
of
change
being
made
to
the
code
base
and
you
can
see
the
latest
pipeline
progress.
You
can
review
and
prove
the
changes
you
can
review.
Security
scan
results
all
in
one
place.
So
if
we
start
from
left,
we
see
that
it's
work
in
progress
It's
designated
by
WIP.
So
everyone
knows
that
hey
someone's
working
on
this
as
we
go
down,
we
can
see
that
there
was
one
commit,
a
one-part
client
run
and
two
changes
were
made.
A
So
we
see
that
also
it
requires
approval
and
there's
also
a
view
up
in
the
review
section,
which
means
that
you
can
click
on
that
and
you
will
see
your
application
Live
and
you
can
visually
check
it.
You
can
also
see
that
the
code
quality
has
improved
in
this
particular
commit.
We
see
that
all
the
security
scanning
detected
fully
Logistics
vulnerabilities
lots
of
great
commits
from
where
I'm
standing
also
license
compliance
added
on
your
license.
So
you
would
have
said
a
particular
rule
that
would
have
said
hey.
A
We
need
to
be
compliant
with
a
you
know.
This
is
that
license,
so
we
haven't
broken
anything
so
in
order
to
deploy,
we
would
need
to
change
the
working
progress
to
complete
it.
So
we
need
to
resolve
this,
and
also
a
cool
feature
is
being
able
to
collaborate
on
a
line
of
code
is
what
you're
seeing
right
on
site.
So
you
can
start
a
review
and
you
can
ask
things
like
hey.
Why
really?
Why
right?
So?
A
Why
did
you
write
this
code,
so
that
has
to
be
also
resolved
before
it
can
be
submitted
to
production?
So
what
should
be
here
is
the
full
pipeline
graph,
all
the
jobs
in
gilab
cicd
pipeline.
A
So
basically,
everything
starts
with
a
build
stage
where
you're
building
the
application
then
you're
running
different
task
situations.
Unit
tests,
then
it
moves
to
staging.
There
will
be
also
a
number
of
security
scans
running.
Essentially,
it
gets
a
lot
more
complicated
here
and
what
you
see
what
you're
seeing
on
the
slide
is
a
great
terminology
to
be
familiar
with,
if
you
haven't
seen
it
before.
So
what
cicd
is
we're
going
in
a
more
detail
in
other
webinars
in
how
to
start
with
cicd
with
gitlab?
A
So
now
a
little
bit
more
about
group
labels
and
this
view
shows
labels
again
at
the
group
level,
it
can
be
filtered
by
keywords
to
find
the
relevant
relevant
labels.
This
is
showing
all
the
priority
labels
in
this
group,
and
these
are
using
the
scope
label
feature
that
lets.
You
create
a
name
value
pair
for
labels,
so
only
one
of
each
category
can
be
applied
at
a
time.
So
now
we're
looking
for
Priority
One
Two
Three.
A
Here,
as
you
can
see,
you
can
create
labels
for
lots
of
different
purposes
and
they
can
be
applied
to
epics
issues,
merge
requests
and
what
have
you
in
those
group,
Milestones
they're,
a
way
to
book
issues,
emerge,
requests
together
and
block
a
time
they
have
a
defined
start
and
end
date.
They
don't
include
any
number
of
issues
and
merge
requests.
So
here
we
see
all
the
milestones
for
this
group
and
any
Milestones
created
for
this
project
and
in
group
as
well.
A
So
you
get
a
summary
view
of
the
number
of
issues
a
merge
requests
to
the
Milestone
and
how
about
how
far
along
it
is.
So
from
now,
when
we
see
you
know
at
the
very
top
15.
our
group
Milestone
on
what
a
thousand
fifteen
hundred
and
issues
three
thousand
five
hundred
merge
requests.
99
complete!
So
that's
great
and
you
can
also
drill
into
these
and
see,
burn,
burn
down
and
up
charts
associated
with
the
milestone.
A
So
there
are
a
little
ways
to
navigate
in
gitlab
and
on
the
left.
You
can
easily
switch
to
view
different
types
of
data
within
the
group
or
projects
reviewing
so
at
the
top
Center.
You
have
breadcrumbs
I'll
show
you
where
you
are
in
a
group
of
project
hierarchy,
so
that's
going
to
be
confusing,
you
could
be
lost
where
I
am
and
that's
very
helpful.
A
So
so
you
can
see
that
whenever
you
change
the
using
gitlab,
the
URL
changes
and
you
can
bookmark
or
share
the
URL
to
the
exact
view
you're,
currently
on
and
again
depending
on
where
you
are
in
a
Google
project,
The
View
will
change.
A
So
in
terms
of
how
you're
going
to
create
a
project,
if
you're
looking
to
do
that
so
from
the
group
page,
we
can
click
the
create
project
button
and
create
a
new
project.
We'll
have
different
options
to
create
a
blog
project.
Import
want
to
create
from
a
templates,
so
if
you've
never
used
gitlab,
if
you've
never
created,
one
I
suggest
you
try
create
from
template.
A
There's
a
number
predefined
projects
that
we
have
done
that
allow
you
to
deploy
a
simple
application
in
a
matter
of
minutes,
so
I
suppose
we're
almost
done
here,
we're
getting
closer
q,
a
part
which
wanna
answer
all
the
questions.
So
if
you
want
to
start
stay
up
to
date
on
more
webinars,
here's
a
link,
there's
a
short
link
that
I've
created.
So
if
you
want
to
kind
of
take
a
screenshot
of
that,
we
have
a
lot
more
coming
up
but
I
suppose.
A
As
a
summary,
we
reviewed
today,
foundational
Concepts
such
as
you
know
how
gitlab
is
really
news,
how
things
are
organized
the
terminology,
navigating
the
UI
and
fundamentals
for
tracking
work.
We
also
come
with
GitHub
flow
for
future
branch,
so
I
just
hope
that
it
was
useful
and
if
you
have
any
feedback,
let
us
know
how
how
it
went
whether
you
liked
the
session.
What
are
you
know?
It
could
be
improved
in
any
way.
We
appreciate
feedback
in
all
sorts
of
forms.
B
Yes,
I,
yes,
I
guess
everyone
can
hear
me
now
so
I
have
picked
three
questions
coming
from
the
audience
that
I
thought
were
really
interesting
and
that
we
should
talk
about
them,
live
the
first
one
being
from
Anonymous
attendee
I
like
to
understand
more
about
the
review
app
and
how
we
can
implement
it
with
our
branching
strategy.
A
Right,
okay,
I
suppose
from
what
from
what
side?
I'm,
not
quite
sure
it's
it's
part
of
kind
of
our
best
practices
usually
happens
after
the
code
is
I
suppose
is,
is
checked
for
so
yeah
I,
just
I,
wonder
yeah.
B
From
if
I
can
add
some
details
around
the
review
app
and
how
it
should
be
leveraged
and
used,
yeah.
B
First
of
all,
as
Greg
mentioned,
the
review
app
is
the
live
running
replica,
that
of
your
app
and
that
will
run
the
code.
That's
currently
leaving
on
the
feature
branch
in
general
or
more
precisely.
If
you're
executing
a
pipeline
that
builds
review
apps,
it
will
contain
the
code
within
that
Branch
I
would
say.
Review
apps
are
in
general,
useful
for
having
a
live
running
replica
that
you
can
use,
for
example,
for
user
acceptance
tests.
You
can
share
the
URL
with
your
users
and
you
can
get
that
validation.
B
Ideally,
this
happens
before
deploying
to
production
and
having
review
apps
and
leveraging
review
apps
helps
you
shift
that
left
and
get
that
feedback
quicker,
making
the
the
whole
feedback
loop
for
the
development
team,
for
example,
and
for
the
people
that
are
in
charge
of
of
approving
that
merge
request
faster.
B
It's
a
quicker
loop
with
stronger
feedback.
I
would
say
you
can
leverage
review,
apps,
no
matter
the
branching
strategy.
However,
we
do
encourage
people
to
use
feature
branches
now,
once
development
is
done
on
that
feature
Branch,
if
you
merge
it
into
the
master
Branch
directly
or
if
you
have
a
bunch
of
other
branches
in
between
it's
fine,
you
can
still
leverage
the
review
app
and
I
hope.
This
clarifies
that
topic
a
bit.
C
A
That
was
Master.
Thank
you.
Bob
yeah,
there's
a
couple
more
there.
So
how
important
labels
there's
not
a
question
so
I
suppose
yeah.
It
depends
on
on
how
your
your
doing
your
personalization
and
how
you're,
who
is
doing
the
planning.
So
it
depends.
It's
definitely
a
good
teacher
to
take
a
look
at.
We
can
definitely
answer
that
with
us
more
documentation.
How.
A
B
We
quickly
covered
issue
boards,
for
example,
and
Greg,
showed
some
examples
from
gitlab.com,
because
we
do
use
gitlab
to
build
gitlab
the
product,
but
also
run
gitlab
the
company
having
a
good
label
set
and
what
a
good
label
said
is
is
very
subjective.
That
depends
on
you.
Your
structure,
your
workflow
and
all
that
stuff
enables
you
to
search
filter
issues
quickly,
but
also
it
provides
better
value
out
of
our
issue
boards,
because
we
did
lab
issue
boards.
B
The
same
issue
can
be
presented
in
different
boards
and
that
will
give
you
different
views.
We
have
boards
for
specific
teams,
for
example,
where
they
are
highlighting
the
issues
that
they
are
working
on
and
we
have
boards
more
backlog,
type
of
where
we
have
everything
that
we
are
working
on,
hope
that
makes
sense
and
clarifies
a
bit
issues.
Issue
labels,
sorry.
B
And
yeah
the
third
one
was
gitlab,
looks
similar
to
jira
I
use
jira,
but
they've
said
my
company
use
both.
Why
that's
a
very
great
thing
you
want
to
answer
this.
First
of
all,
I'm
sorry,
I,
don't
wanna
look.
B
B
If
you
will
synced
up
what
we
noticed
from
experience
talking
with
customers
is
that
traditionally
people
prefer
jira,
because
they
are
more
used
to
it
from
the
past,
the
Developers
like
gitlab
and
they
explore
gitlab
and
they
start
using
gitlab
issues,
because
it
provides
a
better
link
between
the
planning
side
of
things
and
source
code
management
and
moving
onwards
to
cicd
and
merge
requests.
B
This
is
what
we
noticed
from
experience.
It's
not
a
very
precise,
accurate
answer,
but
hope
this
helps
give
you
some
sense
about
why?
Let's
hold
this
Gap
right,
this
Gap
is
happening.
A
Yeah
we're
different
to
do.
We
had
just
quite
a
lot
of
interesting
ones,
so
I
yeah
I
should
be
not
quite
sure
if
we
can
have
labels
on
pipelines.
Do
you
want
to
take
that
one
as
well.
A
B
There
was
a
conversation
to
be
able
to
do
that
at
one
point,
but
I'm,
not
sure
if
we
delivered
this
yet
next
question
in
the
line
from
column.
Do
you
keep
your
documentation
only
gitlab
or
it's
part
in
another
tool
from
a
product
perspective
or
a
company
perspective
from
a
product
perspective?
I
think
it's
mostly
in
gitlab,
but
you
do
need
to
take
to
take
into
account
that
we
do
have
docs.gitlab.com
to
hold
the
product
documentation.
We
do
have
about
dot.
B
Gitlab.Com
I,
think
the
name
of
the
URL
is
to
contain
information
about
the
company
and
in
a
more
General
type
of
information
and
internally
for
meetings
and
collaboration
and
communication,
because
we
are
async
in
nature
and
we
that's
one
of
our
core
values.
As
a
company,
we
are
using
a
lot
of
Google
Docs
to
document
stuff.
B
So
this
is
how
we
document
things
in
at
gitlab
in
in
multiple
mediums,
I
would
say:
yeah.
A
B
Also,
for
example,
I
realized
right
now
sorry
Greg
for
interrupting.
We
do
provide
gitlab
pages
and
wikis
in
our
projects
and
groups,
so
that
would
be
an
alternative.
If
you
want
to
document
some
things,
that's
possible
and
yeah.
You
can
leverage
that
as
well.
B
B
Probably
use
review
apps,
sorry
we'll
set
up
so
in
general,
with
review
apps,
we
do
provide
a
template
for
the
job
review.
Apps
will
use
the
kubernetes
cluster
that
you
have
configured
that
a
group
or
a
project
level,
and
there
will
be
without
going
into
too
many
details,
time,
wise
and
detail-wise.
This
is
an
intro
section
session.
B
The
job
that's
part
of
the
pipeline
will
use
that
kubernetes
clusters
to
create
the
review
app.
It
will
create
the
URL
and
you
will
get
a
link
to
that
URL
in
the
merge
request
web
page.
B
So
this
is
how
the
review
app
is
created.
How
we'll
use
review
apps
I
think
I
already
covered
this.
It's
a
live
running
replica
of
your
app
testing
in
general.
All
sorts
of
testing-
this
is
very
useful
for
I,
would
say
and
then
search
live
and
yes,
are
there
near
future
plans
for
the
laptops
offers
job
related,
metrics
or
test
related
metrics
I'm
interested
to
observe
for
regressions
jobs
and
test
in
terms.
B
So
in
general
we
do
provide
these
metrics
job
related
and
pipeline
related.
You
can
see
how
much
time
it
takes.
You
can
see
how
much
time
this
was
queued
and
all
that
stuff
I'm,
not
sure
if
there
are
some
additional
metrics
coming
up,
but
let
me
quickly
bring
that
up.
B
I
have
written
a
blog
post
around
more
efficient
pipelines
or
exciting,
getting
greater
efficiency
from
your
Pipelines
and
I'll
post.
A
link
to
that
hope
that
helps
and
and
yeah
moving
on
to
the
next
one
we'd
like
to
have
comments
on
and
labels
on,
Pipelines.
B
Yes,
we'll
we'll
make
a
note
of
that
and
send
this
feedback
further
to
our
product
management
team.
B
How
can
we
perform
web
inspect
for
those
45
percent
server
type,
any
template
guides
so
in
general
and
I
think
this
is
a
question
that's
better
suited
for
the
next
session,
which
is
intro
to
CI
CD,
but
quickly
to
address
all
this
with
gitlab
CI
we
use
yaml,
which
means
that
you
can
use
any
scripts.
Any
API
calls
any
web
hooks
in
your
jobs.
If
you
want
to
trigger
any
third-party
tool
with
the
web,
inspects
45,
so
no
type,
you
can
definitely
do
so
for
a
job
in
your
pipeline.
B
You
can
even
use
gitlab's
API
to
send
a
message
back
and
if
you
want
to
publish
those
results,
add
some
comments
in
the
merge
request,
for
example,
so
that
the
developer
has
quick,
easy
access
to
that
for
the
team
that
needs
to
approve
it.
You
can
do
so.
We
don't
have
any
templates
for
third-party
tools,
but
we
do
have
a
CI
yaml
reference,
Doc,
Page
and
I'll
post.
The
link
to
that
into
the
chat
hope
this
helps.
Will
there
be
better
tools
to
import
from
jira
server
to
gitlab?
B
We
do
have
a
jira
integration,
so
you
can.
If
you
want
to
still
use
jira,
you
can
definitely
do
that
and
have
the
link
to
the
source
code
and
the
stage
moving
beyond
source
code
Management
in
gitlab
in
terms
of
actually
moving
the
work
items
from
jira
to
gitlab
I,
don't
think
there
will
be
a
two,
because
the
philosophy
and
the
design
of
the
product
is
different.
B
C
To
Echo
what
blood
settings,
what
we
see
from
other
customers
that
they're
using
the
apis
to
to
get
the
base
data
or
but
this
is
customized
so
I-
don't
think
our
product
team
is
currently
investing
into
into
building
out
an
importer.
A
B
That's
fine
yeah,
so
it's
fine,
no
worries.
It's
fine!
It's
fine!
Okay,
yeah
yeah!
Any
related
videos
would
be
helpful.
Sorry
I
just
see
Anonymous,
attendee,
I.
Guess
it's
about
review.
Apps.
B
I
think
so,
honestly,
I
don't
know
if
we
have
any
additional
videos
on
that,
but
I
would
say
on.
B
Where
we
kind
of
educational
videos,
yeah.
B
Being
aware
of
time,
I
have
another
question:
can
we
monitor
our
pipeline
stage
duration
Etc
with
grafana?
Yes,
you
can
do
that
I'm,
not
sure
which
exor
we
provide
I
think
there
were
some
dashboards.
B
There
were
some
grafana
dashboards
that
covered
Pipelines.
Let
me
put
that
link
into
chat,
so
yeah
look
into
that,
and
you
can
of
course
create
your
own
if
the
metrics
contained
there's
aren't
exactly
what
you
need
next
question:
is
there
any
documentation
on
how
to
migrate
from
external
Gila
pipelines
to
gitlab
Runner?
We
are
observing
race
around
I'm,
not
sure
I,
understand
this
question
in
general,
so
documentation
around
how
to
migrate
from
an
external
ci2
to
the
internal
gitlab
CI
tool
right.
B
B
My
personal
recommendation,
when
dealing
with
migrations
in
general
and
I
would
say,
CI
migrations
in
particular
would
be
to
leverage
template,
job
templates
or
even
pipeline
templates.
Now,
of
course,
probably
there
won't
be
exact
templates
out
there
for
your
specific
needs.
B
So
my
recommendation
would
be
look
at
the
projects
that
you
currently
have
do.
I
try
to
identify
a
pipeline,
that's
used
by
the
majority
of
your
projects
and
migrate
that
first,
the
gitlab
once
that's
up
and
running
and
you're
happy
with
the
results
create
templates
out
of
it
and
then
once
you
migrate,
the
second
project,
you
already
have
some
learnings
from
the
first,
the
first
one,
and
you
already
have
some
templates
that
you
can
use
to
build
that
pipeline
quicker.
B
Do
that
a
couple
of
times,
and
then
you
can
think
about
migrating
these
projects
more
at
a
time
that
that
that
would
be
the
recommendation
in
terms
of
factual
documentation.
The
link
that
I
sent
earlier
about
the
yaml
reference,
where
you
can
see
all
the
keywords
that
you
can
use
and
all
the
mechanisms
would
be
helpful,
also
tuning
in
next
week,
where
Greg
will
discuss
about
CI
CD
would
be
yeah.
My
recommendation
as
well
hope
that
covers
it.
B
The
code
quality
templates
in
having
a
dependency
on
Docker
Hub
if
they're
customizable,
is
there
a
plan
to
have
this
fixed
I,
don't
know,
I
think
we
can
take
this
offline
and
if
anyone
or
if
any
of
my
colleagues
are
available
to
do
some
search
in
the
background
to
find.
If
we
do
about.
B
So
the
question
about
monitoring
pipeline
States,
all
that
stuff
I-
think
I
already
answered
that
this
Gila
has
as
much
buglings,
so
gitlab
CI
doesn't
have
plugins.
B
Our
product
philosophy
over
here
is
significantly
different
from
Jenkins
Jenkins
leans
heavily
on
plugins,
and
we
know
from
discussing
with
customers
that
these
are
a
headache
to
maintain
on
a
monthly
basis
with
every
update
things
break,
and
you
don't
know
exactly
where
and
why
so.
We
don't
provide
plugins,
but
our
CI
structure
is
flexible.
So
you
can
use
Scripts,
as
I
mentioned
earlier,
to
trigger
apis
to
run
containers
web
hooks.
Everything
that
you
need
to
bring
in
third-party
tools
into
the
mix.
B
A
B
A
Was
a
follow-up
one
of
the
questions
of
answers,
but
I'm
not
quite
sure
which
one
it
was
so
yeah,
let's
skip
to
the
next
one
I
think
that's
the
last
question
we'll
take
for
it
for
now.
B
So
yeah
the
grafana
exporter,
I,
don't
know
we
need
to
do
some
research
and
get
back
to
you
on
that.
We
added
gitlabs
here.
Yes,
the
problems
is
both
gitlab
Runner
and
Jenkins.
Trying
to
update
the
pipeline
status
well,
I
would
encourage
you
to
just
pick
one
CI
tool.
B
If
you
have
gitlab
CI,
then
the
pipeline
will
get
triggering
with
lab
CI,
which
means
you
don't
need
to
have
Jenkins
pipeline.
B
Just
have
one
that
that's
where
the
conflict
comes,
I
would
say
in
the
initial
state
or
when,
when
you're
migrating,
these
things
move
the
source
code
over
first
or
if
the
source
code
is
already
in
gitlab.
As
you
mentioned,
just
develop
a
pipeline
there
temporarily
deactivate
the
web
hook,
so
things
aren't
triggered
in
Jenkins
while
you're
developing
stuff
and
then
once
everything
is
ready,
just
switch
to
The
Gila
pipeline.
We
don't
recommend
having
multiple
pipelines
and
quickly
it's
so
gitla
pipelines.
B
B
Thanks
to
the
audience
for
making
this
a
very
interactive
session
appreciate
it
enjoyed
it.