►
Description
Discussed questions:
0:00 What are the biggest deployment or release challenges that GitLab users face?
4:02 One of the deployment challenges that Delivery experience is the need to coordinate lots of moving parts and manage these alongside relevant deployment and environment information. Has there been any discussion about providing some sort of deployment or release dashboard/control place to help users to do this?
7:18 How is "External dashboard support" a dashboard?
8:57 What do you see for future capabilities in Release Orchestration? (move from viable to loveable)
11:55 What percentage of people using Kubernetes and GitLab are using our agent approach?
16:32 What still has to be determined before making a group environment page?
20:28 Should we aspire to add the capabilities that Lens has inside GitLab?
23:46 To what extent are we using the GitLab Agent to run GitLab.com?
B
Yeah
thanks
amy
hi
everyone,
chris
blaney,
and
the
release
product
manager,
great
question,
and
so
I
I
typed
up
some
some
thoughts
here.
One
problem
we're
facing
with
especially
with
large
enterprise
customers,
actually
literally
just
got
a
call
with
one
of
our
large
customers,
is
ability
to
enforce
deployment,
workflows
and
policies.
So
what
I
mean
what
I
mean
by
that?
So
let's
say
we
have
a
company.
B
All
those
things
all
within
get
love
is
what
we're,
what
we're
looking
into
right
now.
Does
that
make
sense,
and
then
another
one
is
actually
you
mentioned
in
your
question
too,
so
we
could
maybe
say
it
save
it
for
that,
but
giving
the
ability
to
to
look
across
multiple
projects.
You
know
we
have
a
lot
of
capabilities
today
at
the
project
level
in
terms
of
environments
and
visualizing.
B
B
Sorry
go
ahead
and
then
just
and
then
looking
forward
things
like
I'm
kind
of
calling
intelligence
and
automation
around
deployment
and
releases.
So
how
do
we
give
organizations
like
the
confidence
that
it's
the
right
time
to
deploy
and
to
do
it
safely?
Is
production?
Is
the
environment
stable
right
now?
Can
we
do
auto
rollbacks?
Can
we
automate
some
of
those
things
that
are
currently
pretty
manual
for
for
teams?
How
do
we?
How
do
we
do
that
all
within
gitlab,
it's
another
more
opportunity
there
as
well.
C
C
What
do
I
see
with
other
customers
is
how
others
do
it,
because
they
they
look
to
all
of
these
policy
approaches
as
well,
but
the
other
questions
are
like:
we
want
to
provide
the
maximum
flexibility
without
the
developer,
knowing
anything
about
what's
happening.
Basically,
that's
the
that's
the
wishful
thinking
so
to
say,
and
of
course,
everyone
knows
that
this
is
not
possible
and
they
have
to
find
the
the
balance
between
these
two
approaches.
A
I
think
within
the
gitlab
product.
One
thing
is
it's
sort
of
like
each
page.
Does
one
specific
thing
and
we
sort
of
end
up
moving
around
to
quite
a
lot
of
different
places.
So
I
was
wondering
if
there's
been
any
discussion
around
sort
of
providing
some
sort
of
control,
plane
or
dashboard
or
something
where,
as
someone
deploying
things,
you
kind
of
have
all
the
information
and
also
the
buttons
to
to
take
actions
just
on
one
place.
Yeah.
B
Yeah,
thank
you
amy
again
excellent
question
and
I'll
note
you
and
I
talk
a
lot
about
about
how
to
how
to
work
better
together
and
how
to
dock
through
more
of
our
release
stage
functionality
with
our
delivery
team.
Our
I
will
say
our
deployment
process
is
uniquely
complex,
maybe
and
so
things
we.
We
do
use
a
fair
amount
of
coordinated
pipelines.
B
B
But
to
answer
your
question:
yes,
we
and
we
have
a
few
pieces
in
place.
Some
of
the
building
blocks
there
to
make
this
better.
We
have
our
environments
page,
which
we
recently
redesigned
to
be
more
useful
and
help
users
understand,
at
least
on
our
project
level.
Right
now,
what's
being
deployed,
we
have
an
environments,
dashboard
and
operations
dashboard,
so
we
have
multiple
places
in
gitlab
and
room
for
to
kind
of
build
upon
what
we
have
there
and
maybe
even
consolidate
some
of
those
things.
B
B
Right
now
like
we,
don't
have
anything
like,
for
example,
like
a
group
environment,
that's
something
we're
thinking
a
group
environments
page,
that's
something
we're
thinking
about
and
right
now
we're
in
the
ideation
stage
of
what's
the
best
way
to
solve
that
problem,
but
we'd
love
to
collaborate
and
and
work
with
you
and
your
team
to
figure
that
out.
That's
good
great
stuff,
yeah!
Thank
you!
C
What
I've
I
was
actually
surprised
that
it
comes
up
surprisingly
rarely
on
user
code
is
that
they
have
complex
deployment,
orchestration
requirements.
I
heard
it
a
couple
of
times,
but
really
rarely-
and
my
guess
is
that
mostly
because
they
are
loosely
coupled
microservices
that
they
deploy
and
they
don't
have,
that
requirement.
D
C
Very
very
good
point:
yes,
so
we
wanted
to
provide
dashboarding
within
gitlab,
and
actually
we
still
want
to
provide
that,
but
we
realized
it
will
take
several
months
so
we're
going
to
okay.
Let's,
let's
take
a
faster
approach.
How
can
we
still
provide
dashboard
to
users
because
they
really
ask
for
that,
and
the
idea
was
to
provide
support
for
extra
dashboards.
There
are
amazing,
kubernetes
dashboards
out
there.
C
C
E
B
Yeah
I'll
I'll
take
that
one.
Yes,
I
think
there
are
a
few
capabilities
and
some
that
we're
actually
working
on
pretty
soon
to
make
that
upgrade
in
maturity.
So
I
think
examples
of
those
are
like
being
able
to
more
seamlessly
generate
change
logs
and
release
notes
as
an
example
from
based
on
what
we
have
what
we
have
already
in
gitlab.
We
have
some
work
to
do.
B
B
E
Absolutely
happy
to
do
that.
I
really
love
that
idea
of
release
run
books,
especially
that
has
really
good
connection
in
public
sector
where
government
agencies
are
are
just
now
transitioning
from
a
traditional
waterfall
approach
to
more
agile,
devops
and
they're
struggling
with
how
do
they
increase
the
velocity
of
their
releases
to
go
with
the
velocity
of
code
development
right
to
kind
of
match
those
two,
but
they
want
to
maintain
that
governance
and
that
and
that
set
of
of
rules,
if
you
will
definitely
definitely.
C
C
D
D
C
We
know
a
few
use
cases
that
we
cannot
support
today
with
the
agent,
but
not
many
of
those,
so
it
takes
a
lot
of
time
actually
to
migrate
as
well.
That's
what
that's
one
thing
that
we
learn.
What
can
we
do?
We
actually
have
our
top
items
that
I
I
wanted
to
change
the
slides
as
well
the
helm
and
customize
support
dashboarding
and
to
make
it
easier
to
scale
to
multiple
manifest
projects.
The
deployment.
F
And
sort
of
related
to
that
victor,
going
back
to
the
statement
you
made
earlier
around
not
seeing
a
lot
of
demand
for
like
complex
release.
Orchestration
is
that
is
it
that
people
are
using
things
like
argo
cd
instead
of
the
agent
or
the
gitlab
cluster
and
like
that's,
why
we're
not
seeing
demand
for
those
features
in
gitlab
like
do
you
expect
to
see
more
demand
as
adoption
ramps
up,
or
I
mean
it's
also
sort
of
like
a
chicken
and
egg
thing
right,
yeah,
yeah,.
C
C
C
The
visualization
aspect
is
definitely
there
and
even
navigating
like
a
huge
microservices
architecture
with
hundreds
of
services
and
being
able
to
see
pieces.
That's
definitely
there
as
a
requirement.
Yes,
but
argo
doesn't
have
a
good
solution
for
that,
because
you
have
to
switch
between
different
argo
instances
right.
F
D
F
C
It's
still
the
case
and
actually
what
I'm
trying
to
do
in
the
past
few
months
is
to
rally
around
all
stages,
not
just
release,
but
even
the
verified
to
have
it
integrated
with
pipelines
as
well.
So
once
the
fireplan
is
green,
that's
when
we
run
the
deployment
once
deployment
is
done,
we
can
fire
off
another
part
time.
I
try
to
get
buying
from
from
the
verify
team
into
that.
D
C
C
D
C
D
C
C
C
I
decided
to
list
here
the
main
capabilities,
as
far
as
I
say,
feel
free
to
extend
marshall
or
anyone
else
in
those
lens.
The
core
capability
is
its
resource
dashboard.
I
definitely
think
that
it
should
be
part
of
bitmap
as
well
a
resource
dashboard,
and
we
want
to
do
that
together
with
the
obstacles.
Integration
should
be
in
more
power
for
the
the
insights
aspect.
C
C
C
If
we
do
it,
we
want
to
do
it
in
a
really
integrated
approach
with
the
agent,
but
in
larger,
even
mid-sized
organizations.
I
would
say
that
this
is
an
anti-pattern
that
you
install
stuff
from
dashboarding
tool,
so
I
I
would
rather
stay
away
from
that,
and
the
final
features
that
I
see
is
that
they
are
pretty
accessible.
C
F
A
a
while
back
we
had,
we
had
discussed
like
a
possible
first
iteration
of
this
to
just
enable
like
cube
cuddle
access
from
web
terminals,
that
that
would
enable
like
folks
to
use
cli
tooling.
That
does
very
similar
stuff
like
here
I'll
link
canines
here,
and
I
think
like
would
would
just
be
super
valuable
in
a
ton
of
contacts.
I
think
the
main,
if
I
remember
correctly,
the
main
problem
was
that,
like
web
terminals
are
not
enabled
on
shared
runners,
is
that
still
true
as
well.
C
D
A
A
sort
of
small
or
standalone
project,
or
something
like
run
books
that
we
can
to
do
the
transition
we
haven't.
We
haven't
had
the
chance
to
sort
of
figure
out
how
we
will
move
all
of
the
the
gitlab.com
deployments
over
there.
Yet
so,
as
far
as
I
know,
we,
we
may
not
have
anything
running
unless,
unless
you
know
something
else
in
reliability,
victor.
D
C
Yeah,
so
we
started
to
migrate
some
services
before
the
15-0
cutoff,
because
our
initial
plan
was
that
every
service
we
need
to
be
innovative
later
on,
we
managed
to
iterate
a
smaller
term.
So
I
know
that
I
don't
remember
exactly
which
services
we
immigrated
already,
but
some
I
think
it
might
be
the
review
apps
cluster.
That's
that
was
migrated.
The
cluster
itself
and
some
other
services
that
are
not
specifically
running
gitlab.com
but
might
be
business,
oriented
or
or
agile,
hr
or
designgitlab.com
was
already
immigrated.
If
I'm
not
mistaken,.
C
That
what
we
are
planning
to
do
is
actually
we
found
a
few
clusters
that
don't
have
proper
ownership,
so
we
are
looking
for
owners
of
some
of
the
clusters
and
from
us
migrating
the
clusters
we
want
to
directly.
We
want
rather
to
support
the
teams
to
migrate
the
clusters
and
we
just
supporting
them,
so
we
can
learn
along
the
way
more
than
if
we
would
do
the
innovation
itself.
This
will
change
as
well
in
the
past
month,
as
we
don't
have
to,
we
didn't
have
to
fast.