►
From YouTube: Auto DevOps Adoption
A
A
A
This
is
the
challenge
we
want
to
solve.
These
are
the
average
stages
per
user.
Gitlab
contains
standard
stages,
and
over
the
last
year
you
can
see
we
hardly
increased
the
amount
of
stages
that
people
used.
This
is
a
big
problem
because
we
know
for
every
stage
that
people
start
using.
We
triple
conversion,
so
gitlab
becomes
way
more
valuable
for
people
and
they
start
becoming
customers.
So
it's
essential
to
get
this
up
and
we
have
not
been
able
to
make
it
and
auto.
A
Devops
is
a
very
important
way
to
do
that,
because
if
you
look
at
the
stages
of
gitlab,
some
are
super
super
popular,
so
create
is
very
popular
and
verify
is
popular
and
auto.
Devops
can
make
it
easy
to
use
package,
secure,
release
and
monitor
and
probably
also
configure
which
auto
devops
is
a
part.
So
if
we
make
this
work,
we
can
get
people
to
embrace
five
new
stages,
which
is
like
it's
gonna,
make
the
stages
for
user
graph
go
totally
up
and
to
the
right.
A
But
if
you
look
at
how
we
currently
use
it,
I
think
I'm
I'm
scratching
the
surface
of
some
problems
that
we
have
normally
what
we
say.
Auto
devops
is
implicit,
like
you,
don't
add
a
gitlab
seattle,
gamma
file
and
then
we'll
just
make
sure
that
auto
devops
works
out
of
the
box
enabled
by
default.
That's
great.
A
However,
in
this
video
of
auto
deploy
to
ec2,
you
can
see
that
people
are
adding
gitlab
seattle
gmo
file
explicitly
so
apparently,
this
implicit
thing
is
is
not
something
that
works
well,
that
we
recommend,
and
if
you
look
at
this
one,
create
a
job
to
stop
ecs
review
apps
again
you
see
that
they,
they
don't
seem
to
be
using
auto
devops.
It
seems
to
be
something
different
from
auto
devops.
So
again,
we're
recommending
hey
people.
A
We
got
this
new
great
functionality
and
that
by
the
way
yeah
forget
about
all
things,
auto
devops,
just
just
use-
you
just
use
this
and
forget
about
that.
Then
we
have
here
a
repository
with
ci
templates
and
I
think
a
lot
of
these.
I
suspect
that
a
lot
of
these
don't
leverage
the
templates
of
auto
devops.
A
Now
it's
hard
for
me
to
tell
because
there's
a
lot
of
files
in
here,
but
I'm
not
sure
they're
all
built
on
the
auto
devops
foundation,
in
fact,
like
the
fact
that
we're
recommending-
oh,
if
you
use,
go
use
this,
and
if
you
use
this,
it's
it
doesn't
reference.
Anything
auto
devops
tells
me
that
again,
we're
not
leveraging
auto
devops
to
do
this,
and
here
is
our
deploy
template.
A
We
mentioned
earlier
again
no
mention
of
auto
devops,
oh,
and
this
is
actually
what
I'm
working
on
with
dimitri
and
city
and
a
few
others,
but
for
the
five
minute
production
app,
we
kind
of
are
working
around
auto
devops,
instead
of
using
it
now
now.
The
problem
is
kind
of
on
me,
but
it
seems
it
seems
to
all
point
in
the
in
the
direction
that
we're
not
using
it
and
also
not
all
of
our
technologies
are
available
on
auto
devops
and
for
some,
for
example.
I
think
it
was
about
some
scanning.
A
It
was
like,
oh,
but
if
we
use,
if
we
use
that
scanner
it
takes
a
while
to
complete.
I
think
what
we
should
do
is
at
least
introduce
people
to
the
scan
and
tell
the
scanner:
hey
scanner
just
run
for
five
minutes
or
something
and
get
people
a
taste
of
what
it
can
do,
and
then
people
should
have
an
easy
way
to
disable
that
limit.
Obviously,
we
don't
want
a
scan
to
run
for
three
hours,
rack
up
the
compute
bill
and
take
a
long
time
for
merge,
requests
to
succeed.
A
But
we
should
find
a
way
where
we
introduce
people
to
technologies,
because
if
we
keep
stages
for
users
below
like
one
and
a
half,
we're
not
a
devops
platform,
we're
just
we're
just
they're
using
one
stage.
They
don't
reap
the
benefits
of
a
devops
platform
and
we
we're
not
delivering
the
value
that
we
intend
to
deliver
to
users
kevin
kenny,
any
any
kevin,
also
invited
and
there's
any
questions
or
things
that
misinterpret
it.
B
No,
I
think,
that's
spot
on.
I
agree
with
both
the
intent
and
the
the
gap.
I
guess
I
think
your
point
of
explicit
versus
implicit
is
the
big
glaring
gap
to
me
that
we
say
this
should
just
happen
and
it
doesn't
and
it
isn't
even
as
inclusive,
and
it's
especially
poignant
to
me
in
the
op
section,
because
when
you
talked
about
those
stages,
the
things
that
it
unlocks
is
the
entire
ops
section.
B
B
I
think
I
would
just
say,
we'd,
like
lulled
ourselves
into
the
belief
that
it's
okay,
if
we
just
give
them
the
composability,
because
that's
how
people
want
to
use
it
anyway
and
forgotten
about
the
mission
of
no.
It
should
be
complete
from
the
starting
point.
And
so
that's
why
you
see
things
like
the
template
includes
coming
out
because
it's
well.
We
know
from
talking
to
users
that
they
don't
that
autodevops
isn't
sufficient
enough,
so
they
end
up
decomposing
it.
So
it's
okay
to
just
give
them
the
composable
bits.
Yeah.
A
A
A
C
B
B
The
contrary
point,
I
guess,
would
be
the
the
one
of
the
concerns
that
you
hear
from
people
who
are
using
auto
devops
is
that
it's
too
heavy-handed
for
when
they
start,
and
so
autodevops
is
where
we
want
you
to
get
your
auto
devops
your
your
software
delivery
pipeline
too.
But
when
I
just
start,
I
don't
want
to
run
a
sas
scan
that
takes
10
minutes
every
time,
so
that
probably
drives
the
like
decomposition
desire.
A
A
That
was
that
was
just
not
what
users
wanted,
but
right
now
I
I
bet
that
95
percent
plus
the
whole
workloads
like
they
don't
even
know
what
auto
devops
is
or
how
to
turn
it
on
and
they've
started
to
customize
their
gitlabs,
the
other
javascript,
because
we
recommend
that
we
have
hundreds
of
templates
and
now
they
wouldn't
know
how
to
enable
that,
and
if
you
want
to
enable
it,
there's
something
decomposed
it's
hard
to
spell
with
all
kinds
of
capital
letters.
I
don't
think
anybody
actually
does
it.
B
Yeah,
I
think
we've
also
entered
into
a
little
bit
of
a
self-fulfilling
prophecy,
where
I'll
use
ori
as
an
example,
but
her
first
shipment
of
let's
allow
people
easily
allow
people
to
deploy
to
aws
was
not,
and
let's
turn
that
on
in
other
demos,
because
that's
actually
there's
so
low
usage
of
auto
devops
that
no
one's
going
to
benefit
from
it.
And
so
she
chose
to
ship
it
as
a
template
and
then
only
later
at
its
auto
devops.
B
But
I
think,
if
you
think
about
as
a
pm
my
ability
to
impact
usage
of
my
part
of
the
product
or
my
feature,
knowing
that
auto
devops
was
this
highly
utilized
thing
that
we
had
all
in.
But
it's
kind
of
like
we're,
making
a
lot
of
local
optimizations
when
the
global
optimization
would
be
get
everyone
using
auto
devops.
And
then
it's
much
easier
to
drive
adoption
of
each
individual
thing.
That
gets
added.
B
B
B
A
A
Yep-
and
I
could
see-
I
think
that
makes
sense,
and
I
could
see
in
your
pipeline
offering
experience
you
see
your
pipeline,
but
you
see
kind
of
steps
in
light
great
that
are
like
off
by
default,
but
you
see
like.
Oh,
you
want
to
turn
on
static.
You
just
click
that
right
and
it's
like
feature
flags
for
the
for
the
different
parts
of
gala
yeah.
B
Yeah,
okay,
yeah.
I
totally
agree.
I
think
it
has
been
a
missed
opportunity
and
we've
probably
fallen
on
the
local
optimization
of
one
of
the
things
we've
done
over
the
last
six
months,
and
this
is
on
me
and
my
direction
was
enforce
that
decomposition
by
saying
one
team
owns
the
build
stage
and
the
secure
teams
own
the
secure
templates,
the
other
teams
own
these,
and
so
that
has
allowed
there
not
to
be
a
singular
owner.
B
A
Yeah,
that
makes
a
lot
of
sense,
and
maybe
we
can
make
sure
that
by
default,
if
you
start
get
lab,
you
push
some
code
to
it,
just
the
things
you
want
to
do
like
if
I
gave
it
aws
credentials
that
you
do
the
the
right
thing
and
it
does
the
things
I.
I
would
probably
like,
like
a
review
app
and
it's
trivial
to
turn
on
stuff,
I
I
might
like,
like
the
security
scans.
B
Yeah
each
one
of
those
are
like,
for
example,
your
the
five
minute
production
app,
more
complex
database
types
is
a
difficult
thing
to
do
in
auto
devops,
because
there
are
these
kind
of
deployment
characteristics,
and
so
we're
always
going
to
have
the
like
known
limitations
of
auto
devops
that
you
currently
have
to
work
within.
But
what
I
think
we
need
to
not
do
that.
We've.
The
mistake
we've
made
in
the
past
is
say:
well
because
there
are
those
known
limitations.
That
means
we
should
just
allow
it
to
splinter
and
instead
say
no.
A
Of
activities
right
exactly
and
other
devops
should
support
the
five
minute
production
app
like
you
should
be
able
to
use
it
to
deploy
a
production
app,
and
I
think
a
lot
of
that
hesitance
to
expand
other
devops
is
because
it's
not
tested
because
it's
not
tested.
If
you
change
it
and
you
break
it,
there's
a
problem,
so
people
have
just
made
new
things
because
you
don't
want
to
break
something.
So
the
solution
is
not
not
to
change
it.
The
solution
is
to
test
it
properly,
so
that
you're
sure
it
doesn't
break.
B
A
No,
it's
not
me,
but
I've.
I've
I've
seen
it
like.
Look
we're
not
testing
this
and
because
we're
not
testing
autodevops
anytime.
A
relevant
change
is
made
to
one
of
the
templates,
with
10
different
code
bases
and
seeing
whether
everything
still
works.
People
are
hesitant
to
touch
the
auto
devops
template
so
where
all
the
changes
should
be
happening
there.
People
have
gone
out
and
does
it
elsewhere,
because
it's
hard
to
understand
it's
hard
to
know.
A
If
you
broke
something
and
if
you
break
something
then
suddenly
auto
devops
is
broken
for
the
few
users
who
are
actually
using
it.
So
untested
code
just
slows
down
innovation
to
the
point
where
everyone
is
doing
it
someplace
else.
So
that's
the
first
thing
to
fix
like
make
sure
that
every
time
one
of
our
templates
is
changed
and
maybe
even
on
every
commit
to
gitlab
we
import,
maybe
it's
10
jobs
with
10
different
repositories,
a
ruby
on
rails
and
a
node
and
a
go
repository.
B
B
A
A
B
Yeah
the
thing-
and
I
agree
in
the
results,
but
the
thing
that
exists
today,
because
autodevops
was
not
successful.
The
the
like
secure
configuration
experience,
which
marcel
highlighted
in
that
video
you
their
experience
for
adding
secure,
is
adding
their
default
templates
instead
of
some
experience
with
auto,
like
turn
on
auto
devops
and
make
sure
these
the
templates
are
on
and
that
we
need
to
kind
of
move
that
experience
into
the
general
pipeline
authoring
experience.
So.