►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
Yes,
thank
you,
so
I'm
curious
to
hear
about
what
are
the
biggest
deployment
or
release
challenges
that
your
hearing
get
lab
users
face.
C
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.
C
We
have
a
platform
teams,
we're
responsible
for
building
employment
pipelines
and
enforcing
how
deployment
should
look,
who
should
who
has
access
to
deploy
to
which
environments
and
so
on,
and
they
want
to
enforce
those
all
within
git
lab
and
so
kind
of
that
class
of
problems
is
what
we're
seeing
right
now
and
giving
giving
organizations
and
teams
sort
of
the
flexibility
and
controls
for
doing
that
across
multiple
projects
and
groups
and
and
whatever
configuration
they
might
may
want
for
their
organization
like
one
one
pattern
is,
is,
of
course,
like
segregation
of
duties,
where
operators
have
permissions
to
deflate
a
reduction,
but
and
and
then
they
might
want
dev
teams
to
to
be
able
to
run
pipelines
but
not
to
play
the
production
and
who,
who
has
to
approve
those
those
steps,
I
think
orchestrating.
C
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
your
question
too,
so
we
could
maybe
save
it
for
that,
but
giving
the
ability
to
look
across
multiple
projects.
You
know
we
have
a
lot
of
capabilities
today
at
the
project
level
in
terms
of
environments
and
visualizing.
C
What's
what's
deployed
where
and
when,
but
being
able
to
do
that
at
scale
across
projects?
For
you
know
an
application
or
multiple
applications.
We
we
have
some
opportunity.
There.
C
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.
A
I
I
I
would
specifically
only
expand
upon
chris's
answer,
because
I
said
most
of
the
same
things
with
the
monitoring
aspect.
I
would
add
as
well
that
12,
the
most
of
the
requested
features
with
configure,
is
actually
to
see
how
something
is
being
rolled
out.
A
So
not
just
what
was
rolled
out
yesterday
and
what
is
current
running
there,
but
as
it
rolls
out
whether
there's
any
issue
with
rollout
that
ties
into
chris's
last
answer,
that's
part
of
that,
but
it's
more
just
a
red
line
showing
or
that
it's
in
progress
and
stuff,
like
that,
the
other
which
I
find
as
a
that
they
are
looking.
They
are
asking
me.
A
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.
B
Yeah
amazing
yeah
and
then
so
one
of
the
deployment
challenges
that
delivery
face
is
we
have
a
lot
of
moving
parts
or
our
sort
of
deployment
pipelines,
and
we
are
sort
of
looking
in
different
places
for
like
environment
information
and
like
health,
and
you
know,
is
there
something
to
deploy.
B
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.
C
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
do
use
a
fair
amount
of
coordinated
pipelines.
C
We
have
our
security
releases,
which
have
their
own
special
sort
of
needs
and
and
the
fact
that
we
use
sort
of
mirrored
repos
a
few
other
sort
of
characteristics
about
it
and
so
the
product
today
doesn't
definitely.
It
definitely
doesn't
solve,
like
some
of
those
pain
points
very
gracefully.
C
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
the
project
level.
Right
now,
what's
being
deployed,
we
have
an
environments,
dashboard
and
operations
dashboard,
so
we
have
multiple
places
in
get
lab
and
room
for
to
kind
of
build
upon
what
we
have
there
and
maybe
even
consolidate
some
of
those
things.
C
We're
actually
just
talking
about
that
as
a
team
this
morning
and
and
but
yeah
we'd
be
def.
This
is
definitely
one
of
the
next
problems.
We're
trying
to
solve
so
again
being
able
to
coordinate
view
first
and
then
coordinate
those
types
of
deployment
actions
across
multiple
projects.
C
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
Victor.
You
had
a
notebook,
yeah.
A
What
I've
I
was
actually
surprised
that
it
comes
up,
surprisingly
rarely
on
user
codes,
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
A
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
would
take
several
months.
So
that's,
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.
A
Two
examples
are
lens
and
kines
and
all
of
these
work
in
a
very
traditional
way
of
kubernetes
context
and
the
cube
config
file,
and
what,
if
we
can
just
integrate
with
these,
where
the
tooling
is
actually
already
present,
thanks
to
the
ci
cd
workflow
that
we
support,
we
just
have
to
provide
it
that
instead
of
a
runner
that
reaches
the
cluster,
the
user
can
reach
the
cluster
from
the
local
laptop.
A
E
Yeah,
hey
victor,
so
question:
what
do
you
see
for
future
capabilities
in
release
orchestration,
because
that
provides
a
lot
of
value
for
our
customers?
But
how
do
we
move
that
from
viable
to
lovable?
What
what
do
you
think
it
would
take.
C
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.
C
We've
heard
recent
feedback
from
customers
that
the
releases
page
ui
can
use
a
little
bit
of
improvements
as
well
being
able
to
navigate
and
search,
for
example,
being
able
to
show
the
right
information,
that's
valuable
for
users,
sort
of
design,
kind
of
hierarchy
and
and
improvements
there
and
then,
and
then
similarly,
to
what
we
were
talking
about
for
environments,
ability
to
and
more
seamlessly
release
or
create
releases
across
projects
in
groups
is
another
key
capability
and
then
beyond
that,
potentially
ability
to
do
sort
of
automate
release
type
of
tasks.
C
So
you
know,
I
think,
of
traditional
releases
where
people
have
run
sort
of
kind
of
run,
books
and
and
kind
of
checking
off
tasks
for
different
releases
tests
and
so
on.
Maybe
bringing
that
ability
to
do
that
within
get
lab
would
be,
would
be
an
improvement
as
well.
Does
that
help?
C
It
sure
does
chris
thanks
and
and
if
you
do
have
you
know
you
mentioned
customers
that
you're
and
working
with
that
that
could
benefit.
I
would
love
to
would
love
to
chat
with
them
as
well.
E
Absolutely
happy
to
do
that.
I
really
love
that
idea
of
release
runbooks,
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.
A
A
Yeah
anybody
can
find
that
on
the
provided
link,
we
see
2.5
of
the
ultimate
users
having
at
least
one
actively
connected
agent
1.7
of
premium.
Software
is
users
and
we
have
roughly
2015.
A
D
D
Thanks
thanks
for
the
data,
how
are
we?
What
can
we
do
to
increase
this?
Because
we,
I
think,
like
80,
would
be
our
goal
or
something
like
that.
A
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
be
make
it
easier
to
scale
to
multiple
manifest
projects,
the
deployment.
A
We
believe
that
these
three
are
at
the
top
blocking
issues
for
many
users
to
to
move
over
to
the
agent
even
to
move
away
from
argo
cd,
actually.
D
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.
A
It
was
very
interesting
that
at
cubecon,
especially
but
even
before,
so
I'm
interviewing
argos
city
users
as
well,
who
are
gitlab
customers,
but
they
use
argo
cd
for
their
deployments
and
basically
they
they
don't
consider
the
deployment
complex
and
my
impression
is
that
simply
because
they
they
can
focus
on
on
just
a
small
subset
of
the
applications
that
they
deployed
because
of
microservice
architectures.
A
A
A
Definitely
the
visualization
aspect
is
definitely
there
and
even
navigating
like
a
huge
micro
services
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
arguments,
often
for
that
right,
right.
D
Cool
what
what
still
has
it
be
determined
before
making
a
group
environment
page-
and
my
thinking
is
a
bit
like
well
just
start
with
the
project
environment
page
and
and
start
there,
and
then
you
can
take
it
from
there,
but
apparently
there's
more
thinking.
So
I'm
curious.
C
Yeah
thanks
it
yeah,
and
I
know,
we've
had
the
idea
for
a
while
before
predates
predates
me
joining
as
well
we're
at
the
point
where
we're
we
are
taking
some
time
to
ideate
other
solutions
to
the
problem
as
well,
but
I
I
believe
group
environments
is
the
best
one,
the
best
idea
we
have
right
now,
so
this
milestone
next
milestone,
we're
we're
scoping
and
prepping
it
for
development
and
then
specifically
we're
discussing
the
first
like
iteration
as
well,
because
there
are
some
technical
challenges
in
terms
of
what
info
to
display
we
don't
want
to.
C
We
don't
want
to
display
everything
off
the
bat,
and
then
there
are
some
performance
issues
that
we're
just
that
we'll
need
to
overcome,
and
so
part
of
part
of
figuring
out.
The
right
duration
is
choosing
the
specific
pieces
of
data
that
that
also
will
will
scale
for
for
our
first
nbc,
but
we'll
we
hope
to
make
progress
on
it
soon.
F
A
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
power
plan
is
green,
that's
when
we
run
the
deployment
once
the
deployment
is
done,
we
can
fire
off
another
pipeline.
D
A
It
was
mentioned
in
the
presentation
very
likely,
not
clear
enough.
It
is
crucial.
I
think
I
think
one
of
the
value-added
is
that
we
are
gitlab
and
it
shouldn't
be
just
deployment
specific,
small
things
that
the
agent
can
provide,
but
it
should
provide
the
integrated
experience
with
the
rest
of
gitlab.
A
D
And
that
makes
sense.
How
can
we,
how
can
I
help
to
like
if
it's
across
multiple
teams
is
there
not
enough
cross
functional
collaboration
here?
Is
this?
Is
there
not
enough?
A
Slowly,
ramping
up,
I
I
think
so
I
started
like
a
month
and
a
half
ago,
as
we
were
planning
the
queue
to
work.
I
am,
I
hope
that
within
the
op
section
we
can
handle
most
of
it
so
because
it's
cross
stage-
and
I
already
had
talks
with
hillary
and
all
their
team
on
on
security
possibilities
as
well.
So
I
think
we
are
on
it.
It
takes
some
time
for
them
to
get
there
on
their
roadmap
as
well.
D
A
A
A
I
decided
to
list
here
the
main
capabilities,
as
far
as
I
say,
feel
free
to
extend
marshall
or
anyone
else
in
those
lands.
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
more
powerful.
A
A
I
wasn't
thinking
much
about
it,
yet
whether
I
would
like
to
provide
it
or
not,
it
would
require
writing
a
business
case,
so
we
have
a
better
understanding
of
the
feature
and
its
requirements.
A
Another
one
is
ham
support
which
allows
easy
installation
of
hem
charts.
I
didn't
have
time
to
to
finish
it
yet
here
I
think
we
should
be.
A
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
would
rather
stay
away
from
that,
and
the
final
features
that
I
see
is
that
they
are
pretty
accessible.
A
D
F
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
context.
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.
A
I
think
I
remember
something:
different
was
the
main
concern,
which
was
that
webtooners
were
not
reliable.
We're
not
unstable
that
much.
I
think,
but
I
am
not
interested
I
would.
I
would
have
to
check
it
again
what
we
discussed
back
a
year
ago,
so
I
I
don't
remember.
F
Yeah
web
terminals
could
be
like
a
really
nice
have
really
nice
energy
with
the
kubernetes
agent.
If
we
get
those
on
sas,
I
should
look
back
into
that.
D
B
So
yeah,
so
within
delivery,
we're
not
using
it
it's
sort
of
on
the
on
the
list
to
prioritize.
B
A
sort
of
small
or
standalone
project,
or
something
like
runbooks,
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
github.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.
A
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
agile,
hr
or
designgitlab.com
was
already
immigrated.
If
I'm
not
mistaken,.
A
It-
and
one
more
note
here,
is
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
be
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.