►
From YouTube: Intro to GitLab Webinar
Description
Are you new to GitLab? Join this webinar, where we will review what GitLab is, how it benefits you, and the recommended workflow to allow you to get the most out of the platform.
A
Hi
everybody
looks
like
we
have
people
joining
us,
thanks
for
for
coming
in
this
morning
or
afternoon,
depending
on
where
you're
at
we're
gonna
give
folks
just
another
minute
or
so
to
join
us,
and
we
will
get
started.
A
Okay:
let's
go
ahead
and
jump
in.
Thank
you.
Everyone
for
joining
us
today
we're
grateful.
You
took
some
time
out
of
out
of
your
calendar
to
to
learn
with
us.
We're
excited
to
go
through
the
content
before
we
jump
in.
I
just
wanted
to
go
through
some
quick
housekeeping
items
for
any
questions
that
come
up
throughout
the
session.
Zoom
has
a
function
where
you
can
directly
enter
those
into
the
q.
A
In
addition
to
that,
this
session
is
being
recorded
and
will
be
sent
out
to
anyone
who
registered
or
attended
to
today's
session.
So
you
can
look
forward
to
that
in
the
coming
days.
With
that
I'll
hand,
it
over
to
kevin
chassis,
he's
a
staff
technical
account
manager
here
at
gitlab
and
excited
to
hear
from
him
today.
B
Today
we
are
going
to
be
going
over
kind
of
introduction
to
git
lab,
so
we're
going
to
do
kind
of
a
high
level
overview
of
git
lab
and
some
of
the
different
things
that
you
can
do
with
it
and
help
you
to
get
started
with
your
use
of
git
lab
as
taylor
mentioned
I'll,
be
feel
free
to
put
your
questions
in
the
q
a,
and
we
do
have
some
other
tams
that
are
on
that
will
help
answer
some
of
those
and
I'll
be
doing
a
interactive
q
a
at
the
end.
B
So
any
questions
that
aren't
answered,
I
will
take
those
at
the
end
but
feel
free
to
put
them
in
as
you
think
of
that,
all
right.
So,
first
and
foremost,
what
is
git
lab
so
git
lab
is
a
single
tool
for
the
complete
devops
life
cycle.
B
B
Continuous
deployment
is
saying
that
we
added
fairly
quickly
in
the
early
days
of
get
lab
and
it
was
decided
at
the
time
to
go
ahead
and
add
that
as
a
feature
into
the
main
application,
rather
than
making
a
separate
application,
and
that
decision
actually
has
really
paid
off
because,
as
we
added
more
features
to
support
the
entire
devops
life
cycle,
they've
all
been
added
in
as
as
part
of
the
main
gitlab.
B
So
you
have
one
application:
one
user
interface,
one
data
model,
one
security
model
to
support
your
devops
life
cycle
as
opposed
to
multiple
tools,
and
then
we
have
other
features
like
we
have
built-in
wiki.
We
have
built-in
issue
tracking
and
of
course,
git
lab
is
still
to
this
day
an
open
source
solution,
and
you
know
we
remain
so
in
our
are
very
proud
of
that.
B
So
gitlab
helps
you
to
one
of
the
things
that
gila
helps
you
to
do
is
to
kind
of
shift
towards
the
more
modern
way.
If
you
haven't
already
of
doing
concurrent,
devsec
ops
and
there's
a
lot
of
tools
built
into
gitlab
to
make
this
easier
and
simpler.
Now,
if
you're
running
a
different
process,
if
you're
running
an
older
methodology
of
software
development,
that's
fine,
you
can
still
use
gitlab
and
you
can
still
use
gitlab
in
the
way
that
you
do
it
today
and
then
you
can
slowly
migrate.
B
We're
gonna
show
you
some
tips
and
tricks
on
how
to
do
that
and
talk
a
little
bit
more
about
that
as
we
go.
But
basically
the
idea
of
sequential
devops
was
where
you
had
teams
working
in
silos.
There
might
have
been
friction
between
handoff.
B
I
know
I
worked
for
a
company
once
where
it
was
more
important,
not
for
your
team
not
to
be
the
reason
we
failed,
as
opposed
to
focused
on
everyone
working
together
towards
success,
so
it
was
more
failure,
avoidance
rather
than
success,
achievement
and,
of
course,
at
gitlab.
We
want
to
help
you
succeed,
and
so
we
want
to
help
your
team
to
focus
on
success
and
not
not
avoiding
failure
and
see.
B
So
you
can
avoid
some
of
those
negative
points
of
finger,
pointing
or
even
things
like
security
as
an
afterthought
and
unpredictability
and
un.
You
know,
lack
of
reliability
is
another
one
that
sometimes
plagues
kind
of
the
this
older
way
of
doing
things.
B
By
moving
to
concurrent
devsecops,
where
you
have
a
a
team,
that's
working
all
together.
You
have
folks
from
development
test
security
program
management
and
operations,
all
working
together
as
a
single
team
with
seamless
collaboration,
regardless
of
where
they
are
right.
Git
lab
is
100
remote
company
and
we
use
gitlab
to
build
gitlab
and
to
run
our
own
gitlab
business,
and
so
we've
built
in
a
lot
of
tools
to
make
it
easy
to
to
work
across
different
offices,
folks,
working
from
remote
or
even
just
folks,
in
other
buildings,
on
your
campus.
B
Potentially
we
make
that
all
really
easy
by
giving
you
lots
of
collaboration
tools,
because
we
need
them
ourselves
for
the
way
we
use
gillap,
there's
also
full
accountability,
embedded
security
and
there's
even
metrics
and
measurements
that
you
can
use
to
kind
of
honestly
look
at
your
own
use
of
gitlab
and
see
where,
where
there
may
be
delays
in
your
process,
where
your
process
may
be
breaking
down,
and
then
you
can
focus
on
improving
those
and
then
measuring
again
to
see
how
you
did
against
those.
B
So
a
lot
of
benefits
and
you'll
see
just
some
of
the
beginnings
of
the
tips
and
tricks
on
how
to
get
the
most
out
of
get
lab.
Today.
B
So
here's
an
other
view
of
kind
of
the
devops
life
cycle
and
the
the
terms
you
see
here
represent
the
stages
of
devops
as
defined
by
gartner.
So
we
we
didn't
make
these
up.
We
actually
aligned
our
different
development
areas
and
feature
sets
around
these
stages
that
are
defined
by
gartner,
which
is
an
independent
organization
not
related
to
gitlab
right.
So
the
idea
here
is:
is
you
can
start
by
planning
your
work
and,
of
course
you
can
do
all
of
this
within
gitlab
right.
B
B
You
can
then
use
gitlab
ci
to
do
your
automated
build
automated
verification,
automated
testing,
whether
that's
unit
testing
integration,
testing
or
even
automated
ui
testing.
If
your
application
supports
that,
you
can
do
all
of
that
within
the
verify
stage
as
part
of
gitlab
ci,
and
then
we
also
can
do,
excuse
me
package
and
release
within
gitlab.
So
we
can
help
you
package
your
solution
up
and
even
help
you
deploy
it
out
either
to
the
cloud
or
to
your
own
infrastructure,
and
we
are
cloud
agnostic
at
gitlab.
B
So
we
can
even
support
multiple
clouds,
you're,
not
locked
in
to
a
single
cloud
infrastructure.
You
can
also
use
git
lab
to
if
they're,
controlling
those
and
if
you've
allowed
you'll
have
to
control
those
environments.
You
can
use
it
to
configure
and
even
monitor
those
environments
and
then
continue
the
cycle
with
new
new
changes
you
want
to
make
and
so
on,
and
then,
of
course
throughout.
B
All
of
that,
you
have
a
built-in
security
scanning
defense
of
those
environments
and
also
the
ability
to
manage
gitlab
and
your
the
folks
using
gitlab,
and
this
allows
you
to
take
in
problems
and
provide
solutions
very
quickly
efficiently,
using
a
single
platform
single
data
model
that
is
simple
and
secure
and
transparent
to
the
entire
organization.
B
So
this
is
just
a
slightly
different
view
of
those
10
stages,
and
this
is
just
really
re-emphasizing.
The
point
that
I
already
kind
of
made
with
git
lab,
covering
all
10
of
these
stages
as
well,
and
using
and
doing
it
with
a
single
data
store,
permissions
user
interface,
built-in
governance
and
security
and
and
lots
of
ways
to
help
your
team
collaborate.
B
And
then,
of
course,
as
I
mentioned
earlier,
analytics
that
will
help
you
team
to
take
an
honest,
look
and
see
how
they're
doing
and
then
use
that
to
do
self-improvement
and
then
measure
and
see
how
those
improvements
helped.
The
team
in
the
future.
B
All
right,
so,
let's
talk
a
little
bit
about
the
get
lab
recommended
process,
so
this
is
also
known
as
get
lab
flow,
and
the
concept
here
is
pretty
simple
and
again:
you
don't
have
to
do
this
from
day
one,
but
we
do
recommend
that
you
take
a
look
at
this
and
the
advantages
it
provides
and-
and
you
can
slowly
migrate
from
wherever
you
are
today
to
this
kind
of
model.
B
So
if
you
can
imagine
this
bottom
line
of
it
represents
your
current
production
line
of
code
or
your
default
branch
within
gitlab,
and
there
you,
you
may
use
our
epochs
and
issues
to
plan
and
discuss
what
the
change
is
going
to
be
an
issue
in
gitlab,
as
you're
going
to
see
in
a
few
minutes
can
be
a
user
story.
It
could
be
a
feature
request.
It
could
be
a
bug
report.
B
A
B
Those
issues
are
open
to
the
public
at
get
lab
so
that
our
users,
our
customers,
even
folks
who
aren't
our
customers,
can,
can
see
those
and
comment
on
them
and
provide
feedback
and
say
you
know
what
it
really
should
go
in
this
direction.
Or
this
isn't
a
good
idea.
We
should
do
something
different
or
whatever
the
case
may
be.
All
of
that
happens
within
the
issue
and
you'll
see
some
examples
of
that
coming
up
when
we
get
into
what
this
all
looks
like
in
gitlab
itself,.
B
It'll
automatically
create
the
feature
branch
associated
with
that
issue
and
merge
request,
and-
and
we
recommend
that
you
create
the
merge
request
at
the
beginning
of
the
process
and
you'll-
see
why,
in
a
moment,
because
of
all
of
the
very
valuable
data
and
history
it
collects,
some
some
workflows
will
have
you
create
the
merge
request
here
at
the
end,
when
you're
ready
to
to
merge
it
and
some
systems
called
pull
request.
B
But
here
at
gitlab,
because
we
view
it
as
you're
requesting
to
merge
your
changes
into
the
production
line
or
the
main
line.
And
so
we
call
it
a
merge
request
when
you
create
that
merge
request.
It
is
now
associated
with
a
one-to-one
to
this
feature
branch,
which
is
an
isolated
branch
of
code,
where
the
changes
that
you
make
will
not
affect
any
of
the
other
developers
will
not
affect
your
production
systems.
It's
isolated
and
the
beauty
of
that
is
that
it
allows
you
to
make
your
changes
and
those
are
known
as
commits.
B
Each
change,
which
could
be
multiple
files
can
be
a
single
commit
and
you
can
commit
early
and
often
to
to
get
lab
and
there's
really
no
cost
associated
with
that.
Your
developers
can
can
commit
changes
locally
and
push
them
up
to
the
server
or
they
can
even
do
commits
directly
using
our
web
ide
on
the
server
and
when
those
changes
are
seen
by
the
server
by
default.
The
continuous
integration
pipeline
will
run
and
that
allows
you
to
automatically
build
your
code
and
run
whatever
tests.
B
B
You
have
security
scans
as
well
as
things
like
code
quality,
but
we
have
all
kinds
of
different
security
scans
that
are
available
within
gitlab,
and
you
get
feedback
on
those
right
away
at
the
time
of
commit,
as
opposed
to
doing
them
down
the
road
where
it
might
be
weeks
or
months
after
the
developer
made
their
changes
and
they
can't
remember
what
their
mindset
was.
B
They
can't
remember
what
they
were
thinking
at
the
time
and
thus
it's
more
difficult
to
fix
those,
whereas
when
the
developer
gets
feedback
right
away,
hey
you
just
introduced
new
vulnerability,
they
can
go.
Oh
geez,
I
didn't
even
realize
that.
Let
me
just
rework
this
slightly
recommit
and
then
it'll
rerun
it
and
you
can
see
oh
yeah
I
did.
I
did
address
that
correctly,
because
it'll
rerun
the
security
scans.
B
You
can
also
optionally
deploy
out
to
a
temporary
review
app
if
you're
using
kubernetes,
it
can
actually
be
dynamic
and
you
can
have
multiple
review
apps
running
at
the
same
time
for
each
feature
branch,
but
you
can
also
push
this
out
to
a
test
environment.
B
You
can
even
make
it
available.
You
know
if
it's
web-based
application,
you
can
make
it
available.
Your
customers
and
internal
or
external
stakeholders
can
come
in
and
take
a
look
and
give
you
feedback,
which
is
really
powerful
within
the
merge
request.
You
can
also
do
discussions
just
like
you
did
within
the
issue,
but
you
can
also
there's
a
great
mechanism
for
doing
code
reviews
built
into
the
merge
request
where
you
can
do
general
comments
and
create
actions
for
the
developer,
or
you
can
tie
it
to
individual
lines
of
code.
B
You
can
do
code,
suggestions
and,
and
the
developer
can
accept
those
or
provide
comments
or
make
additional
changes
to
address
those.
You
can
also
do
reviews
of
the
security
results.
So
your
security
team
can
view
the
results
of
the
security
scans
directly.
Within
the
merge
request,
you
can
see
only
the
things
that
changed
or
the
full
reports
which
is
really
powerful.
B
What
your
approvals
look
like
and
you
can
have
any
number
of
approvals-
you
can
have
approvals
dynamically
generated
based
on
the
security
results,
and
you
can
have
once
people
once
you
have
the
required
number
of
approvals.
You
can
then
have
the
ability
to
merge
this
back
in.
Of
course,
any
additional
changes
can
automatically
reset
those
approvals
rerun
these
pipelines
rerun
the
scans
redeploy
to
the
review
app
and
the
nice
thing
about
this
process.
Is
that
it's
isolated?
B
So
the
idea
here
again
is
to
do
a
short-lived
feature
branch,
where
you
can
do
all
of
your
testing
and
have
great
deal
of
confidence
that
this
change
is
going
to
a
do.
What
you
thought
it
was
going
to
do.
It's
not
going
to
have
significant
negative
effects
and
your
team
can
have
confidence
and
you
can
increase
the
confidence
level
of
your
stakeholders
and
your
customers
as
well,
because
these
small
changes
each
one
builds
and
increases
that
confidence
level
as
they
successfully
are
deployed.
B
Okay,
I've
got
a
little
cheat
sheet
here
for
some
of
the
terminology
within
gitlab,
so
if
you're
brand
new
to
gitlab
on
the
left,
we
have
all
of
common
terms
for
objects
within
gitlab,
and
then
I
have
a
description
of
what
each
of
these
are
and
then
what
terms
that
you
might
have
heard
these
referred
to
in
the
past.
So
let
me
just
walk
through
these
pretty
quickly,
so
in
gitlab,
the
concept
of
a
project
and
different
tools
use
the
word
project
differently.
B
So
it's
important
to
understand
what
gitlab
means
by
a
project,
but
a
project
is
where
your
code
lives.
So
it's
where
your
code
repository
is,
but
it
also
contains
all
of
your
issues.
Your
merge
requests,
your
pipelines,
all
of
those
other
things
that
we
talked
about
live
within
the
project.
B
B
You
can
estimate
the
size
of
the
effort
you
can
actually,
even
if
you
want
to
track
time
and
and
assign
the
work
and
so
on,
epics
are
a
collection
of
related
issues
across
groups
to
organize
by
theme.
B
B
B
They
can
represent
priority
severity,
whether
it's
a
software
or
a
hardware
issue
all
kinds
of
different
things.
These
are
are
completely
customizable
and
we
can
even
create
name
value
pairs
so
that
you
can
have
only
one
type
of
a
certain
label.
So
only
one
workflow
label,
or
only
one
priority
label,
only
one
severity
label
at
a
time,
but
you
can
create
as
many
custom
labels
as
you
want
to
kind
of
tag
and
track
your
work
across
all
of
these
object
types.
B
B
You
can
also
have
milestones
and
iterations
as
a
way
to
track
time,
so
we
have
both
milestones
and
iterations
milestones,
they're
designed
to
be
fairly
flexible
at
gitlab.
We
use
them
to
track
our
monthly
release.
We
do
a
release
every
month
on
the
22nd
we've
made
that
for
over
a
hundred
releases
in
a
row,
and
you
could
do
it
that
way.
You
can
also
some
teams
use
the
milestone
to
track
the
sprint.
Some
use
it
to
track
a
program
increment
or
an
iteration.
B
Sorry
iterations
can
are
a
smaller
piece
of
time.
So
an
issue
can
belong
to
one
milestone
in
one
iteration.
You
could
have
multiple
iterations
within
a
milestone.
If
you
want
so
milestones
could
be
releases,
iterations
could
be
sprints,
but
really
the
the
thing
here
is
that
they
have
a
start
and
end
time
and
they
both
have
burn
up
and
burn
down,
charts
that
you
can
use
to
kind
of
see
how
you're
doing
and
also
plan
and
help
with
your
execution
of
those
efforts.
B
And
then
finally,
we
have
road
maps
which
are
a
visual
representation
for
the
epics
in
in
a
very
in
a
group
or
of
the
subjects
within
a
primary
epic.
B
All
right,
so,
let's
talk
a
little
bit
about
the
the
hierarchy.
So
when
you're,
first
starting
out
with
git
lab
you're
going
to
have
at
the
instance
level,
you
can
have
as
many
top
level
groups
as
you
want
and
that's
represented
by
this
purple
group
here
at
the
top.
B
Underneath
that
top
level
group
you
can
have
as
many
subgroups
and
sub
subgroups
as
you
want
and
then
inside.
The
groups
is
where
your
projects
live,
which
is
where
your
code
lives.
Your
issues
and
everything
like
that
epics
live
at
the
group
level
could
be
either
any
any
level
group
level
doesn't
have
to
be
at
the
top
group
level.
B
But
the
important
thing
here
to
understand
when
you're
first
setting
these
up
is
that,
as
you
add
users,
if
you
add
a
user
with
a
given
permission
level
at
this
top
group
level,
they
will
automatically
have
that
same
group
of
permission
level
at
the
subgroup
and
project
level.
B
So
you
want
to
add
users
to
at
the
lowest
permission
level
at
that
high
group
level,
because
you
can
always
increase
their
permission.
So
say
someone
just
needs
to
be
a
developer
in
at
this
group
level,
so
they're
going
to
be
developer
for
all
of
these
projects,
but
then
maybe
in
this
subgroup,
they're
a
maintainer,
so
they
have
the
ability
to
make
changes
to
settings
for
these
projects.
So
you
could
add
them
as
a
maintainer
here,
but
if
you
have
them
as
a
developer
here,
they'll
be
only
a
developer
over
here.
B
And
so
it's
important
to
think
about
the
hierarchy
when
you're
planning
out,
where
you're
going
to
add
people
and
to
what
permission
level
you're
going
to
add
them
into.
Similarly
with
the
labels
and
the
milestones
that
we
talked
about
earlier,
if
I
create
lot,
I
can
create
labels
of
the
group
level
or
the
project
level.
B
But
if
you
have
a
set
of
labels,
you
want
this
entire
group
to
use
all
every
single
subgroup
and
project
you
want
them
to
use
the
same
severity.
The
same
priority,
the
same
workflow
go
ahead
and
create
those
at
the
top
group
level,
the
highest
group
level,
where
it
makes
sense
for
everyone
to
share
those
same
set
of
labels.
B
Then,
if
this
subgroup
over
here
or
this
project
over
here
has
a
unique
label
that
it
means
it'll
have
access
to
all
of
those
same
shared
labels
of
the
group
level,
but
they
will
also
have
the
ability
to
create
unique
labels.
Maybe
this
this
one
project
involves
hardware
as
well,
and
so
you
need
to
go
to
track
hardware
issues
separate
from
software
issues,
but
maybe
this
one's
a
web-based
group
that
you
don't
care
about
that.
B
It's
completely
flexible,
but
it's
important
to
understand
the
hierarchy
and
things
you
do
at
the
top
group
level
will
affect
all
of
the
subgroups
and
projects
underneath
that
when
you
are
setting
up
this
hierarchy
by
the
way
you
can
also
create
top
level
groups
that
don't
have
any
projects
in
them.
The
use
for
this
is
you
can
create
groups
of
people
like
a
test
group
development
group,
and
then
you
can
use
those
groups
to
just
have
people
within
it
with
no
projects.
No,
nothing
else.
B
The
nice
thing
there
is
that
when
you're
assigning
permissions,
you
don't
have
to
do
it
on
an
individual
basis.
You
could
add
an
entire
group
and
then,
by
doing
it
that
way,
as
you
add
or
remove
members
of
the
group
that
you
added
you
can
they
will
automatically
be
removed
wherever
they
were
added
here.
So.
B
So,
let's
start
by
taking
a
look
at
what
some
of
these
screens
will
look
like
in
gitlab.
So
now
we
are
inside
git
lab
and
what
we
are
looking
at
here
is
a
group
overview
page,
and
so
so
this
is.
This
is
not
a
top-level
group,
but
you
can
imagine
it's
a
top-level
group.
So
this
is
a
group
that
I
created
for
myself
for
for
doing
demos
and
putting
together
presentations
like
this,
and
so
what
you
can
see
on
the
left
hand
side
of
the
screen.
B
You
always
have
context
of
where
you
are
as
well
as
access
to
all
of
the
different
object
types
based
on
where
you
are
so
we're
in
the
kevin
chassis
group.
So
I
can
technically
it's
a
subgroup
because
you
can
see
here
from
the
breadcrumbs
that
I
am
underneath
a
couple.
Other
groups,
it's
so
you
can
click
here
to
get
the
subgroup
information.
B
Today,
since
today
is
a
high
level
intro
session
and
then
in
the
main
body
view
of
your
gitlab
is
going
to
show
whatever
it
is
that
you're
looking
at
so
right
now
we're
just
at
the
generic
intro
view
of
this
group,
and
so
I
get
a
view
that
shows
me
all
of
the
subgroups
and
I
can
expand
these
out
and
collapse
these
and
you
can
see
the
groups
are
represented
by
this
kind
of
folder
icon
and
then,
ultimately,
as
you
drill
down
you're
going
to
see,
projects
and
projects
are
kind
of
represented
by
this
image.
B
Icon,
I'm
sorry,
this
ribbon
icon,
sorry,
and
so
what
and
you
can
explore
these
and
if
I
click
on
these,
it
will
bring
me
in
and
I'll
be
looking
directly
at
that
group
level
or
that
project
level
and
I'll
get
a
view
of
all
of
the
details
of
that
group
or
project.
B
You
also
get
a
quick
view
over
here
on
the
right
of
how
many
subgroups
there
are,
how
many
projects,
and
so
on,
there's
a
lot
of
information
that
is
available
in
line
with
each
of
these
rows,
and
then
you
can
also
create
new
projects
directly
from
here,
new
subgroups
and
so
on,
and
we'll
show
an
example
of
that.
At
the
end,.
B
If
I
click
on
the
epics
view
now,
you
can
see,
look
I'm
still
in
the
kevin
chassis
group.
You
can
see
from
the
breadcrumbs
the
only
thing
that
changed
is
now
I'm
in
the
epic
view
of
the
kevin
chassis
group
and
by
default
I'll
be
in
the
top
item
of
this
epics.
When
I
click
on
epics,
so
I've
clicked
on
epics.
You
can
now
see
that
the
sub
menu
for
epics
has
now
expanded,
and
I
can
see
I
can
still
see
all
of
those
other
object
types.
B
So
I
can
quickly
navigate
to
issues
or
merge
requests
whatever
I
need
to
do,
but
I
can
now
see
the
this
is
showing
me
the
list
view
of
all
of
the
epics
that
are
in
the
kevin
chassis
group.
B
B
How
many
comments
there
are
and
other
things
you
can
also
filter
this
view,
and
you
can
view
recent
filters
or
searches.
This
is
only
going
to
search
within
the
kevin
chassis
group
and
it's
only
going
to
search
within
the
epics.
You
also
have
the
search
bar
up
here
that
will
search
all
of
your
gitlab
instance
by
the
way.
So
that's
the
difference
between
the
two
search
views
you
can.
A
B
Change
the
sort
order
and
the
sort
what
you
sort
by
so
these
are
sort
of
by
due
date.
There's
a
bunch
of
other
fields
that
you
can
sort
by
as
well
as
you
can
do
a
bulk
edit
of
these
epics
or
create
a
new
epic
directly
from
here.
B
All
right,
so
if
I
click
on
one
of
these
epics,
now
I'm
going
to
see
a
detailed
view
of
the
epic
and
you
can
see
on
the
left,
I'm
still
in
the
epic
list
view.
But
it's
showing
me
the
details
of
that
this
epic.
B
Some
of
the
details
that
you'll
see
here
as
you
can
see
whether
the
epic
is
open
or
closed
again.
How
long
ago
was
open
and
by
whom
you
can
see
the
body
of
the
epic
and
the
description,
and
this
is
all
controlled
by
plain
text
using
markdown.
So
gitlab
has
its
own
extension
of
generic
markdown,
which
is
kind
of
an
industry
standard
way
of
taking
plain
text
and
formatting
it,
and
then
gitlab
extends
it
to
include
a
number
of
other
things
where
you
can
reference
other
epics
issues.
Merge
requests
milestones
labels.
B
You
can
do
all
that
as
well
as
create
checklists
which
I'll
show
you
when
we
get
to
issues
in
a
minute.
But
you
could
also
do
that
within
epics
and
so
and
then
you
can
do
heading
sections.
You
can
do
formatting
of
of
the
text
and
have
a
description
of
all
of
the
details.
Of
this
and
I'll
show
another
view
here
in
a
moment
and
then
on
the
right.
B
You
can
also
see
your
your
start
date
and
end
date,
which
can
be
fixed
or
inherited
from
all
of
the
sub
epics
and
issues
within
them,
and
the
milestones
of
those
issues
are
part
of,
and
so
it
can
automatically
pick
up
these
dates
or
you
can
set
a
fixed
date
for
the
beginning
and
end
target
for
this
epic.
B
You
can
see
all
the
labels
that
are
applied
to
the
epic
you
can
see
if
this
is
a
top-level
epic
or
if
it
has
any
children
or
any
parents.
In
this
case
this
is
a
top-level
one,
and
then
you
can
see
all
the
people
that
are
participating
in
this.
So
participants
are
people
who
have
been
at
mentioned,
so
you
cannot
mention
other
users.
B
Another
thing
you
can
do
in
the
body
or
the
comment
you
anybody
who
has
submitted
a
comment
or
the
creator
of
the
epic
will
all
be
participants
and
they
will
automatically
get
notifications
of
changes.
You
can
also
subscribe
to
notifications
for
this
or
turn
off
notifications
for
this
one,
epic.
Similarly,
for
issues
and
merge
requests,
you
have
this
little
slider
there
as
well.
B
If
I
scroll
down,
I
get
a
view
of
all
of
the
sub
epics
and
issues
similar
to
that
group
view.
I
can
expand
these
out.
The
epics
are
represented
by
the
stack
of
papers
icon,
whereas
the
single
kind
of
single
sheet
of
paper
is
an
issue,
and
then,
within
this
I
can
see
a
lot
of
information
about
the
epic
number,
how
many
sub
epics
it
has.
How
many
issues
it
has.
B
You
can
also
mark
issues
as
on
track
or
at
risk
or
behind
schedule,
and
those
if
they're
marked
will
be
summarized
within
the
epic
view.
You
can
also
switch
to
a
road
map
view
to
see
all
of
the
sub
epics
represented
and
I'll
show
you
an
example
of
that
coming
up.
B
And
then,
if
you
scroll
down
even
further,
there
is
comments
section
where
you
can
create
additional
comments
or
have
nested
threaded
comments.
Where
you
can
reply
to
specific
comments
or
you
can
create
new
comment
threads
and
within
those
you
can
use
markdown
to
format
them
as
well
as
reference
other
issues,
other
epics
or
other
users,
and
so
on.
B
B
Remember
that
I'm
in
this
kevin
chassis
group
remember
issues
do
not
live
in
groups;
they
live
in
projects.
So
with
each
issue,
I
can
see
the
project
that
it's
a
member
of
as
well
as
the
issue
number
and
again
be
like
before
I
can
see
when
it
was
created,
by
whom
I
can
see
the
issue
weight
which
we'll
talk
about
in
a
minute,
but
that's
the
numeric
field
that
allows
you
to
kind
of
say
how
hard
you
think
the
issue
is
going
to
be.
B
I
can
see
all
the
labels
that
are
applied
to
it
as
well
as,
if
there's
any
time
estimates.
I
can
also
see
all
the
assignees
how
many
merge
requests,
how
many
thumbs
up
it's
received
and
how
many
comments
and
when
it
was
last
updated.
I
get
all
of
this
view.
B
You
can
also
do
bulk
updates
of
these
issues
directly
from
here
to
apply
labels
or
close
them
or
whatever
you
want
to
do,
and
you
can
also
create
new
issues
directly
from
here,
and
this
is
select
project
because
issues
live
in
projects.
So
when
you
create
an
issue
at
the
group
level,
you
need
to
know
which
project
you're,
creating
it
within.
B
This
is
an
example
of
a
filter,
so
you
can
see
here.
I
am
filtering
by
the
priority
critical
label
and
I'm
also
filtering
by
the
milestone
this
particular
milestone,
and
so
it
filters
this.
The
same
list
view
that
we
were
on
a
moment
ago
down
to
just
these
two,
which
both
have
the
critical
label
and
they're.
Both
part
of
the
pi1
milestones.
You
can
see
milestones
the
these
are
labels,
so
the
simple
labels
are
the
solid
ovals
like
bug.
B
The
priority.
Critical
and
workflow
testing
are
what
we
call
scoped
labels,
so
those
are
a
name
value
pair,
so
I
can
have
a
series
of
these
for
different
priorities
or
workflows,
but
you
can
only
apply
one
at
a
time,
and
so
this
is
a
nice
feature
that
you
can
have.
B
When
viewing
the
details
of
an
issue,
so
if
we
click
on
an
issue
viewing
the
details
of
the
issue
again,
just
like
with
the
epics
I
can
have
a
headline,
I
have
to
have
it
online
sorry,
and
I
can
have
a
description.
The
description
can
be
formatted
with
markdown
just
like
before.
B
You
can
also
see
linked
issues
and
related,
merge
requests
here.
Linked
issues
can
be
blocked
by
blocking
or
just
related
to,
and
the
merge
requests
show
you
the
different,
merge
requests
that
are
related
to
this
issue
that
were
created
off
of
this
issue,
because
you
can
have
more
than
one
on
the
right
hand.
Side
is
all
of
the
metadata
associated
with
this
issue,
so
I
can
see
who
the
assignees
are,
and,
yes,
you
can
have
more
than
one
assignee,
which
is
very
useful.
B
B
If
you're
using
the
time
tracking
feature,
you
can
also
see
the
estimates
and
how
much
time
has
been
spent.
You
can
assign
a
due
date.
You
can
see
all
the
labels
that
are
applied.
You
can
see
the
weight
again.
Weight
is
a
numeric
integer
field.
You
can
use
whatever
weighting
system.
You
want.
Some
people
use
the
fibonacci
sequence,
some
people
use,
but
if
you
use
things
like
t-shirt
sizes,
you
just
have
to
convert
that
to
a
number,
because
it's
going
to
be
used
to
add
up
on
boards
and
burn
downs.
B
So
it
has
to
be
a
number.
So
as
long
as
you
convert
whatever
system
you're
doing
into
numbers
and
at
gitlab,
we
don't
recommend
that
folks
use
those
to
you
know
to
represent
real
world
values
like
hours
or
days,
because
sometimes
I
can
set
unrealistic
expectations.
You
really
want
the
weights
to
simply
be
relatively
consistent
and
we
are
almost
through
and
I
will
be
taking
questions
here
in
a
moment.
So
just
give
me
a
moment
to
finish
a
couple
more
slides
and
then
we'll
go
to
some
questions.
B
You
can
also
mark
issues
as
confidential,
so
if
you
have
projects
that
are
either
open
to
the
public,
anybody
who
can
see
your
issue
or
open
to
everybody.
That
is
within
your
instance.
B
If
you
want
to
make
a
an
issue
only
viewable
by
the
people
who
are
members
of
your
project,
you
can
mark
it
as
confidential,
so
at
gitlab
we
use
these
for
maybe
a
security
vulnerability
that
we
found
that
needs
to
be
fixed
and
we
want
to
fix
it
before
making
that
public
or
even
other
internal
type
of
things.
Everything
else
in
gitlab,
though,
is
not
and
is
open
to
the
public,
to
see.
B
B
By
the
way
you
can
filter
on
the
emojis
that
you
have
applied
to
issues,
and
so
I
find
this
very
useful.
I
upvote
all
of
the
issues
that
I'm
following
for
my
customers
and
then
I
can
quickly
see
which
ones
are
going
to
be
included
in
a
specific
release
by
filtering
by
milestone
and
that
upvote
emoji
that
I
have
done
here.
You
can
see
some
of
the
discussions
and
I'll
show
you
an
example
coming
up
of
a
threaded
discussion,
which
is
right.
A
B
So
you
can
see
here
these
are
related
comments
that
are
threaded
and
that
you
can
collapse
those
you
can
also
see
an
example
of
the
related
issues
I
mentioned
here
earlier.
Another
best
practice
here
is
to
mention
users
you
want
to
involve
in
the
discussion.
You
also
see
examples
here
where
we've
referenced
a
milestone
or
another
issue,
which
is
very,
very
useful.
B
Here
is
an
example
of
a
board,
so
within
within
a
board.
This
is
a
way
to
visualize.
This
is
an
example
of
an
issue
board.
We
also
do
have
epic
boards
boards
are
very,
very
flexible.
You
can
have
multiple
boards
and
switch
between
them
or
create
new
ones
here
and
then,
within
the
board,
you
can
define
any
number
of
columns
you
want.
Columns
can
be
defined
based
on
labels.
As
you
see
here,
these
are
based
on
labels,
but
you
can
also
base
them
on
milestones,
iterations
people.
B
So
if
you're
doing
a
resource
planning
board,
you
can
actually
have
people
across
the
top.
All
of
the
open
issues
that
are
not
represented
by
one
of
the
columns
will
show
up
on
the
left.
All
of
the
closed
issues
which
you
can't
see
here
are
on
the
right
and
then
you
can
have
as
many
columns
as
you
want.
B
These
can
be
collapsed
to
simplify
things,
and
you
also
get
a
sum
of
the
total
number
of
issues
and
the
total
issue
weight
and
you
can
set
work
and
progress
limits
for
those
as
well,
and
you
can
also
group
these
by
to
create
horizontal
swim
lanes
based
on
the
epics.
Currently,
you
can
filter
the
board
just
like
the
issue
list,
and
you
can
also
edit
the
board
to
create
a
permanent
filter.
B
So
if
you
want
to
filter
it
for
a
given
milestone
or
even
a
given
iteration
or
a
given
user,
you
can
do
that
assigning
sorry,
you
can
do
that
and
then
by
simply,
each
of
these
cards
represents
an
issue
or
you
get
a
little
summary
of
the
issue.
You
can
drag
and
drop
these
and
it'll
automatically
apply
the
label
or
the
milestone
or
assign
it
to
the
individual
based
on
what
the
column
is
represented
by.
B
Here
is
an
example
of
a
merge
request.
So
when
I
talked
about
earlier,
merge
requests
again
have
the
ability
to
have
a
headline
and
a
description,
but
then
here's
all
the
really
really
cool
summary
information
that
you
get
within
a
merge
request.
So
it
shows
you
the
branch
and
where
it's
going
to
get
merged
into
you
can
click
these
to
open
that
branch
in
our
web
ide
or
you
can
click
here
to
get
the
commands
to
work
locally
or
even
download
that
branch
you
can
see
the
latest
pipeline
results.
B
B
And
then,
if
you
can
see
all
of
the
approvals,
you
actually
see
the
where
the
review,
if
it
was
deployed
to
a
review
app,
you
can
see
where
it
was
deployed
to
and
click
here
to
view
that
review
app.
You
can
also
see
all
of
the
security
results
and
code
quality
results
right
here.
You
can
see
the
summary
you
can
expand
these
to
see
what
changed
or
you
can
click
here
to
view
the
full
report,
and
then
you
can.
B
Ultimately,
this
merge
button
will
go
green
when
all
of
the
approvals
and
other
criteria
in
you
know
once
those
are
all
been
satisfied,
you
can
go
ahead
and
click
click.
The
merge
button
to
actually
merge
it
back
in
on
the
code
review
side.
B
This
is
just
showing
you
an
example
of
how
you
can
put
comments
associated
with
lines
of
code,
and
then
you
can
either
add
it
as
a
comment
or
you
can
hit
a
restart
a
review
and
you
can
add
additional
items
to
that
review
and
when
the
developer
gets
it
back,
they'll
kind
of
have
a
checklist
of
items
to
work
on,
and
they
can
they
can
then,
as
they
resolve
each
one.
It
will
show
them
how
much
progress
they've
made
towards
completing
that
code
review.
This
is
a
really
neat
way.
B
B
Okay
and
then
we
talked
about
gitlab
ci
cd,
so
I'm
not
going
to
go
into
a
ton
of
detail,
but
just
kind
of
give
you
an
overview
today,
but
basically,
what
is
cicd
again?
It's
continuous
integration
and
continuous
delivery,
slash
deployment.
B
It
allows
for
early
error
detection,
because
you
are
testing
your
code
every
time
you
have
reduced
integration
problems,
you
can
increase
speed
and
efficiency
and
deliver
value
more
quickly
to
your
customers
using
ci
cd.
It
also
encourages
collaboration
across
departments,
and
then
this
is
an
example
of
a
typical
cicd
pipeline.
Where
you
have
your
build
state,
these
are
stages
across
the
top.
B
Each
stage
can
contain
one
or
more
jobs.
These
each
of
these
represent
a
job.
You
get
a
status
of
the
job,
the
name
of
the
job
and
you
can
rerun
a
job.
Job
is
basically
what
actually
executes,
in
this
case
the
build
or
these
tests,
and
you
can
even
click
on
these
to
see
the
output
and
what
happened
and
look
at
the
output
as
if
you
were
watching
that
job
run
on
the
server
itself,
and
then
you
can
have
deployments
to
different
environments.
B
You
can
even
have
manual
jobs
that
are
initiated
manually
by
someone
with
permissions
and
then
they
automatically
will
deploy
and
do
all
the
other
pieces.
Well,
I'm
not
gonna
go
into
detail
on
that
today.
So,
but
this
is
just
a
quick
overview
of
ci
cd.
B
And
then
a
couple
more
and
we
will
open
up
to
questions.
So
if
you
do
have
questions,
please
get
them
in
the
q
a
and
then
so.
This
is
just
showing
you
an
example
of
the
labels.
When
you
go
to
the
labels
page
under
the
project,
information
or
subgroup
information,
you
can
see
a
list
of
all
the
labels
that
are
available.
You
can
you
can
see
where
those
labels
are
inherited
from.
You
can
filter
this,
so
here
I
filtered
it
just
to
see
the
priority
labels
here.
B
You
can
see
example
of
those
priority
labels,
and
these
are
those
scope
labels
I
mentioned,
that
are
a
name
value
pair.
So
these
are
all
the
same
category
of
priority,
but
they
have
different
values,
and
if
I
apply
one
of
these,
it
will,
if
one
was
already
applied,
it
will
automatically
remove
it
in
a
single
action
which
is
nice,
but
of
course
you
can
create
as
many
of
these
as
you
want,
and
you
can
view
quickly
all
of
the
issues-
murder,
question
ethics
that
are
have
this
label
on
them.
B
You
can
even
subscribe
to
a
label
which
is
very
useful
if
you
want
to
be
notified
of
any
issues
that
get
priority
critical
or
maybe
you're
a
security,
professional
and
anytime.
Something
gets
tagged
with
a
security
or
maybe
you're
a
tech
writer.
If
it
gets
the
documentation
label,
you
want
to
be
notified.
You
can
subscribe
to
these.
You
can
email
whenever
it
is
applied
to
an
object.
B
And
then
this
is
an
example
of
the
milestone
view.
Milestones
again,
have
a
start
and
end
date
that
you
set
manually.
They
can
have
a
name
which
can
be
a
version
release
or,
as
you
saw
earlier
program
increment,
they
can
be
whatever
you
want.
B
Just
be
plain
text,
but
here
you
can
get
a
quick
view
of
how
many
issues
and
merge
requests
are
available
in
the
milestone,
as
well
as
how
far
along
you
are,
and
you
click
these
to
drill
in
and
if
you
click
on
one
of
these
milestones,
you
can
get
in
to
a
burn
up
and
burn
down
chart,
and
I
am
sorry,
I'm
almost
complete
with
the
content.
So
I
will
take
be
taking
questions
in
a
moment.
B
Just
bear
with
me
one
more
moment
and
then
real,
quick,
some
navigation
tips
I
mentioned
on
the
left.
B
You
can
navigate,
but
I
also
wanted
to
highlight
re-highlight
the
re-highlight
the
breadcrumbs
here,
so
you
can
see
exactly
where
you
are,
and
the
other
thing
I
wanted
to
mention
is
every
time
you
click
on
one
of
these
things.
It
updates
not
only
the
breadcrumbs,
but
it
updates
the
url.
B
This
is
very
useful
because
if
you
get
a
specific
view,
even
if
you
apply
a
filter
to
a
view,
it
will
be
included
in
that
url,
which
means,
if
you
bookmark
it
or
if
you
share
it
with
a
colleague
via
email
or
matter,
most
or
slack
or
whatever
your
met
or
teams,
whatever
your
messaging
app
is
that
url
will
take
them
to
the
exact
same
view,
which
is
really
really
nice
and
useful.
B
So,
let's
use
those
breadcrumbs
when
you
have
a
lot
of
breadcrumbs,
there's
a
little
dot,
dot,
dot
or
ellipsis
button,
and
you
can
click
that
to
see
the
full
hierarchy
and
you
can
navigate
back
up
to
whatever
level
you
want
and
then,
when
you
click
on
one,
you
can
quickly
go
back
to
that
value
level.
By
the
way.
B
One
thing
I
wanted
to
show
you
here
was
that
this
is
an
example
of
those
subtasks
that
you
can
create
with
check
boxes
and
put
people's
names
next
to
them,
and
it
gives
you
a
summary
of
those
at
the
top
and
then
finally,
when
you're
back
at
that
group
project
level,
you
can.
I
just
wanted
to
show
you
an
example
of
creating
a
new
project.
When
you
create
a
new
project,
you
have
several
options.
You
can
create
a
blank
project.
You
can
create
it
from
a
template.
B
There's
built-in
templates
within
gitlab,
but
you
can
also
create
your
own
custom
templates
based
on
existing
projects.
You
can
also
import
it
or
simply
create
a
project.
That's
only
going
to
be
a
ci
cd
set
that
doesn't
have
any
other
code
built
into
it.
So
that
is
the
all
of
the
content
I
wanted
to
get
through.
A
Awesome,
thank
you,
kevin.
That
was
great
yeah,
so
I
just
opened
up
the
feedback
poll
we'd
love
to
hear
from
you
about
today's
session.
We
like
getting
feedback
and
like
making
these
as
valuable
as
possible
for
our
customers
that
are
attending.
So
thanks
for
for
giving
us
a
little
bit
of
feedback
and
with
that
I'll
I'll
pass
it
back
over
to
kevin.
To
answer
a
few
of
the
questions
that
have
come
through.
B
Great
yeah,
so
it
looks
like
my
colleagues
answered
a
couple
of
them,
but
let's
go
ahead
and
there's
one
here.
So
the
question
is:
is
everything
being
shown
available
both
in
gitlab
sas
and
get
lab
self-hosted?
We
have
self-hosted
and
want
to
make
sure
that
any
feature
only
available
in
sas
is
documented
someplace.
B
So,
yes,
everything
I
show
today
is
available
both
in
sas
and
self-manage.
So
there's
there's.
Probably
there
are
a
couple
things
that
I
think
are
only
available
in
self-managed
there's
a
few
things
that
are
only
available
sas.
Those
are
all
available
on
our
docs
page,
but
none
of
the
functionality
we
talked
about
today
is
only
one
or
the
other.
Everything
we
talked
about
today
is
available
in
both
now
there
are
a
couple
features
that
we
talked
about
today
that
are
only
available
in
ultimate.
B
So
if
you're
a
premium
customer,
there
may
be
a
couple
of
things
I
mentioned
today.
Some
of
our
security
scans
are
available
at
the
premium
level.
Some
are
not,
but
almost
everything
else
we
talked
about
today
was
available
is
available
to
to
no
matter
where
what
level
you're
on
of
a
premium
or
ultimate.
B
So
I
hope
that
answers
your
question
and
then
I
see
there
is
a
question
I
saw
raj,
you
raised
your
hand,
but
really
there's
there's
no
way
for
us
to
allow
you
to
come
off
mute
in
the
webinar
series
series.
Only
the
panelists
can
come
off
mute.
So
I
need
you
to
put
that
question
into
the
q
a
and
I'll
be
happy
to
address
it.
B
We
do
have
a
few
minutes
left
so,
while
I'm
waiting
for
you
to
answer
that
question
I'll,
take
the
next
question,
which
is:
can
we
use
gitlab
as
cicd
tool
to
deploy
application
binaries
onto
our
azure
kubernetes
service?
Yes,
definitely
so
we
have
a
lot
of
features
available
to
help
you
with
that,
especially
with
kubernetes,
and
we
are
cloud
agnostics.
B
So
we
support
aws,
we
support
gcp
and
we
support
azure
and-
and
you
can
definitely
connect
your
project
or
your
group
to
a
kubernetes
cluster,
and
then
you
can
use
git
lab
to
control
those
environments
and
deploy
to
those
environments
and
even
create
dynamic
environments.
You
can
actually
create
canary
blue
green.
You
could
deploy
out
to
a
percentage
of
the
pods
in
kubernetes
so
like
if
you
had
a
new
feature,
and
you
want
to
just
put
it
out
to
25
of
the
pods,
you
can
totally
do
that
as
well.
B
So
there's
a
lot
of
great.
What
you
would
want
to
do
is
look
at
our
docs
page
and
go
into
the
deployment
environments
and
there's
a
lot
of
great
information
available.
There.
B
Let's
see,
let
me
and
then
we
have
another
question,
any
helpful
documentation,
please
for
gitlab
csc
to
a
k
s,
integration
and
deployment.
B
But
yes,
generally
speaking,
a
good
tip
is,
if
you
simply
google
git
lab
and
then
whatever
the
term
is
you
one
of
the
first
results
is
going
to
be
the
link
to
our
docs
page
and
because
all
of
our
docs
are
open
to
the
public,
whether
you're,
a
customer
or
not.
You
should
be
able
to
find
those.
B
Let's
see
next
question,
I
know
from
my
company
that
you
also
use
commands
in
the
command
window
to
make
new
repositories.
Are
there
any
useful
documentaries
for
that?
So
I
think
what
you're
asking
is
about,
like
the
git
commands
themselves,
to
create
new
repositories
and-
and
things
like
that,
so
yes,
there
is
some
resources
available
on
git
lab,
but
because
the
underlying
technology
that
you
would
be
doing
at
the
command
line
for
those
types
of
actions
is
just
get.
B
What
you
can
do
is
simply
just
google
get
and
and
the
term
you're
looking
for-
and
there
are
a
lot
of
great
tutorials
out
there
available
on
lots
of
different
websites,
not
necessarily
just
on
gitlab.com
that
you
can
take
a
look
at
for
that.
B
And
then
the
next
question
is:
does
gitlab
support
sky
cd
for
auto,
assist
python,
sql
server,
stored
procedures,
ssis
and
ssrs?
B
I
so
the
way
to
get
left
ci
cd
works
is
basically
anything
you
can
do
via
the
command
line
or
you
can
do
in
gitlab
ci.
So
if
you
can
interact
with
those
via
the
command
line,
either
by
doing
a
curl
or
cli,
then
definitely
yes,
and
I
think
you
can
even
like
sql
server.
B
I
think,
has
it's
been
a
while,
since
I've
worked
with
it,
but
I'm
pretty
sure
it
has
the
ability
to
do
stuff
via
cli
as
well,
and
so
you
could
totally
do
those
there's,
probably
some
some
examples
and
tutorials
you
can
find
online
for
those.
But
that's
definitely
something
you
could
do
because
the
bottom
line
with
gitlab
ci
is
anything
you
can
do
via
the
command
line.
Anything
you
could
do.
B
If
you
were
sitting
in
front
of
the
server
you
can
do
via
gitlab
ci
or
do
within
a
container
if
you're
not
doing
it
on
a
vm
or
a
physical
server,
because
you
can
do
this
yeah
in
any
of
those
modes.
B
Let's
see
there
is
a
huge
next
question:
there's
a
huge
documentation
and
tutorial
videos,
but
I
would
like
to
get
learning
pathway
roadmap
for
sequential
learning
as
I'm
a
novice.
Yes,
okay,
so
there's
a
couple
different
resources
that
you
should
be
aware
of
for
additional
learning.
Obviously,
today's
webinar
just
kind
of
scratches
the
surface.
B
We
do
have
full
training
classes
available
with
professional
trainers
through
our
professional
services
offerings,
which
maybe
somebody
can
put
a
link
into
the
in
to
the
q
a
to
to
help
with
that.
But
there's
also,
if
you
go
to,
I
think
it's
gitlab.com
learn.
We
have
a
series
of
videos
and
other
resources
that
are
available
that
are
self-paced
and
I
believe,
there's
a.
B
I
is
escaping
me,
the
name
of
it
right
now,
but
I
believe
we
do
have
an
online
series
that
gitlab
has
put
together
that
go
through
a
series
of
through
one
of
the
learning
sites
and
I'm
I'm
sorry,
I'm
blanking
on
the
name
of
it
right
now.
But
if
one
of
my
colleagues
has
it,
we
can
get
that
out
to
you
or
we
can.
We
can
do
a
follow-up.
So,
okay,
one
of
of
my
colleagues
put
it
in
the
chat
great.
B
So
hopefully
you
all
could
see
that
because
I
think
I
think
we
can
put
that
out
server.
We
can
see
that
the
links
to
those
great
perfect
yeah,
so
there's
a
bunch
of
certifications
as
well
that
you
can
do
and
certification
programs
that
take
you
through.
All
of
that,
so
there's
a
lot
of
different
options
depending
on
whether
you
want
to
do
self-paced
or
if
you
wanted
to
pay
to
to
have
a
professional
come
and
do
either
remote
training
or
maybe
someday
soon.
B
In-Person
trainings
at
your
facility
is
an
option
that
we
do
have.
B
So
another
question
I
saw
was,
as
you
filter
and
search
issues
and
merge
requests
within
gitlab.
Is
it
safe
to
say
that
labels
are
one
of
the
main
methods
for
creating
effective
metadata
for
queries?
Yes,
labels
are
very
useful,
but
you
can
filter
and
search
based
on
other
things
like
milestone,
iteration,
author
assignee.
B
B
Well,
I
think
that's
it
we're
at
the
top
of
the
hour,
so
thank
you
so
much
for
attending.
Hopefully
you
got
a
lot
of
today's
session
and,
like
taylor
said,
the
recording
will
be
distributed
to
all
attendees
that
registered
as
well
as
those
that
attended
so.