►
From YouTube: Auto DevOps AMA - 2021-04-29
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
Hi,
my
name
is
viktor
knight-
and
I
am
the
senior
product
manager
of
the
configure
group
and
my
group
is
responsible
for
how
to
devops
category,
and
this
asks
me
anything.
This
is
kind
of
a
half
reverse
half
direct.
Ask
me
anything,
because
I'm
super
interested
in
your
insight
so
feel
free
to
ask
me
any
questions.
I
would
do
my
best
to
answer
them,
but
the
same
time
I
will
have
a
set
of
questions
at
the
end
of
this
presentation.
A
As
a
result,
this
presentation
has
a
few
aims.
One
is
to
set
a
common
ground.
Autodesk
is
part
of
gitlab
since
11.0
that's
a
long
time.
Many
of
us
has
opinions
around
it.
Many
of
us
experiences
with
it
and
to
have
fruitful
discussion.
I
would
like
us
to
set
a
common
ground.
I'm
super
thankful
for
everything
that
was
done
without
davos
before
me,
because
I
think
it's
it
showed
that
there's
an
amazing,
huge
market
for
what
auto
devops
is
meant
to
serve.
A
Nevertheless,
we
know
that
it
might
not
be
the
best
fit
for
that
market
today
and
that's
what
we
want
to
improve.
So
thanks
for
everyone
who
ever
worked
on
it,
who
improved
the
templates
and
the
integrations,
because
I
think
it's
an
amazing
product
vision
that
autodevops
has
to
support
the
devops
transitions,
but
anyway,
let's
get
started
so
first,
what's
the
aim
of
the
devops
than
relationships
to
other
similar
looking
initiatives?
Where
does
it
fit
within
gitlab
today
and
then
comes
the
discussion?
A
A
A
If
we
manage
to
increase
include
the
stages
a
given
user
uses,
it's
much
more
likely
that
that
user
will
be
upgraded
to
higher
tier.
Since
then,
we
know
that
this
is
even
more
true
for
stages
per
organization.
So
the
more
stages
a
specific
organization
uses
the
more
likely
it
is
that
they
will
upgrade.
This
is
the
business
perspective
of
off
to
devops,
and
this
is
very,
very
important
because
that
drives
that's
one
of
the
driving
motivations
behind
it.
A
Nevertheless,
also
devops
is
a
product
as
such,
it
has
to
serve
a
user's
need,
and
I
would
like
us
to
focus
on
the
user
need
throughout
the
ask
me
anything.
I
wrote
up
here
a
job
statement
throughout
the
devops.
This
is
its
current
job
statement,
and
actually
I
expect
it
to
stay.
It
is,
as
is
so.
We
can
start
with
this
once
I
have
a
stable
development
and
operations
organization,
I
want
to
follow
davos
best
practices
in
order
to
shorten
the
feedback
loop
and
enable
continuous
learning.
A
If
you
are
familiar
with
what
devops
is
devops
is
about
shorting
feedback
loop
and
about
continuous
learning
and
that's
what
ultra
should
enable
devops
is
a
cultural
change
or
to
devops
is
a
technical
solution
to
support
that
cultural
change.
Make
it
simpler
make
it
less
costly
and
easier
to
digest
for
the
company,
as
many
of
us
are
not
familiar
to
speak
in
terms
of
job
statements,
I
try
to
form
the
same
job
statement
in
terms
of
a
user
story,
which
sounds
as
the
following
as
a
platform
engineer
cto.
A
I
want
all
the
engineers
in
the
company
to
follow
davos,
best
practices
without
the
burden
of
learning
any
tooling
in
order
to
shorten
feedback
loops
from
production
and
enable
learning
here,
by
enable
learning,
I
mean
enable
learning
from
production.
So
it's
not
the
learning
of
the
tool
but
learning
in
their
product
area
and
I'm
going
to
unpack
this
job
and
the
user
story.
A
First
of
all,
the
persona
in
the
user
story
is
platform.
Engineer.
Slash,
cto
cto
is
not
really
persona
but
never
mind.
I'm
not
speaking
about
the
dev
of
persona
here,
because
in
reality
it's
it's
not
a
persona.
It's
a
role.
We
have
software
engineers
as
a
persona
and
we
have
application
operators
as
a
persona.
A
The
software
team
for
success
for
success
in
terms
of
devops
and
the
cto
comes
to
this
in
the
sense
that
they
are
the
sponsor
of
this
whole
devops
transition.
Usually
so
the
cto
is
only
relevant
because
he
sponsored
this
transition.
He
pays
the
platform
engineer
to
do
this
job
and
it
should
be
easy
for
the
platform
engineer
to
develop.
A
That
was
best
practices,
including
a
bit
of
gitlab
flavor
devops
is
not
a
solution.
It's
a
culture,
that's
very
important.
We
have
to
understand
that,
and
we
have
to
stick
with
that
and
gitlab.
What
we
can
do.
We
can
support
that
cultural
change.
We
can
enable
that
cultural
change.
We
can
decrease
the
cost
of
that
change.
We
can
make
it
easier
to
adopt
the
best
practices
that
come
with
that
culture
change.
A
A
few
things
that
are
related
to
devops
here
is
that
there's
an
increased
team
ownership.
The
team
owns
the
processes
from
code
to
production
and
it
even
owns
the
production
deployments.
Usually,
there
is
very
strong
argument
around
version
controlling
including
infrastructure
and
winter
flows.
These
are
owned
by
the
team
as
well.
Security
is
part
of
that
process.
A
There
are
many
of
our
customers
who
don't
want
security
to
be
part
of
the
team's
ownership,
but
if
we
think
about
devops,
we
have
to
think
with
security
in
mind
as
well
review
apps.
Now
we
are
getting
more
to
get
flavor
review.
Apps
enable
really
easy
feature
acceptance
and
on
the
thousands
of
interviews
I
run
many
people
are
asking
for
review
apps
if,
whatever
reason
is
not
accepted
accessible
for
them,
various
advanced
various
advanced
deployment
strategies
are
requirement.
A
For
the
same
reason,
the
team
wants
to
own
this
and
it's
their
job
to
make
the
deployments
to
happen
deployments
nevertheless
are
automated.
Everything
is
automated.
Actually,
the
deployment
target
should
be
undefined
from
a
framework
level.
It
should
be
able
we
can.
One
should
be
able
to
use
kubernetes
as
deployment
targets
or
one
of
the
app
stores
or
ecs
it's
up
to
the
user
to
decide
and
we
can
provide
some
defaults,
but
it
shouldn't
be
our
decision.
A
So
there's
a
bit
more
about
what
what
devops
is,
and
you
can
read
that,
but
the
basic
idea
that
we
want
to
serve
is
these
jobs
to
be
done.
Once
I
have
a
stable
development
and
operations
organization,
I
want
to
follow
devos
best
practices
in
order
to
shorten
the
feedback
loop
and
enable
countries
learning.
This
is
the
job
statement
that
we
want
to
fulfill.
This
is
the
user
problem
that
we
want
to
solve.
A
Okay,
now,
of
course,
many
areas
of
gitlab
work,
especially
on
stages
per
users,
digital
organization
initiatives,
so
we
have
to
position
all
the
devops
very
well
in
this
area.
A
I
have
an
issue
here
open
from
the
growth
team
that
describes
very
well
how
they
think
about
it
and
auto
devops
especially
comes
into
play
when
we
think
about
continuous
onboarding.
You
might
said
come
on
this,
that
that
just
means
how
to
level
you
should
enable
the
user
to
use
other
stages
as
well,
and
then
they
got
it
nope.
I
think
autos
is
very
different
from
that,
because
auto
levels
is
automatic,
so
it's
the
user
just
gets
it
without
any
learning
without
any
setup.
A
That
setup
might
be
done
by
the
platform
engineer,
but
not
by
the
software
developer
itself.
When
we
start
to
speak
about
personas
or
it
might
be
done
by
git
lab,
but
again
not
by
the
software
engineer,
it
should
be
automatic
for
the
software
engine
as
much
as
possible,
and
then
the
growth
themes
topics
still
still
valid,
that
the
platform
engineer
has
to
learn
about
this
toolset.
A
Then
the
other
similar
initiative
is
pipeline
authoring
because
you
could
author,
the
autodevops
pipelines
today
on
your
own
and
many
of
our
users,
who
are
not
satisfied
without
knox
offerings
what
they
do.
They
write
their
own
templates
and
they
tell
them
when
they're,
using
things
that
they're
actually
autodesk
users,
just
they
have
their
own
custom
ultimate
templates.
A
So
this
is
so
pipeline
is
again
a
related
area,
but
it's
very
different.
It's
much
minor,
it's
not
about
making
it
automatic
and
we
basically
just
have
to
integrate.
Rather,
if
somebody
is
an
auto
user,
it
should
be
clear
to
them
and
probably
the
pipeline
string
can
help
a
lot.
The
outer
level
experience
and
support
our
users
to
use
these
devil's
best
practices
as
well.
A
Then
there's
the
five-minute
production
app.
I
don't
want
to
speak
much
about
it
because
they
have
actually
a
separate
section
with
the
resp
relationship
dual
to
devops.
I
think
these
are
very,
very
similar
topics,
except
that
we
are
not.
A
A
And,
finally,
I
want
to
mention
our
amazing
solution,
architect
who
provided
me
a
ton
of
useful
feedback
in
youtube
videos,
some
in
live
chats.
I
mean
issue
comments
in
all
kinds
of
various
ways
about
how
what
actually
auto
devops
today
is,
which
is
a
set
of
best
practice
templates
that
users
can
learn
from,
and
it
gives
a
hint
that
I
might
be
able
to
use
gitlab
for
all
these
things.
A
So
this
is
where
we
start
from.
This
is
where
we
are
right
now,
and
this
is
where
optidos
fits
to
fulfill
the
job
that
it's
meant
to
fulfill
and
then,
let's
get
started
with
discussion.
When
I
wrote
up
that
job
statement,
I
had
to
answer
all
these
questions
and
you
can
see
them
reflected
in
the
job
statement.
A
At
the
same
time,
I
having
more
concrete
answers
on
how
I
am
regionality
levels,
but
before
I
share
that
vision
with
you,
I'm
super
happy
that
some
of
my
ngs
have
competing
visions
as
well,
and
I
would
like
to
hear
your
ideas
around
this.
How
do
you
engage
now
to
devops?
How
do
you
imagine
gitlab
to
support
users
devops
requirements
in
five
years,
for
example,
and
together
with
this
comes
the
idea?
Who
is
the
target
audience?
Who
is
the
sponsor?
Who
will
buy?
Who
will
pay
for
this?
A
Who
will
be
the
primary
user
and
who
will
consume
it?
To
give
you
an
idea
of
these
three
different
questions,
if
you
think
about
the
children
and
their
parents,
we
have
a
hard
working
mother
who
buys
the
food
a
really
family-friendly
father,
who
makes
an
amazing
lunch,
and
then
we
have
the
children
who
eat
that.