►
From YouTube: GitLab 14.0 Kickoff - Configure:Configure
A
Hi,
my
name
is,
and
I'm
the
senior
product
manager
of
the
configure
group-
and
this
is
the
14.0
release-
kickoff
video
for
our
group.
What
do
we
plan
to
ship
in
14.0?
First
of
all,
four,
then
zero
is
our
opportunity
to
ship
breaking
changes.
As
a
result,
we
are
going
to
deprecate.
We
are
going
to
remove
a
one
click,
gitlab
managed
app
in
14.0
and,
together
with
that,
we
are
actually
going
to
improve,
hopefully
a
lot.
A
The
ci
based
cluster
management
project
at
the
same
time
actually
naming
the
cluster
management
project
and
this
whole
gitlab
managed
apps
to
gitlab
integrated
applications,
because
that
describes
much
better
what
they
are
aimed
at
and
the
cm
the
cluster
management
project
will
be
a
way
to
to
make
it
easy
to
get
started
with
the
github
integrated
applications,
but
actually
you,
the
user,
will
own
these
applications.
We
do
not
manage
them
for
you.
A
This
is
what
we
failed
in
the
past
years
as
well,
and
we
don't
have
a
good
model
in
upgrading
and
taking
care
of
the
applications
on
our
users
behalf.
So
we
are
not
dealing
with
that
and
we
just
acknowledge
this
fact.
Today,
besides
these
movers,
we
have
a
lot
of
other
minor
changes
as
well
like
bumping
versions
of
the
trafform
template
and
the
auto
double
auto,
deploy,
template
and
so
on.
A
But
those
are
just
minor
changes
in
terms
of
of
scope,
even
though
those
are
breaking
changes
as
well
followingly.
We
are
currently
running
an
auto
devops
design
sprint
and
we
hope
that
we
will
be
able
to
start
working
on
its
output
during
the
next
milestone.
At
the
same
time
as
this
design
sprint,
I
cannot
tell
what
that
output
will
be
and
if
any
issues
we
will
have
there,
those
might
be
just
design
rated
issues
that
need
some
level
of
validation.
A
A
The
ci
channel
allows
our
users
to
connect
to
their
clusters
from
gitlab
ci
to
the
cluster
on
a
secure
channel
using
the
gitlab
commander's
agent,
so
they
don't
have
to
open
up
the
clusters
and
they
can
still
use
ci
to
connect
to
the
cluster.
We
think
that
this
is
a
really
nice
path
forward
to
even
for
existing
users,
because
they
can
easily,
with
minor
changes,
switch
to
the
gitlab
kubernetes
agent
and
the
ui
register
new
agent.
A
The
other
issue
we
have
then,
are
actually
stretch
goals
like
resource
planning.
We
think
that
for
the
gitobs
model,
the
pool-based
deployments
model
that
must
have
that
we
manage
all
the
resources
in
the
cluster,
even
the
ones
that
are
might
be
removed.
So
it's
a
proper
sinking.
We
are
doing
some
spike
we're
running
a
spike
in
this
area.
First
and
then
we
see
what
developments
are
required
for
that.