►
From YouTube: Intro to GitLab - EMEA Webinar
Description
Are you new to GitLab? Watch this 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
All
right,
so,
let's
go
ahead
and
jump
in
my
name
is
Ricardo
I'm,
a
strategic
customer
success
manager
here
at
gitlab,
and
today
we'll
be
going
over
the
basics
of
git
love
in
the
security
webinar
before
we
do.
I
just
want
to
cover
that
this
webinar
is
being
recorded,
so
you'll
be
receiving
the
recording
the
next
day,
or
so.
Also,
if
you
have
any
questions,
please
feel
free
to
drop
them
at
the
in
the
Q.
A
section
of
the
webinar,
as
our
team
will
be
answering
them,
live
through
the
webinar.
A
The
recommended
gitlab
flow
will
also
be
covered
for
a
future
Branch
development
workflow
and
just
to
let
you
know
that
the
upcoming
webinars
that
we'll
be
presenting
in
the
future
include
an
introduction
to
CI
CD,
Advanced,
CI,
CD
and
devsecops,
and
compliance
one
and
those
will
be
a
great
follow-up
to
today's
session.
So
please
keep
your
eyes
out
for
the
webinars
calendar
in
which
you
can
find
links
to
register
for
these
webinars.
A
All
right
so
git
love,
git
love
is
the
first
and
only
true
devops
platform.
It's
a
single
application
with
one
user
interface,
a
unified
data
store
one
permission
model
and
security
embedded
within
the
devops
lifecycle.
A
With
this
in
a
single
application,
it
combines
the
ability
to
plan,
develop
secure
release
as
well
as
operate
and
monitor
software
within
a
single
application
that
is
easier
to
use
and
maintain
with
a
complete
visibility
and
traceability
across
the
devops
lifecycle,
with
gitlab
as
a
partner.
Every
team
in
your
organization
can
collaborate
in
a
single
solution
to
manage
the
end-to-end
development
life
cycle
and
thus
delivering
more
value,
faster,
increasing
visibility,
quality
and
security,
while
remove
contact,
switching
and
non-value
generating
tasks.
A
So
you
might
ask:
why
are
so
many
organizations
using
gitlab
for
and
what
is
the
problem
that
this
is
solving?
We
are
helping
teams
move
from
sequential
devops
to
concurrent
devsecops.
A
The
reality
is
that,
even
though
some
or
all
teams
made
up
devops
their
tools,
the
processes
and
even
the
culture,
they
often
optimize
locally,
but
still
work,
sequentially
ending
work
from
one
team
to
another,
and
the
consequence
is
that
it
limits
organizations
from
truly
realizing
the
value
of
devops,
where
teams
need
to
work
together
and
have
a
single
conversation,
starting
from
idea
to
production
around
smaller
deliverables
in
traditional
sequential
devops
approach.
Each
function
is
running
in
silos
using
their
own
tools.
They
may
be
locally
optimized,
but
that
creates
a
lot
of
end-off
tool.
A
Friction
as
every
teams
is
ending
over
to
the
next
one.
A
However,
as
organizations
are
wanting
a
way
to
move
faster
and
more
efficiently,
they
are
adopting
gitlab,
concurrent
websackops
module,
and
this
approach
offers
a
way
to
get
teams
to
work
together
at
the
same
time
and
collaborate
in
a
single
pane
of
class,
so
so
to
speak,
to
design,
build
tests
deliver
and
even
monetary
code
changes.
The
teams
must
work
concurrently,
not
sequentially
on
the
product
or
service
there
will
be
delivering
to
the
customer
and,
at
the
same
time,
by
moving
security.
A
Now
that
I've,
given
you
an
overview
of
gitlab,
it's
time
to
dig
right
into
our
recommended
workflow
across
all
the
stages
in
gitlab
and
as
you
can
see
in
this
infographic,
there
are
many
steps
to
get
from
an
idea
to
a
solution
deployed
to
production.
A
So
as
you
organize
your
work
all
the
way
from
an
epic
to
Milestone
and
all
the
way
down
to
an
issue
and
assign
that
issue
to
a
developer,
they
will
start
their
work
on
a
new
feature
branch
and
the
idea
is
that
all
the
work
is
being
done
currently
and
typically,
there
are
multiple
feature
branches
going
through
these
automated
build
and
test
process,
as
well
as
security
scans.
That
will
then
later
be
merged
into
the
main
branch.
There
are
a
few
components
that
will
not
be
covering
here,
such
as
the
review
app.
A
So
if
you
are
interested
in
that,
you'll
talk
about
it
in
the
intro
to
CI,
CD
and
also
the
advanced
CI
CD
and
while
git
allows
a
wide
variety
of
branching
strategies
and
workflows.
A
What
we
we
often
see
is
that,
because
of
this,
many
organizations
end
up
with
workflows
that
are
too
complicated,
not
really
clearly
defined
and
not
integrated
with
issue
tracking
systems,
and
therefore
we
propose
gitlab
flow
was
a
clearly
defined
set
of
best
practices,
as
it
combines
future
driven
development
and
feature
branches
with
issue
tracking
the
gitlab
flow
is
a
clearly
defined
set
of
best
practices.
So
with
this,
we
get
a
simplified
branching
strategy.
All
features
and
fixes
first
go
to
main
allows
for
production
or
stable
branches
as
well,
and
bug
fixes
or
odd.
A
Fixed
patches
are
cherry
Pickett
from
Maine,
and
we
recommend
for
devops
team
to
follow
the
gitlab
flow
process,
while
using
gitlab
capabilities
within
a
concurrent
event,
life
cycle
again,
the
gitlab
application
is
based
around
the
future
range
based
workflow.
So,
with
this,
all
developers
will
work
in
a
single
project
and
create
a
feature
branch
in
that
same
project.
The
merge
request
is
the
core
and
primary
collaboration
tool
for
of
the
products.
A
The
green
line
at
the
bottom
of
the
slide
shows
the
main
branch
notice,
another
green
line
that
breaks
off
the
main
branch
and
eventually
ties
back
to
domain,
and
this
is
what's
known
as
a
feature
Branch.
The
featured
Branch
represents
the
source
code
pattern
where
a
developer
opens
a
branch
and
begins
working
on
new
feature
and
that
work
is
soon
integrated
into
the
main
branch
again
We
Begin
this
whole
process
by
creating
a
discrete
unit
of
work
while
creating
an
issue
think
it
off
as
a
ticket,
and
we
assign
the
issue
to
a
team.
A
Member
from
the
issue.
We
spawn
a
feature
Branch
think
it
off
as
a
parallel
line
of
development
and
developers
move
to
a
branch
to
interact
with
the
with
a
request.
Gitlab
provides
updates
and
notifications
on
the
state
of
your
issue
automatically.
So
if
you
work
with
a
featured
wrench
for
more
than
a
few
hours,
it's
a
best
practice
to
share
the
result
with
your
immediate
team
and
it
might
not
be
ready
to
be
merged
yet,
but
feedback
should
be
welcomed.
So
your
team
can
make
comments
on
the
merge
requests
in
general
or
on
specific
lines.
A
The
the
merge
request
serves
as
the
code
review
tool
and
no
separate
tool
should
be
needed.
So
when
you
are
comfortable
with
your
work
and
the
comments
made,
you
can
assign
it
to
someone
who
knows
the
most
about
the
code
base
or
someone
that
has
permission
to
merge
it
back
to
the
main
branch,
and
we
also
have
code
review
and
conflict
resolution
built
into
the
platform
for
merge
conflicts.
A
So
the
comment
here
kicks
an
automated
continuous
integration
pipeline
that
runs
and
goes
through
the
steps
to
the
right
of
the
slide,
and
the
advantage
is
that
developers
have
visibility
into
what
is
going
on
on
the
cycle.
A
So
now
we'll
be
talking
a
little
bit
about
the
gitlab
terminology
and
some
components
that
we'll
be
referring
throughout
the
course
so
become
more
familiar
with
them
as
well,
and
the
gitlab
use
terminology
for
its
components.
That
is
a
little
bit
different
from
other
systems
that
you
might
have
used.
So
let
me
go
through
them.
A
First,
we
have
the
project
and
the
the
project
is
the
core
building
block,
where
the
work
is
organized,
managed
tracked
and
delivered
to
help
the
team
to
collaborate
and
plan
work
in
the
form
of
issues.
So
whenever
you
are
starting
a
new
project,
you
can
think
about
creating
when
you're,
whenever
you
are
creating
a
new
product
or
you
want
to
define
a
project
as
a
single
product
within
your
company
and
then
the
group
is
its
collection
of
projects
or
subgroups.
A
You
can
think
about
them
as
if
they
were
folders,
so
you
can
compile
multiple
projects
on
business
units
or
you
can
also
have
people
groups
and
assign
those
groups
to
specific
projects,
and
this
is
super
useful
if
you
want
to
manage
access
that
way.
A
If
you
work
within
a
specific
Squad
with
a
set
of
front-end
back-end
engineers
and
project
managers,
you
can
assign
those
squads
to
a
specific
project
by
creating
a
people
group
with
that
specific
set
of
people
there
and
we'll
be
discussing
these
a
little
bit
more
in
detail
on
the
next
slide
as
well.
The
issue
that
I
previously
mentioned
is
a
part
of
a
project,
and
it's
the
the
fundamental
unit
or
the
fundamental
planning
objects
where
the
team
is
documenting.
The
use
case
in
the
description
discusses
the
approach,
estimates
the
size
and
effort.
A
You
can
also
track
the
actual
time
and
effort
there,
and
this
is
where
also
you
assign
work
and
track
its
progress
on
other
users.
You
other
projects
or
products
is
also
known
as
story
or
narrative.
The
Epic
is
a
collection
of
related
issues
across
different
groups
and
projects
to
help
organize
all
these
issues.
By
a
specific
theme,
then,
we
also
have
the
merge
request,
which,
on
other
systems,
might
be
also
known
as
pull
requests,
and
the
merch
request
is
essentially
the
linkage
between
the
issue
and
the
actual
code
changes.
A
This
is
where
you
capture
the
design.
The
implementation,
details
and
specific
code
changes
that
the
team
discusses
and
reviews
code
and
approaches
that
are
being
taken
there.
It
might
also
require
approvals,
for
example,
if
you
want
to
wait
for
someone
with
more
Authority
or
more
experience
within
that
specific
part
of
the
project,
to
approve
your
change
and
then
there's
also
a
compilation
of
the
testing
results
after
the
CI
pipeline
is
run,
and
you
can
also
see
there.
A
The
results
of
the
security
scams,
whether
the
merge
request
that
you,
this
developer
is
doing,
is
introducing
new
vulnerabilities
or
not,
and
you
might
want
to
take
some
action
and
fix
those
vulnerabilities
first,
then,
the
label
is
used
to
tag
and
track
work
for
a
project
or
group
and
Associate
issues
with
different
initiatives.
A
So
if
you
have
a
specific
due
date
or
a
specific
OCR
that
you
want
to
put
all
those
issues
together,
you
can
use
a
label
to
tag
that
specific
work,
and
then
this
will
be
very
valuable
if
you
want
to
create
visual
listings
for
issues
with
a
specific
label
on
a
board,
which
is
the
next
item
that
we
have
there.
This
might
be
super
relevant
as
well.
A
So
then
the
board
will
be
the
visual
listing
of
projects
and
issues,
and
those
are
very
useful
for
teams
to
manage
their
backlog
of
work.
This
is
where
they,
they
prioritize
items
and
move
issues
to
their
team
or
specific
stage
in
the
projects.
A
The
Milestone,
which
is
also
known
as
release
or
Sprint,
is
a
Sprint
of
deliverables,
and
that
helps
you
to
organize
the
code
issues
and
merge
requests
into
a
cohesive
group,
and,
last
but
not
least,
the
roadmap
is
then
the
visual
representation
of
the
various
epics
for
the
group.
A
Now
that
we
know
all
these
terminologies,
let's
talk
also
about
the
gitlab
hierarchy
and
how
these
all
comes
together.
So
this
is
super
important
whenever
you
are
setting
up
your
gitlab
infrastructure
coming
up
with,
with
a
with
some
good
practices
for
the
groups
and
subgroups
in
how
you
organize
things
is
super
important
because
of
the
permissions,
which
is
the
first
thing
that
I
want
to
talk
about
so
at
gitlab.
Essentially,
the
permissions
are
narrated
down
from
the
top
level
groups.
A
So
add
users
with
the
list
permission
there
and
give
them
higher
permissions
at
the
soup
group
or
project
level.
A
Also,
it's
relevant
to
know
that
labels
in
Milestones,
created
at
the
top
level
group,
are
available
to
all
subgroups
and
projects,
so
add,
share
labels
at
the
highest
level
possible
so
that
people
can
reuse
them
instead
of
creating
their
own.
This
will
be
also
relevant
whenever
you
are
tracking
issues.
A
So
a
typical
typical
use
case
that
we
are
representing
here
is
where
you
have
a
top
level.
Group
typically
could
be
the
name
of
the
organization,
and
then
you
have
let's
say
one
my
main
project
directly
from
the
top
level
group
with
different
issues
and
each
issue
then
we'll
have
comments,
participants
and
assignments,
and
then
you
might
also
have
a
different
subgroup.
Let's
say
a
different
division
within
the
organization
that
also
has
multiple
projects
and
again
these
projects
will
have
their
own
issues
as
well.
So
this
is
just
a
representation.
A
We
might
have
some
more
examples
on
that
documentation
and
feel
free
to
ask
questions.
But
we
are
just
representing
one
use
case
here,
hopefully
to
make
all
these
terminal
terminologies
make
making
sense.
A
Cool
so
let's
also
discuss
a
gitlab
workflow
example.
So
let's
take
the
example
of
creating
And
discussing
within
a
new
issue.
So
the
way
it
goes
and
the
way
we
should
start
is
by
having
a
team
member
creating
an
issue
inside
a
gitlab
for
a
new
feature,
they'll
be
implementing
the
team
member
applies
the
label
discussion
to
the
issue.
Various
team
members
might
also
discuss
the
new
feature
by
entering
comments
into
the
issue.
A
A
The
Second
Step
will
be
the
code
creation,
so
let's
say
this
will
would
be
some
work
for
the
back
end
team.
The
back-end
team
will
start
working
on
the
issue
and
changes
the
label
to
backend
to
reflect
the
status.
The
assign
a
developer
starts.
Writing
the
code
and
assigns
the
issue
to
themselves,
and
change
is
also
the
label
to
working
on
to
give
some
information
to
the
team
that
the
app
started
working
on
it.
A
After
some
work
is
done,
they
commit
and
create
a
merge
requests.
So
the
flow
here
is
the
developer.
First
creates
the
commit
the
developer
pushed
their
comment
to
a
feature
branch.
The
developer
will
then
create
a
merge
request.
That
is
basically
asking
requests
to
merge
that
piece
of
code
that
I
just
created
into
the
main
branch
and
then
also
the
backend,
will
remove
the
back
end
label
and
working
on
labels,
and
that's
just
the
front
end
to
make
sure
that
the
front-end
team
can
now
follow
that
up
that
work.
A
That
is
started
then,
if
everything
goes,
are
well
you'll
then
deploy
to
staging.
So
the
front-end
developer
starts
working
on
the
issue,
adding
the
label
working
on
and
assign
the
issue
to
themselves.
After
the
code
review
is
completed,
the
code
is
deployed
to
staging
and
the
team
removes
the
label
and
at
staging
label.
After
some
successful
implementation
in
staging
the
team
removes
the
staging
label
and
finally,
adds
label
ready
what
ready
means
it
might
be
different
from
company
to
company.
A
In
this
example,
it
means
that
other
teams
will
prepare
the
technical
documentation,
a
marketing
campaign,
for
example,
and
each
will
be
adding
their
label,
their
labels,
docs
and
marketing,
as
each
team
is
done,
they
remove
their
labels.
The
last
team
done
removes
the
ready
label
and
that's
the
production
label,
which
means
that
everything
was
done
and
this
initial
issue
and
change
is
now
ready
to
go
to
production.
A
So
the
release
team
member
merges
the
the
merge
request
and
the
feature
is
deployed
to
the
production
environment
and,
finally,
the
release
team
member
closes
the
issue.
A
So
here
you
can
see
we
are
in
the
top
level
group
and
you
can
see
all
of
the
two
groups
and
projects
underneath
this
group
s
apps,
the
three
dots
icon
wears
projects
have
the
book
item
so
on
the
left.
You
can
see
all
areas
that
you
can
navigate
to
within
this
group.
A
So
we
click
there,
and
here
are
the
list
of
all
the
epics
within
the
group.
Reminder
that
an
epic
is
a
collection
of
related
issues
across
different
groups
and
projects
to
help
organize
by
theme.
The
example
that
we
are
doing
here
is
just
searching
for
epics,
using
keywords
or
by
filtering
by
a
label.
In
this
example,
we
are
searching
for
all
non-confidential
items
with
the
label
priority
three.
A
An
epic
as
a
title
headline
in
the
body
description
and
you
can
set
a
manual
starting
net
or
end
dates
or
inherit
from
issues
from
within
the
Epic.
And
you
can
also
apply
labels
to
the
Epic
here
directly.
As
we
previously
done
and
saw
on
the
issue.
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,
independent
tracking
with
child
epics
and
issues.
These
are
all
Jericho
and
dynamic,
and
you
can
click
to
expand.
This
hypics
are
designated
by
the
stack
of
papers
and
issues
are
designated
by
a
single
sheet
of
paper
icon.
A
Some
of
these
some
of
these
features
might
only
be
available
on
ultimates,
so,
while
shell
epics
are
only
available
in
Ultimate,
if
you
are
a
premium
customer,
then
you'll
only
be
able
to
see
issues
that
are
linked
to
the
Epic
and
also
the
elf
status
here
that
we
see
the
green,
yellow
and
red
numbers
are
essentially
representations
of
how
many
issues
are
on
track
and
need
attention
or
are
at
risk
within
that
specific
Epic.
A
So
this
is
a
list
of
all
the
issues
within
the
group.
Although
issues
belong
to
individual
projects,
this
view
shows
all
the
issues
in
in
all
of
the
projects
under
this
group
and
similar
to
The
Epic
view.
A
This
list
can
be
filtered
by
a
keyword
or
by
relevant
metadata,
such
as
author
assignee,
Milestone
label
Etc,
and
you
can
see
this
information
about
each
issue
in
the
list
view,
including
labels,
assignees,
weight,
Associated,
merge,
requests,
comments
and
more
and
labels
are
in
different
infinitely
flexible
and
can
be
used
to
identify
the
type
of
issues,
so
you
can
just
use
type
and
and
then
double
dots
bug
the
priority
of
the
issue
with
a
priority
and
double
dots2
the
product
grouping
for
distribution.
If
it
is
related
to
your
user
experience,
you
can
put
ux.
A
A
As
you
add,
additional
search
parameters
or
adjusts
the
Sorting,
the
URL
in
your
browser
will
be
updated
with
the
appropriate
query
string
parameters.
So
you
can
save
the
exact
same
query
and
sorting
by
bookmarking
the
page
or
maybe
share
with
someone
else
by
copy
pasting
into
a
slack
message,
email
or
a
gitlab
issue,
for
example,.
A
This
shows
the
details
of
a
given
issue
with
the
title
and
description
as
well
as
metadata
on
the
right
right
above
the
title.
You
have
the
status
open
or
close
when
the
issue
was
created,
you
can
over
to
see
the
exact
date
and
time
and
the
original
author
of
the
issue
with
their
role
in
the
project
as
well.
A
So
there's
a
few
things
here
in
this
highlighted
area
that
you
can
see.
So
you
have
the
assignees
epics
that
this
issue,
the
Epic
that
is
issue-
belongs
to
the
labels
that
we
put
there
Milestone
issue
the
iteration
issue
and
also
the
issue
8,
which
is
an
integer
used
to
show
related
difficulty.
So
what
happens
is
after
an
issue?
We
has
been
assigned
a
weight.
A
You
can
see
this
added
up
for
issues
in
a
list
or
issue
board
or
on
a
milestone
page
as
the
total
sum
of
issue
Eights.
These
are
all
positive
numbers
and
common
patterns
to
assign
here
are
the
final,
Fibonacci,
Sequence
or
World
numbers
aligning
two
t-shirt
sizes
as
well.
A
You
can
also
have
here
the
due
dates.
You
have
an
option
also
for
the
time
tracking,
where
people
will
be
able
to
see
the
estimated
time
needed
to
complete
the
issue
and
how
much
time
they
have
spent
so
far,
and
then
the
health
status
as
I
mentioned
before,
is
this
ultimate
feature
that
helps
you
to
reference
this
issue
as
on
track
requiring
attention
or
at
risk.
A
So
if
we
scroll
down
on
these
issue,
you'll
see
the
associated,
merge,
requests
and
related
issues
and
discussions,
you
can
have
threaded
conversations
and
you
can
mention
someone
on
other
users
to
bring
their
attention
or
request
their
action
on
a
specific
issue.
Each
issue
or
comment
can
be
reacted
via
an
emoji
as
well.
You
use
this
all
the
time
at
gitlab
to
track
support
from
team
members,
community
members
and
our
customers
on
issues
that
have
the
most
upvotes.
So
we
typically
use
the
thumbs
up
to
help
influence
our
product
priority
prioritization
as
well.
A
So
here
is
basically
an
issue,
an
example
on
a
group
discussion,
so
on
on
the
on
the
left
side,
we
are
seeing
the
related
issues,
the
issues
that
are
blocking
the
current
issue,
related
merge,
requests
and
then
some
links
which
are
clickable.
So
all
these
items
will
be
referencing
to
the
specific
issue
that
is
related
or
being
blocked,
and
on
the
right
side
we
have
just
so
more
visibility
on
the
discussion
area.
So
this
is
where
all
the
comments
will
be
made
on
the
issues.
A
This
is
where
you
can
have
conversations
that
relate
to
the
work
that
you
are
doing
to
achieve
to
achieve
this
common
goal.
This
is
where
you
can
also
mention
other
team
members,
and
those
will
generate
notifications
for
those
members
when
their
attention
is
needed.
A
So
the
most
common
alert
here
is
sending
an
email
in
the
also
note
that
Ali
mail
sends
from
the
system
will
have
a
classification
Banner
on
emails.
If
that
is
desired,.
A
Boards
and
that
we
previously
talked
about
give
the
ability
to
visualize
and
organize
these
the
the
issues
the
boards
can
be
filtered
similar
to
the
issue
list,
so
you
can
have
columns
in
the
board
based
on
the
label,
Milestone,
assignee
and
more.
You
can
have
multiple
boards
as
well
and
switch
between
them
easily,
and
this
board
is
at
the
group
level
and
shows
the
issues
of
all
projects.
Underneath
this
group.
A
Then
merge
requests
so
with
the
merge
requests
you
can
get
a
complete
view
of
all
aspects
of
the
change
being
made
to
the
code
base.
You
can
see
that
the
latest
pipeline
progress
you
can
see
you
can
review
and
approve
the
changes
as
well
and
you
can
review
the
security
scan
results
in
all
in
one
place.
Additionally,
gitlab
makes
it
easy
to
start
and
track
progress
of
a
code
review.
You
can
add
General
comments
to
start
a
review
or
you
can
tag
individual
lines
of
code
with
a
specific
comments.
A
So
gitlab
cicd
and
what
you
are
looking
here,
is
a
full
pipeline
graph
of
all
the
jobs
in
a
gitlab
cicd
pipeline.
So
there's
a
few
things
on
the
terminology
as
well.
That
I
want
to
make
sure
we
are
on
the
same
line.
So
when
I'm,
referring
to
CI
CD
I,
mean
continuous
integration
and
continuous
delivery
or
deployment.
A
This
is
the
the
piece
from
gitlab
that
allows
for
built-in
automated
tests
to
be
run
on
the
code,
as
you
make
changes,
and
this
part
of
gitlab
encouraged
collaboration
across
all
departments
and
makes
code
Creation
in
management
easy
as
well
as
it
provides
the
following
specific
benefits.
So
first
yearly
error
detection.
A
So
the
group
levels,
this
view
shows
the
the
labels
at
the
group
level
and
those
can
be
filtered
by
a
keyword
to
find
the
relevant
labels.
This
is
showing
all
the
priority
labels
in
this
group,
and
these
are
using
a
scope
level
feature
for
that
lets.
You
create
a
name
value
pair
for
labels,
so
only
one
of
each
category
can
be
applied
at
the
time.
A
When
talking
about
group
Milestones,
these
are
a
way
to
group
issues
and
merge
requests
together
in
a
block
of
time.
Milestones
have
a
definite
start
and
end
date
and
can
include
any
number
of
issues
and
merge
requests
as
you
want
here.
We
are,
we
all
see
the
milestones
for
this
group
and
any
Milestones
created
for
projects
in
the
group.
You
can
get
a
summary
view
of
the
number
of
issues
and
merge
requests
in
in
the
Milestone
and
how
far
along
it
is.
A
Some
navigation
tips
so
there's
a
lot
of
ways
to
navigate
in
gitlab
on
the
left.
You
can
easily
switch
to
view
different
types
of
data
within
the
group
or
project
you
are
currently
viewing
at
the
top
here
Center.
You
have
breadcrumbs
that
show
you
where
you
are
in
the
project
hierarchy
and
at
the
very
top
you
can
see
whatever
you
change
views
in
the
gitlab,
the
URL
will
also
change.
So
remember
that
example,
whenever
you
were
filtering
a
board
with
multiple
filters
or
labels
there.
A
And
here
we
are
using
the
breadcrumbs
to
navigate
back
up
to
the
top
level
group.
So
just
a
quick
example:
there.
A
A
So
let's
talk
a
little
bit
about
the
Professional
Services
as
well,
and
how
can
you
improve
the
knowledge,
as
this
is
just
the
first
introduction
to
git
lab?
There's
a
lot
more
and
we
cannot
cover
everything
within
the
hour.
So
we
have
several
trainings
to
offer
teams
getting
started
with
gitlab
age
training
allows
up
to
12
students
from
your
organization
and
to
see
the
current
pricing.
Please
visit
our
catalog
page
link
it
here,
which
you'll
be
also
be
sent
after
the
webinar.
A
So
we
have
trainings
that
include
the
gitlab
with
Git
basic
training,
and
this
one
covers
what
gitlab
does
why
devops
teams
use
it
and
how
it
works
with
Git.
It
also
covers
some
key
processes
and
tasks.
A
A
We
also
have
a
gitlab
for
project
managers,
training
which
covers
how
to
set
up
projects
by
creating
issues.
Labels
milestones
in
groups,
approaches
for
managing
projects
using
gitlab
boards,
epics
and
roadmaps.
How
to
report
on
those
as
well
and
some
best
practices
for
using
gitlab
to
develop
portfolio
plans?
Then
we
also
have
the
gitlab
devops
fund.
Dimensions
training,
which
is
the
most
comprehensive
of
these
three,
covers
all
key
features
and
capabilities
for
each
stage
in
the
gitlab
devops
lifecycle
throughout
the
four
courses,
and
then
we
also
have
the
migration
plus.
A
So
if
you
need
training
and
migration
assistant,
the
migration
Plus
Package
provides
source
code
migration
from
a
single
Source
system
and
adds
three
standard
Education
Services,
to
help
users
and
administrators
to
level
up
quickly
on
gitlab.
So
you
may
consider
a
professional
services-led
migration
if
you
are
moving
100s
or
thousands
of
repos
into
gitlab
and
or
if
you
are
moving
from
a
self-managed
instance
to
a
SAS
offering
by
maintaining
data
Integrity.
We
can
share
additional
benefits
documented
in
our
end
book
and
in
our
congregate,
open
source
migration
tool,
documentation.
A
So
now,
we'll
jump
just
to
the
Q,
a
section
I'll
be
answering
some
of
the
questions
that
were
not
answered
so
far
in
the
chat,
if
not
I'll,
just
stop
the
recording
and
end
up
the
webinar.