►
Description
Viktor Nagy (Product Manager, Configure), Dov Hershkovitch (Product Manager, Pipeline Authoring) and Nadia Sotnikova (Product Designer, Pipeline Authoring) discuss the vision for workflow automation at GitLab based on the outcomes of the Auto DevOps Design Sprint.
https://gitlab.com/groups/gitlab-org/-/epics/5939
A
Okay,
let
me
share
my
screen
so
yeah,
where
we
are
with
the
design
sprint
and
what
this
print
is
about.
First
of
all,
I
won't
go
through
all
the
details
just
very
quickly.
At
the
very
beginning,
we
collected
challenges
around
the
current
auto
devops,
offering
some
of
them
are
related
related
to
also
devops.
A
Some
of
them
are
more
related
to
so
I
would
say
our
current
pipelines,
or
even
the
experience
around
pipelines,
so
it
might
be
interesting
to
you,
though,
and
then
we
decided
whatever
we
want
to
focus
on,
and
the
long-term
goal
in
the
end
became
this
one
that
in
two
years
time
also
devops
is
used
in
75
percent
of
new
projects
without
the
development
teams,
realizing
that
they
are
using
it.
Each
auto
setup
constantly
follows
best
practices
for
devops
that
someone
defined
using
a
set
of
official
and
community
components.
A
I'm
going
to
break
this
down
a
bit
because
there
are
many
many
interesting
pieces.
One
is
that
development
teams
realizing
they
are
don't
even
realize
they
use
it,
which
means
it's
a
it's
a
core
offering
within
gitlab.
So
it's
not
a
special
name.
It's
not
a
special
feature,
but
basically
that's.
I
would
call
it
that
this
is
the
main
approach
to
automation
within
gitlab.
A
The
other
thing
is
that
the
this
best
practice
is
set
up
by
someone
it's.
It
could
be
a
software
engineer
at
the
project
level,
but
it
could
be
as
well
a
platform
engineer
at
a
group
level
who
sets
up
these
best
practices
and
there
are
official
and
community-based
components
that
they
they
can
use
to
build
out
these
pipelines.
A
So
this
is
this
is
the
the
target
where,
where
we
would
like
to
get
the
goal
of
autodevops
as
we
described
it-
and
you
can
already
see
here
that
it's
really
closely
related
to
to
a
pipeline
definition,
not
necessarily
altering,
but
how
we
define
pipelines,
and
then
I
think
we
even
missed
this
part
kind
of
yeah.
They
the
biggest
challenges
we
see.
How
can
we
do
things?
I
think
a
very,
very
useful
part
was
the
lighting
demos
and
I
would
more
like
just
recommend
watching
them.
A
I
might
go
back
to
the
concepts
first,
but
where
we
are
right
now
is
we
are
at
the
end
of
the
user
test
flows
and
that's
the
beginning
of
the
storyboarding
in
terms
of
the
concepts.
The
the
chosen
concept
was
this
one
which
basically
says
that
either
the
start
of
the
project,
or
once
your
project
is
already
there,
you
can
click
a
button
to
set
up
deployment,
which
provides
some
bizarre
like
experience
here.
A
It
says
that
the
docker
file
is
found
and
you
can
still
add
some
database,
but
actually
this
wizard
generates
code
and
that
code
is
stored
in
your
project
under
your
project
somewhere,
and
there
might
be
even
group
level
pipeline
or
definition
of
of
this
workflow
that
can
just
be
customized
at
the
project
level
or
it
can
be
restricted
or
enabled
at
the
project
level.
So,
like
here's,
the
security
limiter
which
cannot
be
overwritten
and
then
there
is
database
which
can
be
accessed
by
project
one
and
then
deployments
are
triggered
on
various
events.
A
A
A
I
guess
that
is,
it
is
to
have
group
level,
infrastructure,
dashboard
or
or
some
kind
of
dashboard,
and
all
these
pipelines
where
we
can
see
if
projects
are
compliant
with
the
develop
standards
we
have
and
we
can
manage
group
level
templates
and
and
edit
all
the
group
level
settings
there.
So
this
this
was
the
concept,
and
then
we
came
up
with
user
test
flows.
A
A
A
C
Yeah,
so
there's
definitely
still
lots
of
gaps
in
the
storyboard,
but
I'll
just
go
over
the
things
that
I
highlighted
on
the
different
steps.
So
I'm
looking
at
a
situation
where
there's
a
group,
so
an
admin
first
creates
a
group
for
the
organization
and
then
they
create
different
projects
in
that
group.
So
once
time
comes,
admin
creates
a
new
project
in
that
group
and
by
default
all
the
devops
will
be
turned
on
for
that
project.
C
C
Maybe
we
want
it
to
be
on
by
default
and
you
would
have
to
go
to
settings
to
turn
it
off,
but
I
thought
it's
good
to
kind
of
give
that
option
and
maybe
at
the
same
time,
in
the
organization
some
other
projects
are
created,
so
maybe
there's
a
security
and
compliance
team.
That
also
sets
up
some
workflows
and
they
could
set
up
compliance
pipelines,
for
instance,
so
that
would
be
already
set
up
for
that
project.
C
So
they
would
get
some
basic
other
devops
features
that
we
know
can
work
by
default
without
any
additional
input
from
the
user,
or
perhaps
something
that
we
can
just
infer
from
the
content
of
their
project,
and
they
might
also
get
something
that
is
set
up
on
the
group
level
or
not.
So
once
the
repo
is
set
up,
whoever
is
responsible
for
setting
up
automated
workflows
in
the
organization
they
go
to
the
dashboard
this
mystical
place.
I
try
to
think
what
it
could
be.
C
Maybe
it
will
merge
like
in
your
in
your
meeting
with
mikhail
you
attached
about
it,
touched
upon
it
a
little
bit,
so
you
would
see
the
auto
devops
pipeline
there
and
you
would
be
able
to
configure
it
further.
If
not,
there
would
be
some
kind
of
empty
state,
and
maybe
you
would
get
an
option
hey
do
you
want
to
enable
auto
develops,
and
this
is
what
it
does
for
you.
Or
do
you
want
to
set
up
some
like
a
custom
pipeline?
C
A
C
C
So
maybe
there
would
be
some
kind
of
progress
indicator
saying
that
hey
you
already
have
all
of
those
things
set
up
and
then
you
can
also
set
up
like
a
deployment
or
security,
jobs
and
whatnot,
and
perhaps
you
would
also
get
a
visualization
of
the
jobs
that
are
already
there
and
then
a
way
to
set
it
up,
but
whatever
like
it,
doesn't
really
matter
how
it
looks
but
and
yeah.
Just
I
pasted
some
screenshots
here
for
maria.
C
I
guess
to
give
some
more
context
like
where
this
idea
came
from,
because
right
now,
what
we're
doing
at
pipeline
authoring
with
the
pipeline
editor,
we
are
creating
a
place
for
like
someone
from
the
platform
team
or
a
devops
engineer,
to
go
there
and
to
manage
their
pipeline
configuration.
So
that's
where
they
can
see.
All
of
their
pipeline
architecture
and
we
will
be
adding
more
and
more
features
that
make
it
easier.
So
now
you
can
see
you
can
view
your
merge
gmo
with
all
of
the
includes
and
there's
the
linter
and
whatnot.
C
C
That's
great
because
it's
important
yeah!
So
basically
my
idea
is
to
have
the
single
place
where
all
the
devops
and
ci
in
some
magic
way
are
able
to
coexist
and
complement
each
other
in
a
way
so
yeah.
Some
questions
here
like
what
happens
with
the
compliance
pipeline
when
other
devops
is
enabled.
How
do
they
interact
because
this
feature
already
exists
and
it's
a
ci
pipeline,
like
a
compliance
ci
pipeline
that
just
gets
merged
with
your
ci
amol
and
yeah
the
competition
between
other
devops
and
ci
so
yeah.
B
C
Your
workflow
further
and
you
would
be
able
to
just
click,
click
setup,
workflow
or
set
up
some
like
subspecific
deployment,
for
example,
and
that
triggers
this
wizard
workflow,
where
you
just
get
a
model
that
pops
up
and
asks
you
for
whatever
inputs
that
are
necessary.
Maybe
first
you
would
choose
a
workflow
type
and
then
yeah.
You
just
answer
different
questions.
C
Yeah,
so
actually
I
don't
know
if
this
is
like
the
next
step,
but
someone
else
added
this.
That
workflow
builder
generates
the
autodesk
yaml
code,
oh
in
the
editor
yeah.
So
then
you
can
customize
the
workflow,
so
it
would
open
up
the
editor
and
these
would
be
kind
of
in
the
same
place.
So
you
would
be
able
to
see
the
graph
to
see
what's
enabled
and
then
also
access
the
editor
from
the
same
page
kind
of
like
now.
We
have
the
pipeline
editor.
C
We
have
the
text
editor
and
we
have
a
visualization
that
is
now
static,
but
in
the
future
maybe
you
could
also
interact
with
it
and
next
step.
So
you
would
customize
the
workflow
in
the
editor
and
then
you
can
commit
to
main
branch
and
just
see
the
pipeline
run
from
from
that
same
dashboard
or
you
might
commit
the
changes
to
a
new
branch
and
open
nmr
and
that
kind
of
it's
a
bit
of
a
different
workflow.
C
But
that's
probably
what
what
will
happen
most
of
the
time
like
you
create
mr
to
to
review,
and
there
we
would
have
to
show
the
pipeline
in
like
the
mini
pipeline
graph
and
whatnot,
so
the
pipeline
that
runs
it
should
be
tracked
kind
of
in
in
github
ui.
The
same
way
that
ci
pipeline
is
tracked
so
from
from
the
user.
Experience
point
of
view
like
once
the
pipeline
runs,
the
autodesk
pipeline
is
just
a
pipeline,
so
we
kind
of
we
should
treat
it
the
same
way.
C
So
I
just
added
this
here
that
you
would
be
able
to
go
to
like
the
pipelines
page
and
view
the
pipeline
there
and
so
on,
and
then
yeah
changes
to
the
pipeline
configuration
are
merged,
are
merged
to
the
main
branch
and
the
code
is
generated
in
the
autodubs
folder
in
their
project,
and
that
was
kind
of.
As
far
as
I
got.
A
Yeah,
could
you
go
back
to
the
automation
menu
because,
that's,
I
think,
that's
where
we
we
we
can
get
rid
of
the
competition
between
ci
and
and
also
as
well,
and
the
question
is,
which
is
that?
What
what
what
we
speak
about
here
is
really
is
really
just
automation
and
I
think
historically,
we
approach
it
from
the
point
of
view
of
ci,
because
that's
what
exists
at
gitlab
for
a
long
time
and
that's
what
what
is
at
the
core
of
gitlab.
A
But
the
topic
is
just
automation
and
when
we
speak
about
autodevops,
that's
just
an
aspect
of
automation
as
well,
and
the
question
we
should
answer
here
is
it's
very
interesting:
how
you
speak
about
pipelines
that
there
is
a
compliance
pipeline.
There's
an
also
doubles
pipeline,
there's
a
ci
pipeline,
so
these
are
kind
of
like
just
pipelines
in
parallel.
A
A
A
A
A
Yeah,
on
top
of
the
automation,
because
all
of
these
actually
use
runner-
and
today
we
have
the
the
api
for
this.
Automation-
is
gitlab
ci,
the
yamo
definition,
and
I
think,
that's
in
a
large
sense
that
that
should
remain,
I
would
say,
but
even
as
the
security
team
does,
they
kind
of
circumvent
it
by
creating
the
compliance
pipelines.
B
Yeah
I
mean
I
agree
about
your
comments,
comment
about
the
limitation
of
yammer,
but
I
would
also
look
at
that
in
the
perspective
of
maybe
it's
a
bit
different
that
what
we
just
discussed-
maybe
it's
maybe
not
but
like
a
pipeline-
is
a
pipeline
and
it
doesn't
matter
if
it's
like
a
not
onto
devops,
if
it's
ci,
if
it's
even
cd
and
so
like
there
are
different
flavors
of
pipelines.
So
a
lot
of
the
features
or
solutions
that
we
are
building
for
ci
will
be
relevant
for
auto
devops
for
compliance
for
for
for
cd.
B
So
I
think
we
should
make
sure
that
the
experience
for
the
user
like
regardless,
if
they
are
following
the
auto
devops
track
or
following
ci
their
own
ci,
would
be
kind
of
similar.
Maybe
there
will
be
some
nuance:
some
things
will
not
work
out
of
the
box.
It
will
not
work
at
all
and
when
we
are
choosing
like
one
like,
for
instance,
I
can
give
an
example.
We
have
the
pipeline
editor
and,
as
nadia
mentioned,
it
has
like
the
visualization,
the
lean
the
view
mirror
gmail
and
the
edit
so
maybe
like.
B
If
I'm
a
user
that
and
and
I
enable
a
lot
of
devops-
I
won't
be
able
to
edit
the
pipeline
or
maybe
not
right
away,
but
I
should
be
able
to
visualize
it
see
how
it
looks
see
even
the
linters,
even
the
view,
merged
yaml
the
dish
without
the
ability
to
to
look
at
it.
And
obviously,
when
you
go
to
the
pipelines
you
can,
when
you
go
to
the
job,
you
should
see
the
same.
B
You
see
the
same
view,
maybe
with
with
different
label
like
this
is
auto
devops,
and
this
is
why
you
know
certain
amount
of
features
are
unable
to
would
not
work.
But
in
terms
of
like
the
the
user
experience,
I
do
see
us
like
morris
following
the
same
path
and-
and
I
think
it's
important-
that
we
need
to
be
cognitive
of
of
the
fact
that
there
are
different
flavors
and
every
time
we
develop
a
solution.
We
need
to
think
about.
Okay.
What
happened
in
the
case
of
you
know
auto
devops.
B
What
happened
in
the
case
of
compliance
every
time
we
develop
a
feature
either
it's
from
config
or
for
pipeline,
nothing.
I
think
we
actually
start
doing
that,
like,
for
instance,
in
the
in
the
empty
page
in
the
pipeline.
We
already
start
talking
about
okay,
what
happened
with
if
you
have
auto
devops
okay,
so
I
think
this
is
something
that
we
start
asking
like
every
time
that
we
are
building
features
into
into
our
solutions.
C
Yeah
same
full
agreement,
so
so
regarding
the
storyboard
for
me
personally,
my
most
glaring
gap
in
understanding
of
how
it
all
will
work
is
the
technical
implementation.
Because,
from
the
discussions
that
I
listened,
listened
to,
that
you
had
with
me
kyle,
it
seems
like
there's
kind
of
like
not
not
we're
not
fully
agreed
on
what
path
to
follow
there.
So,
maybe
victor,
can
you
elaborate
a
little
bit
on
that.
A
Yeah,
basically,
what
I,
what
I'm
going
to
share
with
you
now
is,
is
what
I
came
up
at
today.
So
it's
I
haven't,
discussed
this
specific
aspect
with
mikhail.
That's
in
the
link
that
I
shared
with
you
on
over
slack,
and
the
idea
is
that
so
amica
came
up
with
a
proposal
for
automatable
devops
that
proposes
a
domain-specific
language,
but
actually
what
it
would
do
is
from
an
imperative
code,
that
is
the
domain-specific
language.
We
generate
a
declarative
code
and
the
declarative
code
is
passed
to
the
pipeline.
A
So
that's
the
pipeline
definition
in
the
end.
It's
so
that's
yeah,
exactly
yeah
exactly-
and
this
is
this
is
interesting.
Part
of
the
current
ci
syntax
is
not
purely
decorative,
so
it's
a
mixture
of
declarative
and
imperative,
but
this
is
just
minor.
These
are.
We
are
not
that
far
away
from
what
we
have
today.
Just
think
about
that.
A
The
his
idea
is
to
create
something
very
similar
to
what
we
have
already
today
and
then
we
pass
that
yamo
to
the
runner
that
this
is
my
pipeline
run
the
jobs,
but
he
has
another
hidden
argument
and
and
actually
form
from
from
my
point
of
view,
that's
the
most
important
argument,
which
is
that
the
current
approach
to
pipeline
that
they
are
directed
essay
graphs
is
not
good
enough
for
deployment
pipelines,
because
dogs
cannot
have
loops.
That's
why
they
are
acyclic.
So
it's
by
definition,
and
in
the
case
of
deployments
you
often
want
loops.
A
You
want
to
have
retries,
you
want
to
have
timeout
conditions
and
then
a
separate
pipeline
should
be
started
when,
when
a
deployment
times
out,
so
you
have,
you
need
a
more
more
general
modeling
idea
and
he
found
patreonettes
for
that.
To
give
you,
if
you
are
not
familiar
with
patriots,
I
was
not
a
week
ago,
just
think
about
direct,
basically
graphs
without
a
cyclic,
so
kind
of
any
kind
of
graph.
Just
they
are
very
defined
graphs,
so
they
have
a
beginning
and
an
end,
and
and
that's
it.
A
A
So
this
is
just
a
different
approach
to
what
we
have
today,
but
these
are
basically
two
approaches
for
very
complex
workflows
and
I
think
that
for
us,
the
patinator
approach
would
be
great
because
there
we
can
use
the
whole
integrated
experience
of
gitlab
and-
and
the
only
thing
is
that
we
have
to
move
away
from
the
essay
click
graphs
that
we
have
today.
I
mean
not
move
away,
but
but
extend
to
support
patronets,
not
just
asically
graphs,.
A
A
It's
like
it's
a
user
experience,
but
really
the
second.
The
next
question
is
that
what
will
that
emerald?
Look
like
whether
it's
purely
decorative
yamo
as
mikhail
emergency,
with
the
dslr
that
generates
that
yamo
or
it's
a
mixture
that
we
have
today,
which
I
would
recommend
to
change,
because
it
won't
scale
well
in
the
longer
term?
But
that's
a
that's
an
implementation
detail.
I
would
say.
A
A
B
D
B
A
A
B
B
I
assume
that
we
want
our
pipelines
to
be
more
dynamic
and
in
certain
condition,
we'll
do
we'll
do
x,
amount
of
action
in
another
condition,
we'll
do
other,
and
I
mean,
as
I
mentioned,
we
need
to
dive
into
that
mode,
but
I
just
wonder
like
if
there
is
a
way
for
us
to
to
introduce
a
more
dynamic
pipeline
in
order
to
support
the
deployment-
maybe
maybe
not,
but
I'm
just
I.
I
need
to
ask
this
question
like
it.
A
Might
it
might
be
that
the
thing
is
I'm
I'm
not
sure
if
you
are
speaking
today
about
the
about
the
design,
splinter
or
something
different.
But
what
I
would
say
here
is
that
it
might
happen
that
we
would
so
even
taking
even
forgetting
about
petronets
and
all
of
that
and
just
thinking
about
the
stages
and
the
dag
approach
to
gitlab
ci.
A
It
might
be
that
it
could
be
better
to
have
two
alternative
products
as
gitlab
ci
and
at
the
beginning.
You
have
to
say
that
this
is
kind
of
something
like
a
kind
variable
that
says
that
this
is
a
stages
kind,
and
then
it
follows
just
that
syntax
or
this
is
a
dark
style,
and
then
it
just
falls
that
syntax
and
because
what
we,
what
we
do
today,
as
you
said,
we
just
mix
things
in
there
and
it
seems
like
a
huge
chaos.
A
Actually,
at
least
to
me,
I
I'm
pretty
happy
user
of
gitlab
ci,
because
I
try
to
leverage
it
as
much
as
possible
and
I'm
always
lost
by
the
many
features
there
are,
and
probably
just
by
simply
saying
that
you
either
use
stages
or
dogs.
It
could
be
a
lot
simpler,
actually
and
then
there
could
be
a
third
kind,
which
is
the
even
based
or
whatever.
B
Either
that
or
like
it
will
be
like
a
new
like
a
new
like
versioning
of
of
of
yammer.
I
know
this
is
something
that
is
been
going
on
about
like
this
idea
is,
is
out
there
for
like
couple
of
years.
We
still
didn't
find
like
the
right
justification
of
why
we
should
maintain
like
two
types
of
versioning
of
of
yaml
or
ci.
Maybe
this
will
be
like
the
case
where
we
say.
Okay,
if
you
want,
like
you
know,.
A
B
B
Yes
or
no
I
mean
it
is
confusing,
but
still
it's
it's,
it's
still
manageable.
It's
still
manageable.
I
I
would
say
like
to
add
another.
One
will
probably
be
yeah
will
be
an
overhead,
but
it
I
it's
still
manageable
because,
like
I
see
it,
for
my
users
they
are,
they
are
mixing
it
and
we
are
trying
to.
A
B
Like
what
I
was
thinking
like
th
this
this
this,
along
with
like
there
is
also
one
additional
feature
that
I
know
something
that
our
users
want
is
like
conditional
includes,
so
you
can
like
add
different
pipeline
based
on
different
tools.
The
database
so
like,
if
you,
if
you
extend
it,
it
will
be
more
dynamic,
so
dynamic
child
pipeline
and
conditional
include
would
probably
provide
you
with
the
flexibility
to
do
like,
and
then
I'm
just
it's
just
my
hypothesis.
We
need.
B
C
Yeah
for
me,
from
the
user
experience
point
of
view
having
three
ways
to
like
architecture
pipeline:
I'm
actually
not
too
bothered
by
it
as
long
as
we
have
a
clear
definition
of
like
what
we
recommend
this
for
so
if
we
can
provide
those
three
options,
I
actually
quite
like
this
idea
that
you
mentioned
victor
just
having
some
way
to
like
toggle
or
it's
like
you're
in
this
mode
now
you're
in
that
mode
now,
and
we
just
need
to
make
it
clear
what
this
mode
is
for.
So
like
a
stage
pipeline.
A
Yeah,
actually,
the
very
another
thing
that
that
dove
mentioned
is
that
it
might
happen
that,
at
least
at
the
beginning,
that
everything
is
supported
by
a
kind
of
a
more
advanced
pipeline.
Is
that
I,
I
think,
that's
that's
what
we
should
do,
because
it
would
be
just
foolish
to
to
ignore
the
existing
work
that
was
already
done
around
gitlab
pipelines,
and
so
we
just
have
to
build
up
on
that.
That's
that's!
That's
pretty
clear
to
me.
A
A
A
Let
me
let
me
share
my
screen,
because
then
I
can.
I
can
show
what
I'm
mm-hmm,
if
a
prototype
for
sure.
We
have
something
like
that.
So
I
think
that
these
first,
these
first
things
are,
are,
I
would
say:
okay,
I
would
say
here's
why
what
you
said
that
it's
enabled
by
default
and
the
best
is
that
you
can
opt
out
from
autodevops.
A
A
A
C
A
A
A
A
That
was
that
was
his
idea,
but
this
is
a
very
different
topic
again.
Okay,
so
basically
it's
a
single
pipeline.
Just
in
that
case,
I
think
this
is.
This
is
again
the
question
here
is
like
what
is
the
scope
of
autodevops,
because
today
autodevops
is
your
single
pipeline.
That
does
everything
for
you,
and
this
is
where
the
problems
actually
start
for
auto
devops,
often
that
for
many
teams
the
development
team
is
responsible
to
generate
the
container
and
once
the
container
is
generated,
another
team
is
responsible
to
make
sure
that
that
container
will
be.
A
Deployed
and-
and
this
is
kind
of
how
the
responsibilities
are-
are
set
up
around
the
team
and
without
devops
pipelines.
We
just
say
that
development
team
is
responsible
for
everything
from
beginning
to
the
end,
and
the
thing
is
that
they
don't
know
how
to
do
the
end.
They
don't.
They
know
how
to
generate
a
container,
but
they
have
no
idea
about
the
deployment
aspect,
which
could
mean
that
the
deployment
is
very
similar
to
the
compliance
pipeline
just
run
at
the
end
of
your
pipeline.
C
A
C
B
By
the
way,
this
is
something
we
can
actually
leverage
an
existing
feature,
and
now
remember
that,
like,
if
I
remember
correctly,
the
best
practice
for
the
compliance
pipeline
is
to
run
it
on
the
on
the
pre
stage,
which
always
come
at
the
beginning,
and
there
is
also
a
post
stage,
which
is
always
always
always
covered
in.
So
we
can.
D
A
B
A
C
So
I
mean
it
can
be
called
whatever
setup
workflow.
Actually,
there's
no
button.
I
don't
know
I
just
made
it
up
after
I
made
the
sketch.
So
the
idea
here
is
that
you
can
trigger
a
wizard
by
just
clicking
the
ui
like
set
up
a
deployment
or
set
up
a
job
or
hopefully
we
will
be
able
to
give
like
some
suggestions.
C
So
someone
who's
completely
new
and
doesn't
really
know
what
is
available.
So
they
would
see
some
options
in
the
ui
or
maybe
there
will
be
a
generic
button
set
up
a
workflow
and
then
that
prompts
a
wizard
where
you
can
choose
which
what
kind
of
workflow.
So
if
you,
if
you
scroll
to
the
next
section
of
the
of
the
storyboard,
so
you
would
be
able
to
choose
the
workflow
type,
for
instance.
A
C
Yeah,
so
these
were
sort
of
placeholders,
but
I
also
it's
a
bit
confusing
because
in
the
sketch
it
says
that
compliance
is
not
set
up,
but
we're
imagining,
for
the
sake
of
the
user
flow
that
it
is
actually
set
up
on
the
group
level,
but
for
a
project
that
doesn't
have
it
set
up,
maybe
there
would
be
an
option.
So
if
it's
you
know,
if
nothing
is
set
up
on
the
group
level,
maybe
you
would
okay,
that's
probably
not
relevant.
Forget
compliance
set
up
on
project
level.
A
The
reason
why
I'm
asking
is
more,
I
I
got
it
that
these
are
more
like
placeholders,
but
it's
really.
I
think
it's
a
very
important
thing
that
if
we
can
that
the
idea
here
is
that
we
show
some
kind
of
a
clue
to
the
user
that
you
can
use
the
pipeline
for
compliance.
You
can
use
the
pipeline
for
integration.
You
can
use
the
pipeline
for
deployment
as
this.
This
was
the
message
to
me.
Yeah.
B
C
C
Yeah
yeah,
so
the
idea
here
in
this
markup,
the
idea
would
be
that
he
would
click
customize
and
then
that
would
take
you
to
the
editor
that
shows
you
whatever
you
currently
have
in
the
yaml
and
then
you
would
be
able
to
just
put
whatever
you
want
in
it.
So
if
you
know
what
you
want
and
the
ui
doesn't
give
you
that
option,
there
would
be
an
option
to
just
set
up
whatever
you
want
and
the
options
that
we
do
provide.
C
They
have
to
be
based,
probably
on
some
kind
of
research
like
we
need
to
figure
out
what
are
the
top
things
that
clarissa
and
the
project
would
be
interested
in
for
their
pipeline
and
also,
I
guess,
yeah.
So
you
know
like
setting
up
an
integration
setting
up
a
compliance.
These
are
again
kind
of
different
buckets
of
workflows
that
someone
would
be
able
to
set
up.
A
Yeah,
okay,
I'm
still
get
starting
to
understand
yeah.
In
that
case,
what
I
would
what
I
would
recommend
having
here
is
just
a
minor
modification
which
would
be
that
even
when
I
already
set
up
a
compliance,
it
would
stay
here
and
it
would
just
become
green
and
deployment
would
be
still
red,
because
there
is
no
complaint,
no
deployments,
and
I
can
even
say
that.
A
C
B
A
C
A
B
B
A
B
C
So
I'm
working
on
it,
this
milestone,
probably
will
carry
over
to
the
next
milestone
network,
but
currently
dove,
and
I
are
doing
some
more
problem-
validation
with
large
customers
to
better
understand
their
specific
workflow,
how
they
manage
template
libraries
at
the
enterprise
level,
because
it's
a
very
important
feature
like
a
lot
of
larger
organizations,
have
a
need
for
that
and
how
we
handle.
That
will
definitely
affect
how
we
handle
gitlab
templates
and
community
contributed
templates,
so
the
user
experience
that
we
provide
it
should
be
kind
of
the
same
for
all
of
them.
C
It's
just
gonna
be
like
different
types
of
templates
and
in
terms
of
implementation.
There
are
like
different
ideas.
Dolph
can
probably
talk
a
bit
more
about
that,
like
there
was
even
an
idea
to
use
package
registries
for
template
libraries,
and
then
an
mvc
kind
of
idea
is
just
to
have
projects
in
a
group,
and
this
is
what
we
see
our
large
customers
do
already.
C
So
they
have
like
a
platform
team
that
just
maintains
this
separate
project
within
the
group
that
has
all
of
their
templates
and
templates
have
like
readmes
and
descriptions
and
whatnot,
and
then
they
write
custom
scripts
to
enforce
those
templates
across
their
project.
So
this
is
what
the
compliance
pipelines
feature
solving
for
kind
of,
but
where
we
are
right
now,
they're
like
we
don't
have
any
mockups.
Just
in
this
milestone.
Our
goal
is
to
like
get
a
better
understanding
into
what
the
workflow
should
look
like.
C
So
we
want
to
first
have
some
more
data
points
into
what
specifically
like
workflows
and
what
is
the
team
structure
and
so
on
and
like
what
are
the
different
permissions
that
the
users
need
from
different
teams
and
document
that
and
then
that
will
inform
the
user
flow
that
we
will
create
and
create
visionary
mock-ups
for
probably
like
towards
the
middle
of
now.
We're
in
14,
so,
like
middle
of
14.1,
probably
will
have
the
mock-ups.
B
B
C
Least
at
least
for
one
we
deal
with
just
like
yaml,
so
if
you
just
copy
code,
if
we
start
to
put
some
abstraction
on
it,
then
maybe
there
will
be
some
slight
difference.
Like
some,
you
know
like
you
will
be
able
to
pick
between
like
pipeline
templates
or
job
templates
and
like
pipeline
template.
Maybe
there
will
be
slightly
different
options,
because
the
use
case
is
different
for
a
whole
pipeline
template
and
for
a
job
template
that
you
would
just
insert
into
your
pipeline.
B
It's
it's
just
like
you,
just
don't
include,
and
you
can.
You
can
override
jobs
with
your
pipeline,
and
this
is
like
kind
of
a
job
template,
but
we
don't
really
have
a
real
solution
for
that,
yet
something
that
we
do
plan
probably
to
to
have.
But
before
that
we
need
to
have
like
we
need
to
build
the
experience
around
it,
and
then
it
doesn't
matter
if
we'll
use
like
there
are
multiple
ways
on
how
you
can
use
like
a
job.
B
B
A
A
C
You
know
like
some
things
we
ask
for
input
and
then
maybe
they
need
to
select
the
workflow
and
we
use
those
inputs
to
set
up
that
specific
workflow.
That's
probably
the
easier
way.
So
maybe
that
would
be
like
the
first
step
and
then
it
might
evolve
into
something
a
bit
more
abstracted
or
maybe
not.
Maybe
it's
not
necessary
even.
A
Yeah,
okay,
that
was
my
idea
as
well.
That's
okay!
I
think
that's
that's
what
this
step
is
about,
so
there
isn't
much
to
be
added
here.
Then.
The
question
is
that
do
we
need
a
separate
ammo
that
describes
auto
devops
or
we
don't
need
that,
because
the
only
thing
that
came
up
that
we
might
need?
Something
is
if
we
use
this
post
stage
jobs
for
for
the
deployment,
because
otherwise
it's
not
need
at
all.
B
A
B
D
B
A
Yes,
it
might
be
so
it's
like
the
thing
is
that
what
out
of
those
now
means
it's,
it's
really
confusing.
I
think
because
it
could
be
like
what
it
means
today
is
your
single
pipeline.
That
just
does
just
does
everything
for
you
and
what
we
are
speaking
about
right
now
is
that,
obviously,
more
like
a
compliance
pipeline,
that's
run
in
your
post
stage,
and
that
could
be
a
child
pipeline
as
well.
D
C
A
I'm
thinking
if
the
current
limitations,
so
it's
like,
because
the
current
limitation
of
autodevops
biggest
one
is
that
that
it's
it's
very
brittle.
It's
totally
unversioned
when
we
upgrade
things
things
might
might
break
for
our
users,
and
this
is
in
large
part,
a
consequence
of
of
our
time
of
our
yaml
templating,
like
the
the
includes,
cannot
be
version,
etc.
A
A
B
A
Clearly,
yeah,
actually
that's
something
that
we
even
discussed
with
mikhail
that,
even
if
he,
if
he
would
use
a
dsl
well,
the
kind
of
nice
things
with
the
dslr
is
that
it
can
just
generate
you,
the
ammo
without
running
it,
and
so
you
can
visualize
it.
You
can
test
it,
you
can
you
can
even
it's
a
bit
more
dynamic,
you
can
even
run
tests
against
your
generation
of
the
ammo.
So
definitely
we
should
be
able
to
visualize
even
the
that
post
part
of
it
or
the
whole
together.
A
A
It
should
be
a
successful
experience
for
the
user.
I
can
tell
you
my
own
experience
when
I,
when
I
tried
out
digitalocean
apps,
is
it
that
I
had
a
docker
file
and
it
just
deployed,
and
I
knew
that
what
it
deploys
is
not
what
I
actually
want,
because
I
need
two
services
and
it
it
could
do
it
automatically
only
for
one
service,
but
I
was
already
kind
of
delighted
that
yeah
I
did
it
in
two
minutes.
C
Yeah
yeah,
that
makes
sense,
but
do
we
need
to
provide
some
kind
of
path
from
there
to
do
that?
Customization,
because
it
has
to
be
somehow
discoverable
that
okay,
it's
great
now
it's
running,
you
should
be
able
to
see
the
value
right
away
and
to
see
what
is
working
and
then
there
should
be
some
kind
of
way
for
you
to
move
on
and
extend
it
if
you
need
to,
it
doesn't
necessarily
have
to
be
like
a
step.
A
C
Yeah,
maybe
it's
okay,
at
least
at
first
to
just
you
know,
like
we
can
document
that
hey.
If
you
want
to
customize
it
further,
you
can
go
ahead
and
edit
that
file,
but
in
the
ui
we
don't
necessarily
have
to
guide
them
there
and
which
is,
which
can
also
be
a
good
thing
if
we
can
demonstrate
considerable
value
with
just
what
works
by
default.
As
you
said,
the
same
thing
with
digital
ocean,
I
also
use
them
it's.
It
was
a
really
great
experience
like
for
someone
who's,
not
very
technical.
It
was
just
so
easy.
B
Yeah
I
question
like
when
you
say
user
edit,
editing
the
the
auto
devops
workflow.
It
means
that
they
are
customizing
dot
or
devops,
but
it
still
like
works
as
other
devops
and,
unlike
today,
the
minute
you
touch
the
file,
it's
no
longer
auto
devops.
It's
a
regular
ci
right,
like
what
you're
saying
is,
update
it,
but
continue
to
run
like.
A
A
A
D
A
But
we
cannot
make
the
same
automation
for
staging
environment
already,
because
in
staging
they
have,
god
raise
all
around
that
they
want
to
have
very
strict
on
on
what
linters
will
run,
what
policies
should
be
satisfied
and
we
don't
support
policies
at
all
yeah.
So
that's
that's
when
it
becomes
tricky
and
actually
using
cam
is,
is
not
doesn't
scale
well,
even
though
our
users
know
helm
and
don't
know
any
other
tools.
B
B
Yeah
I
the
way
I
envision
it
is
that,
like
in
the
beginning,
like
probably
a
lot
of
our
users,
will
will
take
control
over
like
dr
devos,
okay,
it's
working
as
you
mentioned,
for
development,
but
now
in
the
real
world
I
need
to.
You
know:
do
my
own
stuff
so
I'll
take
control
on
that,
but
then,
like
as
we
improve
all
the
devops,
there
will
be
like
less
and
less
users.
B
They
want
to
do
it
because
they'll
say:
okay,
it's
it's
working
and,
and
we
need
to
make
sure
we
we
invest
the
right
time
on
like
solving
the
the
problem
for
like.
I
know
if
it
would
be
like
the
majority
of
the
users
but
like
to
extend
our
reach
to
as
much
user
as
possible,
but
there
will
always
be
those
users
that
will
say.
Okay,
I
want
yeah.
D
B
C
C
D
A
C
A
C
Yeah
yeah
it
it
kind
of
seems
like
in
in
terms
of
user
experience,
we're
kind
of
making
autodevops
work
with
the
current
experience
that
we're
creating
for
pipeline
authoring
as
a
whole.
So
we
need
to
have
this
one
framework
for
presenting
pipelines
in
gitlab
and
how
you
work
with
those
pipelines,
how
how
you
set
them
up
and
how
you
can
see
them
run
and
so
on
and
so
forth.
So
this
user
flow
that
we
went
through.
C
It
seems
like
it's
all
for
that
and
regarding
the
sketch
for
the
project
like
project
automation,
dashboard.
So
this
is
kind
of
like
a
long-term
vision
or
like
a
blue
sky
vision
for
what
the
pipeline
editor
or
this
pipeline
dashboard
would
look
like.
So
now
it's
the
editor,
but
then
eventually,
once
once,
we
start
putting
some
more
abstraction
on
it
and
we
would
have
the
ui
where
you
can
click
on
buttons
to
create
those
pipelines.
C
C
I
also
think
that
maybe
it's
okay,
because
for
us
to
maybe
move
on
and
create
something
more
novel,
we
kind
of
have
to
make
the
current
solutions
work
together,
because
then
the
more
we
start
building
them
out
separately,
the
more
they
will
diverge
and
will
be
more
difficult
to
to
proceed.
So
I
think
it's
great
that
we're
aligning
now
on
the
experience-
and
you
know
we
can
run
another
design
sprint
to
create
something
mind-boggling,
that
everyone
will
just
freak
out
about.
A
Third-
I
already
mentioned
this
to
those
before
design
sprint
that
I
think
largely
what
what
we
are
discussing
is
related
to
to
your
team.
Actually,
so
I'm
not
even
sure
that
we
should
we
should
kind
of
play
around
this
area,
because
we
might
just
mess
up
your
your
plans
and
stuff
like
that.
So
I
don't.
I
don't
think
that
with
the
design
sprint
we
can.
We
have
actionable
things
to
do
so.
I
it's
like.
A
C
So
yeah,
I
think,
you're
right
actually,
this.
It
was
perfect
timing
for
this
design
sprint,
because
I
it's
really
going
to
inform
the
work
that
I'll
be
doing
around
the
ci
templates
library,
because
we
need
to
have
this
aligned
user
experience.
So
I
think
the
next
step
for
me
will
be
to
just
make
sure
that
I
loop
you
in
in
whatever
insights
that
we
find
from
the
problem,
validation,
customer
interviews
and
then
keep
you
in
the
loop
on
the
exploration
that
I'll
be
doing
this.
C
Maybe
we
can
start
kind
of
tackling
some
small
parts
and
some
some
small
problems.
I
don't
know
because
either
way
creating
like
taking
this
user
flow,
creating
the
design
and
make
making
this
high
fidelity
design
for
this
huge
workflow
might
not
be
that
useful,
either
way,
because
we
all
know
it's
just
all:
gonna
fall
apart
as
we
learn
more
along
the
way
like
it's
gonna,
morph
and
change
dramatically
over
time.
So
we
can
just
take
it
step
by
step.
A
Yeah
yeah
to
me
really
the
that's
one
of
the
key
learnings
and
the
other
is
that
I
see
deployment
is
a
it's
a
very,
very
problematic
thing
right
now
at
gitlab,
and
that's
that's
what
I'm
working
mostly
on
that
that
what
we
might
have
to
change
in
terms
of
the
automation
behind
all
of
this
and
might
affect
things
and
that's
yeah.
We
getting
aligned
here,
I
think,
is
important
for
us
cool
love.
Anything
from
you.