►
From YouTube: Release Orchestration Roadmap Discussion
Description
Discussion regarding Release Orchestration category between PM and FE developer
A
Hello,
I'm
kevin
chu,
I'm
the
pm
for
release.
I
have
with
me
nathan
friend,
who
is
a
super
awesome
engineer,
and
I
want
to
get
a
chance
to
to
to
pick
up
pick
out
all
the
things
he
learned
has
thought
about
over
the
time.
We
support
that
git
lab
before
before.
We
say
goodbye
to
him.
So
here
we
are
thanks.
Nathan
yeah,
you
bet
so
nathan,
just
to
kick
things
off.
B
Yeah
good
question,
so
when
I
first
started,
we
had
just
broken
out
release
from
verify,
so
it
was
still
a
very
kind
of
ci,
focused
team,
and
so
the
first
feature
I
worked
on,
I
think,
was
merge
trains
building
the
the
front
end
for
that
which
is
like
a
very
ci
focused
feature
and
we've
since
handed
that
off
to
verify
so
release
doesn't
really
do
that.
But
that's
that's
kind
of
background.
That
was
my
first
one
and
then
I
worked
on.
B
I
can't
remember
the
exact
order,
but
I
worked
on
a
lot
of
things
on
the
releases
page
so
that
the
releases
page
was
very
rudimentary
when
I
first
joined
like
it
didn't
have
pagination
it.
It
was
basically
just
like
title
and
description,
so
we
added
a
lot
of
functionality
around
associating
releases
to
milestones,
release
evidence
trying
to
think
what
else
we've
added.
We
did.
B
We
kind
of
kind
of
reworked
the
ui
there
used
to
be
just
a
single
releases
page,
and
that
was
all
there
was,
and
now
we
have
like
an
individual
page
for
each
release
and
you
can
edit
it
through
the
ui.
You
can
create
new
ones
through
the
ui,
so
that
was
all
stuff.
I
worked
on,
let's
see
oh
and
then
I
guess
most
recently,
the
dora
metrics.
All
of
those
are.
I
worked
on
the
front
end
for
all
those
and
helped
define
some
of
the
requirements
for
that
so
yeah.
B
So
for
most
of
my
time
at
gitlab,
I
wanted
to
spend
my
time
on
that
releases
page,
which
I
mentioned,
because
it
was
so
rudimentary
when
I
joined
and
there
you
almost
had
to
do
everything
through
the
api.
B
So
we
built
out
a
lot
of
ui
with
that,
but
I'm
actually
now
at
the
point
where
I
think
it's
an
okay,
we're
at
an
okay
spot
with
that
with
that
feature
in
terms
of
like
editing
it
through
the
ui
and
stuff
like
that,
so
I
think
what
I
would
focus
on
next,
if
I
were
still
at
get
lab,
would
be
deployment
and
and
kind
of
managing
deployments.
B
I
think
that's
the
most
interesting
and
kind
of
sorely
needed
feature
in
our
in
our
product
and
specifically
just
like
thinking
about
how
deployments
are
controlled
through
the
ui
and
through
kind
of
at
a
at
a
group
level
as
well,
because
we
have
a
lot
of
you
know
kind
of
project
level
features,
but
they
don't
necessarily
work
for
big
organizations.
B
So
I
think
that
is
the
most.
In
my
opinion,
that
would
be
the
most
value
you
know.
We'd
get
the
most
value
out
of
focusing
on
on
that.
As
a
group.
A
A
It
could
be
very
well
architected,
so
it's
like
everything's
a
service
and
the
service
just
works
either
independently
or
in
conjunction
with
everything
else.
The
reality,
you
know
is
nothing's
ever
that
crisp
and
clean
yeah.
Absolutely
so,
especially
that
legacy
in
the
prices
for
any
company
that's
been
around
for
a
while.
It's
like
it's
not
that
clean.
A
So
you
run
into
a
situation
where
you
have
a
release,
manager,
type
person
or
that
person's
job
is
like
talk
to
all
the
teams
make
sure
all
their
stuff
fits
together
in
the
right
way
and
when
it
comes
to
deployment,
we've
got
to
make
sure
a's
got
to
go
before
c,
because
b
depends
on
b
and
b
can
only
work
if
this
version
of
c
works
in
such
a
way
in
that
in
that
world.
How
do
you
see
like
where
does
release
the
release
page
fit?
A
Is
it
a
starting
point
like
should
a
release
manager
before
doing
anything
else,
create
a
release
page?
If
that's
the
case,
what
should
be
on
that
page?
That's
missing
today,
if
that's
not
the
case
where,
where
should
people
start
what's
natural,
what
an
augmentation
to
their
workflow,
which
is
frankly
completely
manual
for
from
every
single
company
I've
seen
every
customer,
I
talked
to
what
do
you
think
about
these
type
of.
B
Things
yeah,
so
that's
actually
something
we
had
we're
talking
about
a
lot
before
we
was
kind
of
on
the
release
management
team
before
we
switched
into
into
door
metrics,
and
I
think
the
direction
we
were
going
in
was
creating
this
idea
of
a
a
group
release
which
wasn't
really
a
release
in
the
same
sense.
So
maybe
that's
not
the
best
word
it's
more
of
a
release
plan
or
you
know
a
release,
schedule
or
manage.
B
I
don't
know
some
kind
of
it's
almost
a
place
to
manage
the
release
more
than
anything
else,
yeah,
and
I
think
what
we
at
the
the
first
step
was.
We
had
looked
at
jupiter
notebooks
as
kind
of
a
release
management
system,
and
that
would
let
you
have
some
dynamic
elements
like
check
boxes
and
be
able
to
run
scripts
as
that's
part
of
that
notebook,
and
then
I
think
you
know
thinking
further.
I
think
we
had
thought
about
even
building
that
kind
of
dynamic.
B
You
know
kind
of
runtime
our
the
ability
to
kind
of
execute
steps
in
that
plan
into
get
lab
itself
like
into
the
markdown.
So
you
might
have
this.
B
You
know
big
release
plan
with
check
boxes
and
you
can
define
you
know,
actions
that
execute
when
you
check
them
and
then
that
would
be
your
release
plan
and
it's
kind
of
the
single
place
that
you
document
it
and
execute
your
release
and
then
that
would
kind
of
support
the
whole
spectrum,
whether
or
not
it's
fully
manual,
and
it's
just
kind
of
a
static
list
of
checkboxes
that
you
checkbox
or
if
it's
almost
fully
automated,
where
you
know
you
click
a
checkbox
and
it
runs
a
script
that
does
everything
you
could
kind
of
it's
up
to
the
user
to
define
their
release
plan
as
they
want.
B
A
B
B
B
I
think
what
could
be
interesting
is
have
have
the
ability
to,
let's
say,
create
this
in
your
release
plan
you
have
a
big
markdown
description
and
what
you
can
do
is
create
buttons
that
fire
pipelines
in
your
child
projects,
so
you
might
say,
okay
deploy
project
a
and
then
it
goes
and
executes
a
pipeline
step
in
the
sub
project
a
and
then
that
gives
you
kind
of
the
as
the
developer
you're
still
in
charge
of
implementing
how
how
it
gets
released
and
how
that
pipeline
works,
but
it's
being
called
and
orchestrated
at
a
higher
level,
so
you're
not
in
charge
of
timing
it
and
you
don't
have
to
be
quite
as
involved.
A
A
How
do
you
find
ui
important
sorry,
not
ui,
visual
treatments
of
a
release?
Hey.
I
hear
this
from
people
that
want
this
like.
Oh,
I
want
to
visualize
this
complicated
spreadsheet
that
I've
created
and
without
any
more
details.
That
statement
generally
makes
sense
to
me
at
for
when
I
first
hear
of
it,
but
then,
when
you
think
about
it,
it's
like
how
do
you
visualize
something
like
that?
Does
it
simply
becomes
another
architect
like
perspective
on
an
architecture
diagram,
because
is
it
really
that
different,
it
doesn't
feel
like
it?
A
B
Yeah,
are
you
thinking
about
like
visualizing
the
the
release
process
like
itself,
like
you
know
like
these
two
have
to
be
deployed,
and
then
that's.
You
know
that.
B
B
B
One
of
the
things
I
think
we're
missing
in
a
huge
way
is
just
the
ability
for
to
see
how
a
release
moves
from
first
of
all
being
a
release
like
being
merged
by
a
developer
and
then
moving
through
all
the
process
and
then
finally
being
deployed
in
production
I
kind
of
in
my
head.
I
can't
remember
which
system
I
think
it
might
be
octopus
deploy,
but
they
have
these
nice.
B
Like
a
like
a
timeline
view-
and
I
think
that's
that's
really
cool
and
that's
that
fits
a
little
nicer
with
the
release
manager
persona
because
they're
not
necessarily
going
to
want
to
like
a
super
technical
like
gitlab,
ci,
yaml
format,
isn't
really
what
they're.
Looking
looking
for
yeah.
A
That
makes
sense
so
you
mentioned
earlier
you're
excited
about
deployment,
and
I
really
like
your
thinking
around
deployment
should
be
like.
If
we
had
an
opinionated
way
about
how
things
should
work,
it'll
be
everyone
creates
their
code
and
then
you
orchestrate
it
into
a
group
release
and
then
underneath
that
group
release,
there's
individual
project
level
releases
and
that
released
just
a
rubber
stamp
of
the
thing.
That's
gonna
potentially
get
moved
into
some
environment,
yeah
and
there's
a
float.
So
if
you
don't
have
a
rubber
stamp,
perhaps
it's
like
the
time
of
deployment.
A
It
gets
stamped
somewhere
and
that's
your
retroactively.
You
create
a
release,
so
you
can
still
go
back
and
access
the
page,
which
would
be
really
nice
because,
like
if
there's
I
I
was
thinking
I
I
don't
know
if
you
said
any
of
this,
but
you
may
have.
I
don't
remember
it's
like.
If
you
look
at
the
environment,
the
latest
deployment,
it's,
what
in
theory
should
be
what's
out
there
today,
it'd
be
great.
Even
you
don't
have
a
step
where,
in
your
process,
best
is
creative
release,
but
you
can
click
on
that
latest
deployment.
A
So,
like
no
matter
which
way
you
go
backwards
or
forward
that
whole
chain
is
there
yep
yep
that
creates
all
sorts
of
like
traceability
and
this
visibility
new
process
that
to
me
would
be
super
cool
yeah.
B
B
I
would
almost
go
so
far
as
say
like
we
were
strict
at
a
system
level
you
have
to
you,
deploy
a
release
like
you,
create
a
release,
and
then
you
have
to
source
your
files
from
that
release
when
you
deploy
and
because
that
would
that
would
give
you
the
traceability
that
you
want
where
you
can
definitively
say
this
environment
is
running
release,
1.5
and
then,
like
you
said,
you
can
link
back
to
it
and
you
can
see
the
release
evidence
and
you
know
exactly
what's
in
it.
B
I
think
that
would
yeah
exactly
what
you
said
is
that's
kind
of
what
I,
in
my
vision
as
well.
Okay,.
A
B
Yeah,
I
think
what
I
would
focus
on
first
is
associating
deployment
of
releases
with
deployments
or
releases
with
environments
kind
of
one
of
the
same,
because
right
now,
they're
really
completely
separate
concepts
like
we
have
releases
and
then
completely
separately.
We
have
environments
and
that
association
would
really
enable
a
lot
of
the
a
lot
of
the
future
features
we
want.
B
So
I
think
that
would
be
my
first.
The
first
thing
I'd
implement
if
I
was
building
all
the
stuff.
We
just
talked
about.
B
A
A
B
Yeah
right
no
you're
totally
right,
and
so
that's
why
I
don't
know
if
release
is
the
best
word,
maybe
yeah
release
plan
or
yeah
coordination
right
yeah,
something
like
that
something
to
indicate
it's
not
like
it's
not
actual
code.
It's
not
like
a
snapshot
of
code
like
an
actual
release.
It's
it's
just
managing
that.
B
A
I
want
to
talk
about
release
evidence
slightly.
My
yeah.
A
Is
very
non-existent
here
from
what
I
understand
release
evidence.
Oh
it
is
it's
a
json
blob
and
how
you
access
that
json
bob
is,
you
can
click
it
on
the
release
page,
but
that
blob
really
doesn't
offer
additional
details
than
what's
on
the
page.
A
B
You
know
that's
a
great
question.
I
I
actually
am
not
the
best
person
to
talk
about
this,
because
this
was
a
feature
that
I
think
sean
carroll
did
most
of
the
back
end
and
I
think
jake
did
most
of
the
front
end
so,
okay,
unfortunately,
I
kind
of
I
didn't
actually
work
with
this
one
very
much,
I'm
trying
to
remember.
What's
in
it,
I
think
it's
like
a
list
of.
I
think
it's
basically
kind
of
a
snapshot
of
the
release.
Object
like
everything.
B
A
B
B
A
At
the
end
of
the
day,
I
I
don't
think
there's
a
difference,
but
I
haven't.
I
haven't,
run
into
anybody
with
a
strong
opinion
that
says:
yes,
they
should
be
different,
yeah
they're,
looking
for
that
person,
that
person
exists
right
right,
yeah
because,
like
at
the
end
of
the
day,
I
think
the
distinction
really
is
whether
this
thing
has
been
deployed
already
the
release
once
it's
deployed
it
becomes
a
release,
becomes
immutable
because
you
don't
want
to
change
history
to
say
something
that
wasn't
work
but
up
to
the
time
of
deployment.
A
Of
course,
you're
still
working
on
it.
You
can
add
release
notes,
you
can
add
issues.
Oh
this
thing's
in
and
right
have
a
discussion.
It's
only
after
you
deploy
or
the
need
to
make
sure
your
records.
Don't
change
becomes
an
important
element
yeah,
which
makes
your
point
about
associating
deployments
to
releases
being
the
first
step.
A
That
makes
total
sense
because,
like
how
do
you
know,
a
release
is
released
yeah
unless
there's
that
record
somewhere
that
we
can
oh
yeah,
we
created
this
foreign
key
to
this
deployment
or
whatever
it
is
yeah.
At
that
point
you
can,
then
you
can
programmatically
actually
like
lock
things
down
with
change
the
treatment
of
the
ui
or
whatever
it
is
that
we
want
to
do
exactly
yep,
okay,
that
makes
sense
what
what
else
did
you
think
about
better
than
to
ask
you.
B
Yeah,
so
I
have
like
a
list
of
of
like
it's
almost
like
a
wish
list
of
things
that
I
would
build
if
I
had
infinite
time.
The
the
disclaimer
is
that
I
don't
know
if
these
are
like
valuable
things,
but
there's
the
things
that
I
want
to
work
on.
If
I
had
the
time
yeah,
so
I
shared
that
document
with
you,
so
the
first
one
is
making
releases
a
little
more
automatic
and
less
explicit.
B
It
requires
some
kind
of
effort
on
your
part,
yeah,
just
the
user.
That's.
B
Exactly
yeah
yeah
and
I
think,
there's
an
opportunity
to
forget,
lab
to
detect
and
auto
create
releases
and
specifically,
if
they
we
could
do
that
using
there's
this
concept
of
semantic
commits.
So
you
embed
in
the
commit
message
yourself
as
a
developer.
You
say
what
kind
of
change
it
is
and
there's
a
there's.
B
A
project
called
semantic
release
which
ties
into
those
and
we'll
read
those
and
then
create
releases
automatically
based
on
those
commits,
and
so
at
the
moment
you
can
integrate
with
that
package
and
you
can
kind
of
build
your.
You
can
build
that
as
a
pipeline
step,
but
we
could
actually
take
it
a
step
further
and
build
that
functionality
into
get
lab
itself.
So
there's
basically
zero
setup.
B
You
know
you
could
have
you
create
a
brand
new
project
with
a
brand
new
repository,
and
you
begin
committing
with
semantic
commits,
commit
messages
and
automatically
gitlab
and
start
creating
releases
based
on
on
those
messages,
and
that
would
be
really
cool
because
then
that
would,
I
think,
a
lot
more
projects
would
use
releases
because
it
would
be
so
easy
to
get
started
with
them,
and
then
that
would
kind
of
you
know
if
it
would
make
the
funnel
a
lot
bigger
for
people
to
begin
using
releases
and
begin
using
environments
and
and
all
the
other
things
that
are
connected
with
releases.
B
So
that
would
be.
That
would
be
something
I
think
would
be
really
cool.
A
B
B
B
Yeah
and
you're,
using
it
once
again,
you're
using
the
your
get
history
as
the
single
source
of
truth,
so
now
you're
pulling
in
like
not
only
is
it
all
my
versions
and
snapshots,
but
it's
also
my
deployment
or
not
deployment.
All
my
release.
History
can
be
determined
through
my
commit
messages,
so
it's
it's
pushing
more
and
more
forget
to
be
the
single
source
of
truth,
which
is,
I
think,
really
awesome.
Yeah.
B
Yeah
so
yeah
anyway,
that's
my
first
one
and
then
the
next
one
is
is
kind
of
related.
B
So
it's
making
releases
aware
of
semantic
versioning,
and
this
is
this
kind
of
goes
hand
in
hand
with
the
other
one,
because
semantic
release
creates
semantically
versioned
releases
and
what
that
means
is
you
know
you
have
those
three
version
numbers
like
major
minor
patch
that
you
often
you
see
people
using
that
schema
when
they're
versioning
right
now,
gitlab
like
it's,
you
can
use
that
as
your
tag,
names
and
gitlab
was
fine
with
that,
but
it
doesn't
infer
anything
off
those
off
those
numbers
and
if
we,
if
we
did,
if
gitlab,
could
actually
parse
those
tag,
names
or
version
numbers,
it
would
open
up
some
possibilities.
B
For
example,
we
could
say-
even
if
you
say,
let's
say
you,
release
version
1.0,
1.2
1.3
and
then
you
have
a
bug
fix
for
the
very
first
version,
so
1.1.1
at
the
moment.
Gitlab
would
just
show
those
in
chronological
order,
because
it's
just
the
order
that
you
created
it.
But
if,
if
gitlab
could
understand
the
semantic
version
between
the
different
releases,
we
could
actually
sort
them
by
version
number,
which
would
be
really
really
powerful,
and
you
could
also
order
them.
B
You
would
say:
okay,
I
know
the
next
major
version
after
this
release.
Is
this
next
release
or
the
next
minor
release?
Is
this
one
and
it
gives
the
system
of
get
lab
a
lot
more
understanding
of
the
order
of
the
releases
yeah.
A
A
B
Like
yeah,
it's
just
a
big
list
right,
so
it's
not
the
most
valuable
and
I
I
see
that
being
valuable
too.
If
we
go
forward
with
like
making
nice
workflows
for
deployment,
we
could
say:
okay,
we
can
auto
deploy
to
production
if
it's
a
a
minor
release
or
a
patch
release,
but
maybe
major
versions
require
approval.
B
B
That's
another
one.
We
kind
of
already
talked
about
making
releases
of
source
for
deployments
so
that
instead
of
kind
of
sourcing
it
at
the
moment
you
when
you
do
a
deployment
job,
you
just
get
the
project
repository
at
a
certain
snapshot
and
then
it's
up
to
you
to
like
compile
and
build
them
and
and
release
it.
B
But
I
think
it
would
make
a
lot
more
sense
if
deployments
always
start
with
releases.
So
you
have
a
ci
pipeline
that
ends
in
a
release
and
that's
kind
of
like
this
is
ready
to
go.
And
then
you
have
another
a
separate,
almost
a
separate
pipeline
that
takes
that
release
as
an
input
and
then
deploys
that
to
an
environment.
B
So
I
don't
know
I
I
don't
have
a
great
idea
of
what
that
should
look
like
like
it
could
look
in
the
most
extreme
form.
It
could
be
a
whole
separate
pipeline
view
and
a
whole
separate.
Even
a
separate
gitlab
file
like
a
gitlab.
A
A
B
I
don't
necessarily
don't
think
it's
too
dramatic.
Well,
I
I
don't
know
it.
I
think,
as
a
very
different
way
of
thinking
about
it
yeah
it
is,
and
it
would
just
be
a
lot
of
there'd
be
a
lot
of
considerations
that
have
to
go
into
like
what
that
would
look
like,
and
it
would
be
hard
to
do
an
mvc
of
it.
I
think
that's
maybe
my
resistance
to
it
is.
B
It
would
be
hard
to
do
in
a
get
louder
way
where
we
we
build
small
pieces,
but
I
don't
think
that
means
it's
wrong
like
I
think
that
could
be
a
valid
approach.
I
just
don't
know
exactly
where
I'd
start
with
it,
but
yeah.
B
Exactly
nice.
B
A
B
Yeah
we
have
this
really
awesome
ci
system
and
then
we
kind
of
see
that
as
it's
every
every
new
feature,
we
think
of
first
building
it
on
top
of
ci
and
that's
not
always
the
best
user
experience,
and
I
think
that's
the
case
with
cd,
like
all
of
our
release
features.
Currently,
it's
really
just
embedded
in
ci
and
I'd
love
to
see
more
kind
of
seeing
release
features
as
its
own,
its
own
concepts,
separate
from
that
of
ci
and
that's
kind
of
related
to
the
previous
one.
I
guess
like
having.
B
B
B
Yeah
and
then
the
last
one
is
so
we
have
right
now
we
have
the
con
concept
of
a
package
and
we
have
the
concept
of
a
release
and
I
think
part
of
that's
because
they're
two
separate
teams-
and
we
there's
so
much
crossover
between
those
two
concepts
and
I
think
we
could
go
as
far
as
combining
them
into
a
single
concept,
because
I
can't
really
think
of
too
many
cases
where
you
create
a
package
and
that's
not
a
release
like
that's
almost
by
definition.
A
A
A
B
Yeah
it
could
be,
and-
and
there
might
be
some
other
things
that
I'm
not
thinking
of
that
would
differentiate
the
two,
but
at
the
very
least,
I
think,
there's
a
lot
of
a
lot
more
that
at
the
very
least,
they
could
be
associated
a
lot
more
closely
right
now,
there's.
B
B
I
don't
know
even
in
that
one
that
one
feature
about
having
a
release
as
an
input
to
a
pipeline.
I
think
tim
commented.
Oh
we're
thinking
about
doing
the
same
thing
for
packages,
because
a
package
could
be
an
input
to
a
pipeline,
and
so
it
would
be
great
to
be
able
to
build
that
once
and
and
have
it
work
for
either,
and
then
it's
also
a
little
bit
confusing
as
an
end
user.