►
From YouTube: Webinar - Intro to GitLab
Description
Learn more about GitLab and how to get started quickly and successfully.
A
B
A
A
A
We've
got
a
couple
folks
here
to
help
answer,
questions
and
drive
drive
the
primary
focus
of
the
webinar
so
leading
the
webinar
today
will
be
kevin
chassis,
our
staff
technical
account
manager
on
the
public
sector
team.
We've
also
got
chloe,
whitestone
manager
of
commercial
technical
account
managers
as
well
as
brian
cappini,
a
technical
account
manager
here
at
get
lab
kevin
I'll.
Kick
it
over
to
you
this.
The
focus
of
this
webinar
is
for
new
customers
getting
introduced
to
gitlab
for
the
first
time.
A
This
will
help
get
you
oriented
to
the
structure
of
git
lab
the
devops
process
and
how
git
lab
supports
the
entire
software
development
life
cycle
and
things
that
we
find
that
teams
need
to
know
to
quickly
get
oriented
and
be
able
to
collaborate,
work
together
and
get
their
projects
up
and
running
in
gitlab.
So
without
further
ado,
I
see
we've
got
most
folks
in
the
webinar.
This
is
being
recorded,
we'll
provide
a
link
afterwards.
There
will
be
a
short
q
and
a
as
well
and
so
without
without
any
further
delay
kevin.
Take
it
away.
C
C
So
the
first
thing
we
added
was
actually
ci
cd
and
at
the
time
there
was
some
debate
about
whether
to
add
that
as
a
separate
application
or
include
it
in
with
the
git
repository
manager
and
one
engineer
argued
very
vehemently
that
it
should
be
together
and
luckily
won.
That
argument,
because
now
we've
got
a
single
application
in
gitlab
that
covers
the
entire
devops
life
cycle.
C
C
But
you
can
also
do
things
like
issue
tracking,
wiki
and
you'll
see
a
whole
bunch
of
other
features
that
are
covered
within
gitlab
and,
of
course,
we're
still
open
source
today
and
we've
got
thousands
of
contributors
that
contribute,
as
well
as
our
engineering
team,
adding
features.
We
do
a
monthly
release.
We've
had
over
100
releases
consecutively
on
our
hitting
our
monthly
release
on
the
22nd
of
the
month,
and
so
there's
always
lots
of
great
features
being
added
to
gitlab.
C
But
gitlab
is
optimized
and
has
been
designed
and
we're
gonna
talk
about
some
of
the
best
practices
today
so
that
you
can
get
the
most
out
of
your
investment
in
gitlab,
and
so
the
idea
here
is
older
systems
or
sequential
systems,
or
you
might
have
completely
separate
teams
for
development
security
operations
and
so
on
it.
The
there's,
there's
issues
with
that
paradigm
right:
it's
it's
opaque,
inefficient
teams
tend
to
work
in
silos.
There's
handoff
friction
there
can
be
finger
pointing.
C
I
know
it
at
places
that
I've
worked
in
the
past
that
had
that
kind
of
mindset.
It
was
difficult
you
weren't,
trying
to
succeed.
You
were
trying
not
to
fail
and
be
the
one
who
was
blamed
as
opposed
to
trying
to
work
together
as
a
team
and
succeed
on
delivering
what
your
your
goal
was
to
deliver
with
your
software
package,
so
get
lab
does
help
you
to
transform
into
the
concurrent
devsecops
model.
C
You
know
gitlab
uses
gitlab
to
develop
your
lab,
and
so
we
have
built
in
a
lot
of
those
best
practices
into
the
tool
because
we
actually
use
it
and
use
all
aspects
of
it
not
just
for
development
but
for
other
aspects
of
the
business.
So
it
allows
you
to
work
together.
Everything
is
visible
across
all
of
the
teams.
C
It
allows
for
seamless
collaboration,
efficiency,
allows
people
to
take
action
and
provide
full
accountability
for
the
for
the
team,
so
that
the
entire
team
is
working
together
towards
a
single
goal
and
and
then
they're
really
focused
on
success
as
opposed
to
avoiding
failure.
So
a
lot
of
benefits
and
you'll
see
some
pieces
of
that
as
we
go
through
the
basics
of
the
application
here.
Coming
up.
C
So
one
of
the
things
that
so
there's
a
number
of
different
stages
that
have
been
defined
by
gartner
for
the
dev
ops,
life
cycle
and
we've
kind
of
visualized
them
here
as
kind
of
a
a
loop
that
is
kind
of
a
continuous
process
right.
So
this
is
kind
of
you
know
the,
not
the
opposite,
but
it's
much
different
from
waterfall
or
other
systems
that
you
might
have
used
in
the
past.
And
the
idea
here
is
that-
and
you
can
do
all
of
this
within
gitlab.
C
So
you've
got
issues
that
you're.
You
can
plan
plan
your
work
within
gitlab
on
what
you're
gonna
have
coming
up.
You
can
actually
use,
of
course,
gitlab
for
doing
your
coding
and
code
versioning,
but
you
can
also
use
gitlab
to
do
your
verification,
which
is
your
your
ci
for
continuous
integration
and
testing
automated
testing,
as
well
as
using
gitlab
to
package
and
even
release
gitlab
into
gitlab
gitlab,
real
sorry,
release
into
gitlab
controlled
environments,
which
can
be
configured
and
even
monitored
by
gitlab.
C
And,
of
course,
with
all
of
that,
you
have
tools
to
manage,
provide
security
and
even
defense
of
those
deployed
applications,
and
so
the
idea
is
that
you're
doing
this
continuous
loop
as
new
features
or
things
that
you
want
to
change
come
in,
and
you
can
do
this
in
small
chunks,
quickly,
rapidly
iterating
to
provide
solutions
and
continuous
value
to
your
customers,
to
your
stakeholders.
Whoever
it
is
that
you
were
developing
software
for.
C
And
then
one
other
view
of
these
10
stages
as
defined
by
gartner.
So
these
these
we
adopted
what
gartner
had
come
up
with
for
the
the
10
stages
of
the
dev.
Sockops
lifecycle
and
gitlab
has
an
offering
a
solution
for
all
10
stages
in
a
single
application,
where
you
can
have
a
single
data
model,
single
permission,
single
user
interface
and
a
single
place
for
your
team
to
collaborate,
view
analytics
governance
and
security
and
and
there's
a
significant
advantage
to
having
everything
in
one
place.
C
Now,
that's
not
to
say
if
you
have
some
tools
that
you're
using
today
that
you
really
want
to
continue
using
or
you're
required
to
continue
to
use
for
various
reasons
that
you
can't
use
them
in
place
of
gitlab,
because
gitlab
has
a
lot
of
great
integrations
into
some
of
those
other
tools
and
we
play
nice
with
a
lot
of
other
tools.
But
you
can
do
the
entire
life
cycle
in
the
single
application
of
gitlab.
C
So
this
is
a
diagram
that
kind
of
shows
you
the
get
lab
recommended
process,
and
this
is
definitely
what
we
would
consider
to
be
a
best
practice
for
use
of
git
lab
and
let
me
just
take
a
moment
to
walk
you
through
what
this
is
and
what
it
means
and
highlight
a
few
things
as
we
go
through
it.
So,
if
you
imagine
that
this
bottom
line
here
is
your
production
line
of
code,
so
this
is
the
the
main
branch
in
your
code
base
or
represents
the
version
of
your
code.
C
That's
currently
in
production
with
git
lab,
we
usually
start
with
an
issue
and
that
issue
could
represent
a
user
story,
a
feature,
a
bug
report,
a
to-do
could
be
any
number
of
things,
and
in
that
issue
we
usually
use
the
issue
to
collaborately
just
collaboratively,
discuss
with
our
team
what
we're
going
to
be
working
on
what
the
priority
should
be.
Maybe
who
should
be
working
on
it?
How
urgent
it
is
maybe
even
helping
to
define
what
some
of
the
parameters
are
associated
with.
C
C
You
can
also
have
it
do
various
security
scans
on
your
code
like
static
code
scanning
and
others,
you
can
also
optionally
deploy
out
to
a
temporary
or
ephemeral
review
app.
This
is
good
if
you
want
to
be
able
to
show
what
these
changes
look
like.
Have
stakeholders
come
in.
Maybe
you
have
some
tests
that
are
still
manual
and
you
could
do
those
in
that
environment.
C
C
C
You
know
that
the
tests
that
are
important
have
been
run
and
passed
and
succeeded,
and
so,
when
you
merge
this
code
back
in,
it's
ready
to
be
deployed
and
updated
security
scans
and
dashboards
on
your
your
main
branch,
so
that
it
can
go
out
and
even
update
your
your
production
system
automatically
after
this
short-lived
feature
branch
for
this
one
change
described
in
this
one
issue
is
done.
So
this
is
the
gitlab
recommended
process.
C
If
you're
brand
new
to
gitlab,
you
don't
have
to
switch
to
this
process
immediately.
You
can
actually
continue
to
use
your
existing
process
and
then
make
incremental
changes.
If
you
like,
you
know
the
advantages
that
I've
talked
about
here.
You
can
actually
start
to
approach
that,
but
you
don't
have
to
do
it
all
at
once.
You
can
start
by
just
creating
ci
pipeline
and
and
so
on.
So
you
don't
have
to
do
everything
at
once,
but
this
is
just
giving
you
an
image
of
what
that
final
process
would
look
like.
C
And
don't
forget,
if
you
do
have
questions
feel
free
to
pop
them
into
the
q,
a
as
we
go
now.
A
couple
of
the
things
that
I
wanted
to
point
out
here
is
some
of
the
different
terms
right.
Different
tools
and
different
software
development
systems
have
some
different
terms
for
different
types
of
of
objects
within
the
system,
and
I
wanted
you
to
understand
what
the
get
lab
term
is
for
it
kind
of
the
idea
of
what
it
is
and
then
what
it
might
be
called
in
other
systems.
C
C
Your
issues
and
merge
requests
all
live
within
this
project,
but
we
also
have
groups
which
is
a
collection
of
projects
and
or
sub
groups
kind
of
like
folders.
We
talked
a
little
bit
about
issues
already.
Issues
are
could
be,
like
I
said,
a
user
story
a
feature
and
they
let
you
kind
of
plan
and
track
the
work
and
discuss
it
before
it's
started
development
we
also
do
have
epics,
which
are
a
collection
of
related
issues
across
different
groups
and
projects.
C
And
then
we
do
have
labels
which
can
be
used
against
issues
epics
and
merge,
requests
to
tag
and
track
work
across
projects
and
groups
and
use
them
for
filtering,
and
things
like
that.
We're
not
going
to
go
into
a
ton
of
detail
in
that
today,
but
we
have
a
lot
of
great
information
on
different
ways.
You
can
do
that
in
our
on
our
website
and
our
docs
page.
C
We
do
have
milestones
and
iterations,
which
are
a
way
to
track
and
group
together
issues
and
merge,
requests
into
releases
or
chunks
of
time.
Milestones
are
generally
a
larger
group
of
time.
Iterations
are
generally
a
smaller
group
of
time,
and
then
we
do
also
have
a
roadmap
capability
that
has
a
visual
representation
of
various
epics
at
the
group
level.
C
All
right,
one
thing
that
I
think
is
important
to
understand
and
we
are
going
to
get
into
some
screenshots
and
seeing
what
these
things
look
like
in
get
lab
and
in
action.
But
one
of
the
things
I
think
it's
important
to
understand
is
the
group
and
project
hierarchy
that
you
can
create
within
git
lab
and
some
of
the
things
that
you
want
to
think
about
as
you're
building
out
your
structure.
C
So
the
idea
here
is
this
purple
group
is
a
top
level
group,
so
you
have
your
gitlab
instance
and
you
can
have
any
number
of
top
level
groups
in
that
instance,
and
then
those
groups
within
that
top
level
group.
You
can
have
as
many
subgroups
as
you
want,
which
can
then
have
subsequent
subgroups
or
you
can
even
have
projects
directly
in
these
groups.
C
C
So
if
I
add
someone
as
a
developer
to
this
top
group,
they're
gonna
automatically
have
developer
access
to
the
subgroup
and
to
this
project
as
well
as
these
orange
projects
over
here,
and
if
so,
you
want
to
add
people
at
this
top
group
level
being
aware
that
they're
automatically
going
to
get
permissions
to
everything
below
it.
You
can
always
add
someone
to
one
of
these
subgroups
or
projects
that
doesn't
have
access
to
this
top
level
group
or
you
can
give
someone
a
higher
permission
level
if
you
want.
C
So
if
someone
needs
to
be
a
maintainer
or
an
owner
of
one
of
these
other
projects,
you
can
add
them
as
a
lower
level
here
and
add
them
as
a
higher
level
down
here,
and
they
will
only
have
the
higher
level
permission
down
here.
Similarly,
with
labels
and
milestones,
we
talked
about
earlier
when
you're
creating
those.
If
you
you
want
to
create
those
at
the
highest
level.
That
makes
sense.
C
C
The
other
thing
that
you
can
do
as
kind
of
a
best
practice
within
gitlab
is
you
can
create
a
series
of
top-level
groups
that
don't
hold
any
projects
and
all
they
are
for
is
collecting
users.
So
you
could
create
a
group
for
all
of
your
testers
or
all
of
your
qa
people
or
all
of
your
security
people
or
all
of
the
members
of
a
specific
team,
and
that
way
you
can
add
them
on
group
to
a
project
rather
than
have
an
ad
each
individual
person
and
there's
some
significant
advantages
to
that.
C
So,
as
I
mentioned
before,
with
this
basic
process,
we
like
to
start
everything
with
an
issue,
and
the
issue
is
kind
of
our
recommended
starting
point
for
your
workflow.
If
you
are
using
a
different
system
for
currently
for
issues
issues,
you
can
still
use
other
systems.
If
you
want
and
different
projects
can
use
other
systems
or
they
can
use
the
git
lab
issues,
we
recommend
definitely
taking
a
look
at
them.
B
There's
one
about
approvals,
which
I
think
would
be
worthwhile,
so
the
question
is:
does
gitlab
support
multiple
approvals
at
different
stages,
for
example,
one
merge
request
and
then
approval
one
approval
from
infosec
move
to
uoit
approval
from
itups,
then
move
to
production
change,
approval
and
so
on.
Until
finally,
the
project
manager
approves
into
the
master
branch.
C
Obviously
what
with
with
our
best
practices
recommendation,
what
we
would
do
is
is
say
that
you
would
have
those
approvals
here,
and
the
idea
is
that,
because
you're
working
on
this
isolated
feature
branch,
you
could
do
all
of
those
activities
here
and
track
those
approvals.
You'd
have
separate
approval
rules
here
and
then,
once
it's
cleared
all
of
those
hurdles,
you
could
then
do
a
single
merge
back
in.
C
I
do
have
some
customers
that
are
migrating
from
an
older
philosophy
and
a
similar
to
kind
of
what
you
mentioned
where
they
have
different
silos
or
requirements
or
like
on
the
government
side.
They
might
have
regulations,
they
have
to
follow
and
they're
interpreting
them
in
a
way
that
causes
them
to
have
to
get
those
approvals
separately
and
what
they
end
up
doing
is
this
particular
customer
ended
up
choosing
to
do
multiple,
merge
requests.
C
They
have
a
merge
request
that
goes
through
an
approval
process
against
merge
and
then,
when
it's
going
into
that
next
area,
they
create
a
new
merge
request
for
that
purpose.
So
there's
a
great
deal
of
flexibility
with
how
you
can
use
it.
What
I
presented
here
today
is
kind
of
our
our
idealized,
but
of
course
you
don't
have
to
you,
you
do
have
flexibility.
I
don't
know
if
any
of
my
panelists
would
like
to
chime
in
to
help
answer
that
question
in
another
perspective
from
other
customers
but
feel
free
to
chime
in.
B
C
Wow,
okay,
so
so,
basically
the
way
we're
doing
things-
and
I
don't
know
if
you're
coming
from
a
system
that
that
used,
git
or
didn't
use
git
in
the
past
and
definitely
recommend
doing
some
reading
up
on
git
if
you're
brand
new
to
git
in
general,
which
is
the
underlying
technology
for
for
several
different
tools,
including
gitlab.
Obviously,
but
the
idea
here
is
that
yeah,
your
everything
that's
in
this
feature.
Branch
is
isolated
like
we
talked
about
earlier,
and
so
you
can
make
multiple
changes
to
individual
files.
C
These
commits
can
be
multiple
changes
to
the
same
file
and
every
time
you
make
a
change
that
gets
pushed
up
to
the
server
the
the
ci
pipeline
by
default
is
going
to
be,
is
going
to
run
now
you
can
change
that
in
the
configuration
so
that
it
it
runs
only
manually
or
does
nightly,
runs
if
you
want,
but
traditionally
we
would
want
that
to
run
every
time
it
changes.
So
you
can
see
what
the
effect
of
that
was.
C
So
if
you
actually
broke
something
right,
you
know
about
it
right
away,
while
that
change
is
still
fresh
in
your
mind
now,
if
you
had
multiple
features,
the
idea
here
is
that
so
this
feature
branch
once
it
you've
completed
it,
it
would
get
merged
back
in
and
then
the
next
one
would
be
created.
Now,
that's
not
always
what
happens
right.
You
could
have
multiple
future
branches
going
on
at
the
same
time
and
generally,
the
way
that
works
is
the
first
one
to
merge
back
into
your
default
branch,
we'll
get
a
clean
merge.
C
It's
super
easy.
The
second
one
may
tell
you
that,
there's
a
merge
conflict
that
has
to
be
resolved
and
then
you
might
have
to
rebase
pull
the
changes
back
from
your
mainline
branch
back
into
your
future
branch
test
out
that
and
then
finally
do
a
merge.
So
if
you
do
have
multiple
feature
branches
going
on
at
the
same
time,
the
ones
that
merge
later
that
branched
off
from
the
same
location
might
have
a
little
bit
more
challenges.
C
C
C
So
so,
if
you
have
a
new
feature,
that's
coming
out,
you
might
create
an
issue
to
start
the
discussion
on
it
and
you
might
apply
a
label
to
it
that
lets
the
team
know
that
what
stage
of
your
workflow
it's
in
we
do
not
in
gitlab
have
specific
workflow.
You
can
use
our
labels
to
to
define
your
workflow,
but
it's
it's.
C
Some
systems
have
a
specific
hard
workflow,
where
you
have
to
go
from
step
a
to
step
b
to
sfc
and
if
gitlab
will
let
you
kind
of
define
that
yourself
using
our
our
label
so
then,
within
within
within
the
issue.
You
have
a
way
to
discuss
the
issue
asynchronously
and
put
comments
in
and
respond
to
other
folks
comments.
You
can
at
mention
different
folks
on
team.
C
Because
of
you
know,
global
events
or
other
factors,
you
can
use
gitlab
to
kind
of
seamlessly.
Do
those
collaborations,
whether
you're
sitting
next
to
the
person
you're
communicating
with
or
not,
and
the
nice
thing
is,
the
history
of
all
of
those
conversations
and
the
reasons
behind
the
decisions
that
were
made
are
all
kind
of
self-documented
within
those
comments
and
threads
within
the
issue,
and
then,
as
I
mentioned
once,
the
teams
kind
of
finished
discussing
it
developer
would
create
a
merge
request
from
the
issue
and
assign
the
issue
to
themselves.
C
Keep
in
mind
in
gitlab.
You
can
assign
an
issue
or
a
merge
request
to
multiple
people
doesn't
have
to
just
be
one
assignee
and
you
might
have
maybe
there's.
Maybe
this
change
is
gonna
require
back-end
and
front-end
changes,
so
you
might
have
the
back-end
team
start
working
on
it
and
start
writing
code
start
making
commits
directly
to
this
fee.
The
feature
branch
associated
with
that
merge
request
and
you
might
add,
a
label
to.
C
Let
folks
know
that
you're
working
on
it
once
you
once
that
developer
kind
of
finishes
with
some
of
those
commits
they
would
push
those
commits
to
the
feature
branch
to
kick
off
the
ci
pipeline
now
remember
with
git
you
can
work
locally
and
and
when
you're
working
locally
in
your
local
machine,
you
can
commit
to
your
local
git
repository
as
much
as
you
want.
Only
when
you
push
it
back
up
to
the
server.
C
Will
it
kick
off
that
ci
pipeline
if
you're
working
on
the
server
through
our
like
web
ide,
every
commit
is
effectively
a
commit
and
a
push
and
thus
triggers
the
the
ci
pipeline,
and
so
the
developer
would
monitor
the
pipeline
watch
for
the
results.
Did
the
bail
succeed?
Did
the
tests
that
I
wanted
pass
and
then
maybe
they
would
change?
You
know,
add
another
developer
to
assigned
and
add
a
label
to
it.
To.
C
You
can
have
multiple
people
do
reviews.
They
can
actually
comment
on
individual
lines
of
code.
They
can
make
general
comments
and
even
kick
off
code
reviews
that
give
the
developers
kind
of
a
checklist
of
items
to
review
or
respond
to,
and
then
maybe
the
team
is
ready
to
push
it
out
to
a
to
a
staging
area
and
and
update
labels
on
those
issues
and
merge
requests.
C
You
could
also
do
things
like.
Maybe
the
this
is
gonna
need
documentation.
So
you
add
some
additional
labels
to
let
the
marketing
or
documentation
team
know
they
need
to
look
at
this
issue
and
do
something
correspondingly
and
then
you,
you
kind
of
update
final
labels
when
these
different
tasks
are
done
and
then,
ultimately
you
know
you
merge
the
merge
request
and
deploy
to
production
and
then
ultimately
close
the
issue.
This
is
just
an
example,
but
just
to
give
you
a
little
better
idea
of
what
this
process
might
look
like
in
reality.
C
So
what
does
this
look
like
in
gitlab?
So
what
I'm
going
to
do
is
walk
you
through
a
series
of
of
screens
here
in
git
lab,
so
you
can
kind
of
see
what
this
looks
like
as
an
example.
So
here
we
have
a
group
overview,
so
I'm
on
the
group
page,
if
you
remember
from
the
view
earlier,
this
is
actually
a
sub
group.
This
is
not
a
top
level
group.
You
can
actually
see
here
and
we'll
look
at
this
again
later.
C
I
can
interact
with
it,
expand
these
out.
The
groups
have
a
folder
icon
and
the
projects
have
a
this
little
ribbon
icon
and,
as
I
expand
these
out,
you
would
see
different
projects
in
different
hierarchies
and
you
can
create
the
hierarchy.
However,
it
makes
sense
for
your
organization
and
your
team.
C
I
mentioned
earlier
that
issues
in
merge
requests
live
in
the
project
level,
epics
live
at
the
group
level
and
when
I'm
viewing
this
epic
epic
view,
I
have
a
search
or
filter
where
I
can
filter
on
various
values,
including
labels,
and
things
like
that,
and
then
I
can
get
a
listing
of
all
of
the
the
epics,
the
name
of
the
epic.
I
get
a
brief
information
about
the
epic
when
it
was
created
what
its
number
is
and
the
the
dates
that
it's
scheduled
to
be
active
or
operating.
C
You
can
also
see
your
open
epics.
Your
closed,
epics,
create
new
ones
and
I'll
go
into
an
epic
here
in
a
moment.
So
you
get
an
idea
of
what
it
looks
like
and
you'll
see
that,
on
the
top
of
a
lot
of
these
streams,
you'll
see
a
search
bar
that
is
specific
to
the
area
where
you're
in
this
top
search
bar
searches,
all
of
git
lab
your
entire
instance
and
that
that
is
useful
at
times
as
well.
So,
if
you're
wondering
why
there's
two
search
bars,
that
is
why.
C
So
if
we
click
on
one
of
those
epics
and
go
into
it
so
now
we
are
in
an
epic
view
and
looking
at
the
details
of
this
epic,
and
so
some
of
that
same
information
was
from
the
other
screen
like
who
created
it.
When
and
so
on,
is
here,
but
then
I
get
to
see
the
details.
So
you
see
the
headline
of
the
the
epic
and
then
a
description,
the
descriptions
of
epics
issues
and
merge
requests
and
even
the
comments
within
them.
C
You
can
do
formatting
using
markdown,
markdown's
kind
of
a
industry,
standard,
universal
way
of
formatting
plain
text
to
have
formatting
and
then
gitlab
has
an
extension
of
the
industry
standing
marked
down
with
some
additional
features
that
allow
you
to
reference.
Other
gitlab
objects,
like
you,
can
reference
other
issues,
merge,
requests,
epics
milestones
and
so
on.
You
can
add
mention
other
users
and
so
on.
I
think
I
have
some
examples
of
that
coming
up
here
shortly
within
the
epic.
C
C
C
I
get
a
summary
of
how
many
there
are
it's
again,
a
drill
down
hierarchical
view
and
the
epics
are
represented
by
this
kind
of
stack,
whereas
the
issues
represented
by
this
kind
of
like
sheet
of
paper
looking
icon.
Here
and
again,
you
get
some
kind
of
general
information
and
you
can
click
on
these
to
go
into
the
details.
C
C
Issues
have
a
whole
bunch
of
additional
metadata
that
you
can
search
on
as
well
as
free
text
search.
You
can
do
free
free
text,
search
obviously
for
the
epics
and
merge
requests
as
well
and
again
you
get
this
view,
which
shows
you
now
here
in
the
group
level
view
it's
actually
telling
me
which
project
each
issue
that's
listed,
because
it's
showing
me
all
of
the
issues,
issues
don't
live
in
a
group.
C
They
live
in
a
project,
but
it's
showing
me
all
the
issues
that
live
in
all
of
the
projects
that
are
underneath
this
group
and
all
of
its
sub
groups.
So
it's
showing
you
everything
so
you'll
actually
get
a
different
list
of
issues
depending
where
you
are
in
that
hierarchy
tree
that
we
saw
earlier
and
that's
a
powerful
tool.
C
C
This
is
just
showing
an
example
of
what
a
search
looks
like
so
here
we
did
a
label
search
and
a
milestone
search.
So
I
was
looking
for
critical
items
that
were
part
of
this
pi1
milestone,
and
it
gives
me
just
a
filtered
view
to
to
to
see
these,
and
then
I
can
do
a
bulk
update
of
these
issues
to
add
labels
or
close
them
or
whatever
I
want
to
do
with
them.
C
Once
we
go
into
the
issue,
so
if
we
click
on
the
issue,
this
is
what
a
typical
issue
looks
like.
We
have
a
headline:
we've
got
our
markdown
with
different
sections
for
headers
and
and
detail,
and
you
can
create.
You
can
create
issue
templates
and
markdowns
so
that
when
someone
creates
an
issue
in
your
project,
they
can
have
a
default
issue,
template
that
will
pre-fill
it
in
with
helpful
reminders.
C
You
can
actually
find
examples
of
this
in
the
gitlab.org
gitlab
project,
for
when
you
go
to
create
an
issue
against
gitlab
for
a
new
feature,
request
or
a
bug
report,
and
you
can
kind
of
see
some
examples
of
that
which
are
pretty
neat
on
the
right
hand,
side
we
have
all
of
the
different
kind
of
metadata
about
the
issue.
Who's
assigned,
which
epic
it
belongs
to
an
issue,
can
only
belong
to
one,
what
milestone
and
actually
there
should
be
iteration
field.
C
This
is
a
slightly
older
screenshot
of
my
apologies
and
you
update
that.
But
the
what
milestone
iteration
of
wrong
belongs
to
you
can,
if
you've
assigned
time
tracking
or
due
date,
you
can
see
those
and
all
the
labels
that
are
assigned,
as
well
as
the
weight
weight,
is
a
integer
field
that
allows
you
to
kind
of
specify
the
the
relative
difficulty
of
this
issue
compared
to
other
ones.
It
we
use
it
in
some
of
the
burn
down
and
burn
up
charts
and
on
some
of
the
boards.
C
So
you
don't
have
to
use
it.
But
if
you
do,
you
can
use
any
system
you
want,
you
could
use
like
a
fibonacci
system
or
you
can
use
a
t-shirt
size
as
long
as
you
convert
it
into
those
integer
values,
because
it
is
adding
those
up,
and
so
it
needs
to
be
a
number
that,
and
if
you
have
public
projects,
you
can
have
marked
issues
as
confidential,
so
that
only
members
of
the
project
can
see
them.
C
Further
down
on
the
issue,
you
can
see
related,
merge
requests.
You
can
actually
see
other
related
issues
as
well.
It's
not
showing
the
screenshot,
but
you
can
see
issues
that
are
blocked
by
or
block
is
blocked
by
or
block
blocking
other
or
just
simply
relating
to,
and
it
shows
you
merge
requests
that
were
created
against
this
issue,
and
you
can
even
see
the
discussions
here
and
all
of
the
history.
C
This
view
is
just
showing
comments
only,
but
you
can
switch
this
to
share
the
history
or
all,
and
you
can
see
all
the
different
changes
every
time.
Anyone
made
any
change
to
this.
It's
recorded
here,
you
can
see
in
the
comments
people
have
at
mentioned,
other
users
to
get
them
to
chime
in
you
can
apply
emojis
and
upvote
the
issue
itself,
as
well
as
individual
comments.
C
Then
you
can
also
organize
your
issues
on
boards.
You
can
have
multiple
boards
switch
between
boards.
Each
board
can
have
it's
like
a
kanban
board
or
similar
where
you
have
a
default
column
on
the
left,
and
then
you
can
define
as
many
columns
as
you
want.
The
columns
can
be
defined
by
labels.
They
can
be
defined
by
milestones
people,
so
you
can
use
these
to
assign
items
you
can
use
these
to
for
various
different
purposes.
So
this
is
an
example
of
a
triadic
board
where
I
have
my
priorities
across
the
top.
C
Any
item
that
doesn't
have
one
of
those
priorities
is
shown
here
and
I
can
simply
drag
and
drop
this
card,
which
represents
a
single
issue
into
the
column
that
I
want
it
to
be
assigned
to
and
will
automatically
add
that
label
to
it.
Similarly,
if
I
did
a
resource
board
and
had
people
across,
if
I
drag
one
across
it
will
automatically
assign
that
person
to
it,
you
need
the
same
thing
for
milestones
for
doing
release,
planning
or
sprint
planning,
and
so
on.
C
You
also
notice
there's
two
different
kinds
of
labels.
Here
the
solid
color
labels
are
kind
of
just
just
our
basic
labels.
We
also
do
have
another
kind
of
label
that
allows
you
to
create
a
name
value
pair
where,
like
this
is
the
category,
and
this
is
the
value,
so
you
can
see.
This
is
priority
critical
priority
high
and
those
are
called
scoped
labels,
and
you
can
use
those
to
two.
C
Let's
go
into
so
now.
This
is
a
view
of
the
merge
request
where
I
wanted
to
highlight
here
so
once
from
the
issue.
If
we've
created
the
merge
request
in
this
merge
request
again,
this
is
a
kind
of
a
complete
view
of
the
change
that's
being
made,
so
you
can
see
a
bunch
of
different
information
here.
You
can
see
up
at
the
top
what
issue
it's
associated
with
in
this
case,
when
this
is
completed,
if
it's
completely
successfully
merged,
it
will
close
out
the
corresponding
issue
automatically.
C
C
C
You
can
define
those
approval
rules
in
the
settings,
we're
not
going
to
go
into
that
today,
but
then
this
thing
definitely
took
a
look
at
if
approvals
are
important
to
you
and
then
your.
If
you
have
your
our
security
scanning
turned
on,
you
can
actually
see
the
security
results
directly
here
within
the
merge
request.
One
of
the
things
I
really
like
about
this
is
because
gitlab
news
what
the
last
status
of
your
security
results
were.
C
It
can
show
you
just
the
difference,
so
you
can
actually
see
just
what
you
know
how
much
you
improved
or
if
you
fix
vulnerabilities
or
introduce
new
vulnerabilities,
but
you
can
also
view
the
full
report
and
that
way
as
a
developer.
If
I
accidentally
introduce
a
vulnerability,
I
get
told
about
it
right
away,
while
it's
still
fresh
in
my
mind,
as
opposed
to
something
that
happens
a
month
from
now,
and
I
can't
remember
what
the
heck
I
was
working
on
when
I
accidentally
introduced
it
now.
C
I
have
to
refactor
my
code,
whereas
if
I
get
the
information
now,
I
could
do
it
right
away
and
then,
ultimately
you
can
also
you
can
also
do
like
I
mentioned
code
reviews,
you
can
actually
write
comments
directly
against
an
individual
line
of
code,
because
you
can
view
this
is
a
different
view
of
the
merge
request
which
shows
this
is
looking
at
what
files
have
actually
changed,
which
lines
of
code
changed?
You
can
also
look
at
the
pipelines
associated
with
this
or
the
all
of
the
different
changes
that
have
been
made.
C
The
idea
is
that,
rather
than
taking
a
bunch
of
different
changes
and
trying
to
merge
them
together
at
the
end
of
the
process
and
then
try
and
do
a
build
and
test
you
do
those
continuously,
so
that
if
you
do
accidentally
make
a
change
that
breaks,
something
whether
it
be
the
build
or
one
of
your
tests,
you
know
about
it
right
away.
You
can
fix
it
right
away
again.
C
Making
your
process
more
reliable
and
faster,
also
encourages
collaboration
across
all
of
your
departments
allows
for
the
early
error
detection
as
we
talked
about
reducing
integration
and
increasing
speed,
and
this
is
kind
of
what
it
looks
like
where
you
have
your.
Each
of
these
bubbles
represents
a
different
job.
Each
job
can
be
optionally,
put
into
different
stages.
C
Stages
by
default
will
be
sequential,
but
the
jobs
within
them
will
run
in
parallel,
so
you
can
have
a
build
job.
A
series
of
test
jobs
that
run
in
parallel
and
then
pushing
out
the
different
environments.
You
can
define
this
pipeline,
however,
you
want.
We
also
do
have
an
auto
devops
feature
that
will
automatically
build
this
pipeline
for
you
just
by
turning
on
the
auto
devops
feature,
which
is
pretty
neat.
C
And
then
really
quickly,
just
a
little
bit
more
information
about
labels.
This
is
just
showing
the
labels
view
within
the
group
level.
I
filtered
this
for
just
the
priority
labels.
You
can
see
examples
of
those
here,
but
you
can
create
as
many
labels
as
you
want
use
them
for
various
purposes,
including,
like
I
said,
priority
severity,
slings,
a
bug
or
a
feature
pretty
much
anything.
A
lot
of
people
use
are
use
the
workflow.
C
And
then
this
is
just
a
view
of
the
milestones
we
talked
about
milestones
earlier
milestones
a
collection
of
issues
generally,
it
could
be
a
release.
It
could
be
a
programming
comment.
It's
it's
generally,
just
something.
That's
time,
boxed
you're,
setting
a
manual
start
and
end
date
for
the
milestone,
giving
it
a
name
and
then
you,
as
you
add
issues
and
merge,
requests
to
it.
You
can
see
how
many
are
in
there
how
far
it's
completed.
C
C
And
then
real
quick,
I
had
a
couple
navigation
tips
for
you,
as
I
mentioned
earlier,
there's
the
breadcrumbs
at
the
top.
To
always
show
you
where
you
are.
We
have
the
on
the
left.
You'll
always
have
wherever
you
are
you'll
have
the
relevant
set
of
of
different
objects
that
you
can
view
so
and
reminder
of
where
you
are
and
then
up
at
the
top
is
the
url.
C
It's
not
it's
kind
of
how
we
do
subtasking
within
git
lab,
because
you
can
have
multiple
assignees
to
the
same
issue
or
merge
requests
and
then
ultimately
back
up
at
the
top
we're
back
at
the
group
level,
and
if
I
want
to
create
a
new
project,
you
can
create
a
new
project
here
or
a
new
group,
and
then
you
get
a
number
of
different
options
to
create
that
new
project,
including
creating
a
blank
project
creating
from
a
template.
You
can
gitlab
comes
with
a
bunch
of
built-in
templates.
C
Your
administrator
can
also
create
instance,
level
templates
for
you
based
off
of
an
existing
project.
You
can
also
import
projects
or
just
create
a
project
just
purely
for
for
ci
cd.
So
there's
a
lot
of
different
options
there
that
you
take
a
look
at,
but
I
definitely
encourage
you
to
take
a
look
at
our
built-in
templates.
There's
a
lot
of
neat
stuff
that
helps
you
get
a
jump
start
there.
C
A
We
also
have
more
of
these
upcoming
webinars
on
more
advanced
topics
and
more
specific
topics.
So,
as
you
get
more
familiar
with
git
and
git
lab
and
working
with
code
and
issues,
we
have
webinars
already
recorded
for
ci
cd
security
scanning
and
vulnerability
management,
project
management
and
planning
and
issue
tracking.
A
So
if
you're
curious
about
how
to
take
workflows
that
you've
been
doing
historically
in
things
like
jira
or
other
products
and
do
them
in
get
lab,
those
are
great
introductions,
we'll
add
links
to
some
of
the
pre-recorded
webinars
to
the
slide
deck
and
also
stay
tuned.
To
the
same
you
know,
email
invites
will
be
going
out
for
other
webinars
along
this
in
this
series,
so
we'll
be
sure
to
share
those
and
just
to
be
clear.
These
are
distinct
from
our
marketing
webinars.
A
C
C
Looks
like
brian's
answering
the
question
about
exporting
projects.
You
can
export
projects
from
one
gitlab
to
another.
We
don't
recommend
necessarily
using
that
as
your
primary
backup,
especially
if
you're
a
self-managed
instance.
We
do
have
great
backup
capabilities
that
are
available
and,
of
course,
gitlab.com
is,
is
backed
up
and
and
has
a
whole
site
reliability
team
that
monitors
it
continuously.
So.
C
Let's
see
james
asked
if
all
these
features
available
on
both
self-managed
and
sas,
or
are
they
different?
Every
feature
that
I
pointed
out
today
is
available
on
both,
I
think
the
one
thing
that
is
slightly
different,
that
I
should
have
mentioned
when
I-
and
I
said
it,
was
that
if
you
have
a
group
on
gitlab.com,
you
can
create
at
that
top
level
group.
C
And
then
oh
muhammad
asked,
does
gitlab
have
any
synchronization
capability
for
self-hosted
instances
in
case
we
want
to
implement
an
active
active,
dr
or
yes,
so
we
have
the
geo
feature
that
allows
you
to
set
up
a
secondary,
git
lab
and
it
does
a
continuous
sync
across
it.
It
also
allows
you
to
create
a
single
url
that
all
of
your
team
can
access.
C
It
also
has
the
advantage
of
if
you
do
have
a
geographically
dis,
disparate
team
teams
can
connect
to
the
one
that's
closest
to
their
area
and
get
the
exact
same
information,
and
if
then
one
of
them
goes
down,
you
can
promote
the
secondary
to
a
primary
and
then
restore
from
from
there,
because
our
you
know
it
has
all
the
data
and
then
you
can
work
on
whatever
the
issue
was
on
the
primary
keep
in
mind.
This
does
not
replace
if
your
self-management
did
not
replace
high
availability.
C
A
C
C
All
right
well
we're
at
the
top
of
the
hour,
so
thank
you
all
for
attending,
as
patrick
mentioned.
I
really
hope
this
helps
you
get
started
with
get
lab
and
stay
tuned
for
updates
with
the
newsletters
as
patrick
mentioned,
and
for
any
upcoming
sessions
like
this.
I
think
we're
gonna
do
one
on
ci
cd
in
the
future,
so
stay
tuned.
For
that.