►
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
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
A
B
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
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
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.
B
B
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
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
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
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.
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
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
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
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
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
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
A
A
A
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.