►
From YouTube: Release tag to Issue Sync
B
So
we
can
discuss
all
that
stuff.
But
on
this
first
issue
we
were
doing
some
interviews
with
customers
as
a
result
of
our
release.
Orchestration
maturity
scorecard
journey
when
we
moved
it
from
minimal
to
viable
and
a
large
piece
they're
complaining
about
in
order
to
leverage
the
release.
Progress
view
feature
was
that
they
weren't
using
milestones
as
a
part
of
their
planning
mechanism.
B
So
they
aren't
taking
advantage
of
that
feature
they're
only
using
issues
and
the
source
code
management
work,
so
one
thing
that
they
requested
was
to
be
able
to
associate
the
release
requirements
that
they
have
documented
inside
of
issues
to
a
particular
release
tag,
and
that's
what
this
feature
is
about.
It's
about
creating
that
relationship
when
customers
aren't
leveraging
milestones
future.
Looking,
there's
a
couple
of
triggers
that
we
can
create
from
this
like
hey,
we
notice
that
you're
attaching
a
release
to
an
issue.
You
know
you
can
plan
releases
with
milestones.
B
So
how
about
you
check
out
our
milestones
and
then
there's
even
more
stuff
that
we
can
do
with
like
when
people
create
group
releases
and
using
group
milestones
to
track
work
across
multiple
projects
and
create
indications
and
triggers
inside
the
ui.
But
the
heart
of
this
problem
that
we're
trying
to
solve
with
this
relationship
is
to
support
the
users
that
are
using
releases
and
issues,
but
not
milestones,
because
we
don't
want
to
constrain
people
from
from
releasing
their
code
just
because
they're
not
using
milestones
right.
A
Right
yeah-
and
I
I
think
this
makes
sense
for
lots
of
reasons,
but
starting
with
the
first
thing,
the
the
ui
proposal
is
fine.
I
think
eventually
we're
gonna
move
stuff
out
of
the
sidebar
and
into
like
widgets
somewhere
else
in
the
issue,
but
like
that's
just
another
thing
that
you
don't
have
to
worry
about,
that
associating
releases
to
issues
makes
a
ton
of
sense
for
lots
of
reasons.
So
I
think
the
only
the
only
thing
that
I
guess
this
is
where
associating
a
release
to
an
issue
problem
solved.
A
A
B
A
Sure,
okay,
so
if
that's
the
case,
then
you're
you're,
basically
at
that
point
in
time
when
the
release
gets
created,
you're
creating
a
snapshot,
a
tag
in
in
the
git
repo.
At
a
point
in
time
that
says:
hey
here's
the
code
at
this
point
in
time.
Exactly
so,
then,
if
you
want
to
associate
an
issue
to
that
at
that
point
in
time,
I
guess
what
I
was
asking
is
you're
associating
an
issue
to
a
release.
A
B
B
Exactly
so
for
people
who
are
using
releases
as
they're
intended,
which
is
this
continuous,
I'm
tagging
a
release
for
every
commit
that
I
make
on
deployment
and
my
issues
there's
going
to
be
a
handful
of
issues
for
every
commit.
All
of
it's
been
done
already.
So,
theoretically,
those
are
closed
issues
they're,
just
associating
the
scope
that
was
requested
with
the
release
tag
that
was
produced
in
production.
B
We
have
an
offshoot
of
people
using
a
release
tag,
so
they
create
a
release
tag.
It
doesn't
contain
any
code
in
it,
but
they
are
planning
releases
with
milestones,
so
they
associate
that
shell
tag
with
a
milestone
and
that's
where
we
get
the
issue
progress
view
and
it's
all
those
open
issues
in
the
merge
request
and
merge
requests
inside
that
milestone
that
are
then
assigned
to
that
release.
B
That
is
like
future
facing
and
then
once
that
released
date
passes
so,
like
the
milestone
is
closed
and
that
release
is
closed.
The
issues
that
are
within
that
milestone
should
also
be
closed.
There's
no
automation
around
that,
though,
so
you
could
technically
have
a
complete
release
with
open
issues
in
it
still
because
there
isn't
any
reconciliation
there.
B
We
have
a
concept
of
draft
releases
that
we
are
going
to
be
instrumenting
in
short
order
and
a
draft
release
would
be
what
we're
hoping
to
deliver
and
then
that's
where
you
use,
like
your
milestone
associations,
to
show
future
work
and
then
once
the
release
is
promoted
or
published,
it's
no
longer
in
draft.
That's
the
snapshot
of
production.
C
Okay,
because,
in
general,
how
I've
worked
in
years
past-
and
this
is
how
a
lot
of
the
customers
I've
been
talking
to
work-
is
they
create
baselines
every
time
they
merge
effectively,
if
you're
doing
it
correctly,
you're
creating
a
new
baseline,
the
baseline
or
the
final
baseline
will
go
into
testing
when
the
baseline
passes
testing.
At
that
point,
it
is
considered
a
release.
You
may
have
multiple
iterations
of
a
baseline
that
don't
pass
and
therefore
are
never
released.
C
However,
those
baselines
need
to
be
kept
and
the
artifacts
need
to
be
kept
against
them,
because
baseline
7
may
contain
50
issues.
You
find
a
problem
in
testing.
You
fix
the
problem
under
50
issue.
51,
you
re-baseline
that
baseline
only
contains
issue
51,
it's
a
culmination,
so
it's
that
plus
one
more
and
then
your
release
is
these
four
baselines
with
these
issues
against
each
baseline?
Your
release
is
the
final
baseline
becomes
your
release.
B
In
my
mind,
there's
like
a
clear
line
in
the
sand
between
plan
versus
delivery
and
plan
may
have
the
baselines,
but
release
is
the
production
state.
That
is
where
we're
expecting
our
version
to
be
declared,
which
will
have
a
get
tag
associated
with
it
and
the
chain
of
custody
which
we're
calling
release
evidence
attached
to
that.
So
there
could
be
multiple
snapshots
of
that
release,
tag
which
we
have,
which
we're
calling
on
demand
release
evidence
which
shows
for
each
production
patch
that
are
released
for
a
particular
tag.
B
B
Future
looking
on
release
evidence,
we
have
this
idea
of
being
able
to
diff
those
two
chain
of
custodies
between
within
either
a
particular
tag
or
between
different
tags.
I
think
that
that
baseline,
that
you're
talking
about
would
be
represented
with
our
ability
to
compare
release
evidence
over
time.
So
I
feel
pretty
pretty
good
about
that.
That's
that's
good
I'll!
Send
you
some
more
links
after
that
about
release
evidence.
It's
still
a
minimal
feature.
B
We
had
some
things
come
out
of
it
that
we
needed
to
go
back
and
fix,
so
we
have
removed
a
bunch
of
stuff
and
now
we're
rethinking
how
we
want
to
contain
all
of
the
related
artifacts
inside
of
release,
evidence
and
that
work
is
happening
this
milestone.
So
after
that,
we
should
have
more
of
like
a
richer
release.
Evidence
chain
of
custody.
C
A
A
B
B
A
So
like,
let's
talk
about
future
kind
of
working
backwards,
like
one
of
the
things
is
like
if
in
this
first
use
case,
we
talked
about
where
somebody
completes
all
these
issues
and
then
they're
gonna
go
add
the
the
release
that
contains
all
these
changes
that
the
issues
requested.
Basically,
that's
where
I
was
thinking
about
it
from
the
standpoint
of
you
have
your
merge
requests
and
the
merge
requests
should
theoretically
like
be
able
to
determine
which
two
tags
it
falls
within
right.
A
So
if
you
have
one
tag
that
happens,
let's
say
you
tag
your
code
on
january
1st.
Then
you
tag
your
code
on
january
31st.
The
merge
request,
the
time
that
the
commit
was
made
to
to
the
main
branch
will
fall
between
these
two
dates.
So
there,
therefore,
you
know
if
it
falls
between
after
the
last
one
and
before
the
next
tag
that
it's
part
of
the
next
tag.
B
So
there
may
be
any
given
commit
that
a
developer
could
tag
if
they're,
if
they
are
producing
tags
as
a
part
of
their
commitment,
commits
to
master
and
then
those
get
deployed
to
production
if
it's
like
a
cd
world.
So
I'm
a
little
hesitant
to
say
that
that's
like
a
very
clean
inference,
because
you
can
have
like
five
merge
requests
attached
to
an
issue
and
then
thousands
of
commits
of
those
thousands
of
commits
ten
of
those
could
have
tags.
So
there
isn't
necessarily
like
a
a
clean.
B
A
But
this
is
the
actual
you
know,
release
or
the
actual
tag
that
this
falls
within,
or
maybe,
if
there's
more
than
one
merge
request
here,
all
the
tags.
That,
basically,
this
issue
is
part
of
the
reason
why,
like
that,
having
that
actual
sort
of
important
is
because
we
eventually
want
to
get
to
the
point
where,
when
there
is
a
defect
that
gets
reported
six
months
down
the
line,
we
can
basically
say
hey.
It
was
introduced
by
this
issue.
B
I
realized
something
I
didn't
tell
you:
draft
releases
will
be
a
object
without
a
tag,
so
it's
a
pre-release
and
it
would
be.
You
could
then
associate
a
tag
with
it
after
your
production.
So
it
helps
tackle
that
second
use
case
that
we
opened
up
with,
which
is
users
who
are
currently
creating
a
shell
tag
and
then
planning
to
that
and
then
re-tagging
it.
After
their
release
is
done
to
production
and
for
draft
releases.
You
would
create
a
release,
object
and
then
attach
a
tag
to
it
later.
B
So
what
we
would
see
in
the
future
on
issues
is
that,
like
you,
were
suggesting
having
a
target
release
in
the
sidebar
or
it
could
say,
release
assigned
in
the
same
option,
whether
that's
a
current
tag
or
it
would
have
an
indication,
that's
a
draft
release
in
the
drop
down
menu.
If
it's
a
side
side
panel
option
and
it
would
pull
in
releases
without
tags
and
a
user
could
select
the
draft
release
in
that
menu
item
so
that
you're
still
getting
the
issues
to
releases.
A
B
So
it
would
be
inclusive
of
all
the
mrs
and
then
that
commit
is
the
merge
of
that
release
branch
into
master
indicating
deployment
to
production.
So
what
we
would
be
seeing
is
a
representation
of
all
the
efforts
that
are
included
in
that
release,
because
it's
like
a
a
monthly
release
with
hundreds
of
mrs
and.
A
A
A
Yeah
yeah,
so
I
get
that
but
there's
three
different
releases,
and
so,
if
you
only
can
do
one
thing
in
the
sidebar,
do
you
just
keep
updating
it
or
like
that's
where
I'm
kind
of
saying?
Would
you
also
then
have
to
add
the
release
tag
to
the
merge
request
itself
so
that
we
can
see
that
this
merge
request?
You
know,
like
happened
within
the
13.4
tag,
and
this
merge
request
happened
within
the
13.5
tag.
Do
you
see
what
I'm
saying
I.
B
So
since
each
change
is
is
tagged
in
this
case,
and
these
are
all
related
to
the
issue,
we
can
have
a
series
of
tags
on
an
issue
in
the
case
of
like
this
issue,
since
it's
scheduled
for
13.6,
a
person
could
have
it
assigned
to
a
draft
release
in
13.6
and
it
could
still
populate
other
tags
that
this
issue
is
for,
given
that
it
has
mrs
associated
with
it,
because
the
changes
are
represented
in
13.5
tag,
but
that's
only
partial
for
the
issues
being
completed
so
correct.
It's
a
many-to-one
relationship.
B
A
Okay,
that's
sort
of
where
I
was
saying
like.
I
think
that
is
one
of
the
requirements
is
in
the
initial
thing
that
you
proposed
is
that
you
can
only
assign
one
one
release
to
one
issue,
but
in
this
case,
would
you-
and
this
is
probably
my
own
education,
since
this
change
did
go
into
13.4,
even
though
this
issue
wasn't
closed,
would
you
associate
basically
this
issue
and
this
merge
request
to
the
13.4
release,
evidence.
B
So
release
evidence
is
very
specific
to
the
tag
and
the
change
and
the
mr
included
in
13.4
would
have
a
change
log
on
it
and
that
change
log
would
be
included
inside
the
13.4
milestone.
So
that
means
that
it
if
the
released
at
is
for
that
merge
request.
The
merge
request
in
that
particular
tag
will
include
release
evidence
of
that
issue
or
of
that.
Mr.
A
Yeah,
I
think
that's
the
sort
of
thing
in
talking
with
matt
gonzalez
a
little
bit
and
talking
with
mark
mark
on
what
on
this
call.
His
background
is
in
highly
regulated
industries,
like
you
know,
aerospace,
that
sort
of
thing,
which
is
why
his
language
is
slightly
different
than
like
the
release
train
safe
type
stuff.
A
So
I've
been
learning
a
lot
about
that,
but
especially
from
like
a
compliance
standpoint
and
a
chain
of
custody
standpoint,
I
was
under
the
assumption
that
an
auditor
will
want
to
know
specifically
like
the
chain
of
custody,
from
a
merge
request
to
a
issue
to
a
tag
in
the
state
like
that.
This
is
now
like
altering
the
state
of
production.
So
what
was
the
request
that
requested
the
change?
A
The
merge
request
satisfies
the
change
or
whatever,
and
then
that
happened
within
a
specific
tag
and
tying
that,
together
in
a
100
like
bulletproof
chain
of
custody.
Basically-
and
so
that's
why
I
was
asking
the
question:
if
we're
not
planning
on
adding
that
to
the
merge
requests,
I
guess
the
merge
request.
A
B
So
the
release
dat
attribute
inside
of
a
release
tag
will
be
connected
to
nmr,
which
introduced
the
change
to
your
q
branch,
or
it
has
a
series
of
commits
that
were
then
tagged.
So
it's
very
much
like
the
source
of
change
is
the
mr
and
the
tag
that
was
generated
in
the
current
state.
So
that's
it's
like
a
very
direct,
clear
relationship.
A
C
C
Now
I
realize
that
that's
not
immediate,
but
that's
that's
where
I'm
getting
a
lot
of
questions
from
people
is.
How
do
I
pick
and
choose?
How
do
I
get
a
firmware
team?
That's
constantly
iterating
and
they're
snapping
releases
once
a
month
once
every
two
weeks,
and
we
may
want
to
use
release
n
minus
seven
when
we
actually
roll
up
our
release
and
send
it
to
the
customer.
We
won't
want
the
latest.
It's
not
tested
it's
in
development
kind
of
thing
and
that's
where
this
gets
really
hard.
C
When
you
get
into
those
types
of
industries,
I'm
not
saying
we
have
to
solve
for
that
now.
I
think
we
have
a
great
start
and
I'm
really
excited
for
where
this
is
going,
but
I
guess
that's
sort
of
one
of
the
things
that
people
are
asking
about
and
right
now
I
don't
know
is
that
we
have
a
very
great
story
for
how
that's
going
to
come
to
fruition.
B
C
B
B
I
also
have
other
features
like
adding
environments
to
the
compare
page
so
that
people
can
see
like
production
versus
staging
versus
production
a
week
ago
and
comparing
those
those
states
kind
of
like
a
configuration
drift
which
might
be
useful
for
the
more
regulated
industries
that
are
looking
to
see.
What's
changed
in
production
over
time.
C
They're
using
ci
to
do
building
and
linting
and
mizra
or
other
formal
code
checks,
but
the
result
of
the
ci
pipeline
is
an
executable
that
gets
pulled
out
of
git
lab
and
put
onto
embedded
hardware.
So
any
embedded
industry
like
a
phone
manufacturer,
microwave
totally
they're
producing
software
hardware
that
gets
loaded
onto
something
and
then
tested
there.
C
B
Is
like
how
do
we
support
a
distribution
network
with
package
and
the
releases
page?
And
I
think
that
that
is
alluding
to
how
can
we
support
embedded
software
companies
a
little
bit
better
as
a
distribution
network?
But
also
some
of
those
pieces
are
like
release,
assets
and
artifacts
and
persisting
those
assets
over
time
and
then
being
able
to
integrate
with
external
build
packages
and
having
them
hosted
and
distributed
through
gitlab.
B
C
Requirements
we
need
to
go
because
I
think
where
we've
we've
gone
a
lot
towards
sas,
which
is
fantastic,
but
I
think
we
need
to
recognize.
The
embedded
market
is
very
large
with
a
lot
of
money
and
a
lot
of
them
want
to
get
off
of
jira
and
some
of
the
things
stopping
them
right
now
are
the
fact
that
we
are
very
saf
oriented
and
we're
not
incredibly
embedded
oriented,
and
I
think
the
planning
is
coming
along.
C
You
know
we're
dave
and
I've
been
working
really
hard
to
get
planning
up
this
enough,
so
that
people
can
use
it
for
planning
on
these
major.
You
know
enterprise
level
plans,
but
I
think
it's
great
to
see
that
we're
also
recognizing
that
we
need
to
understand
how
to
do
things
like
release
management
and
those
things
and
and
just
having
something
out.
There
shows
our
customers
a
lot
that
no
we're
looking
at
this,
and
we
understand
that
there
may
be
a
deficiency
here
for
you,
and
this
is
where
we're
improving,
feel
free
to
comment
and
contribute.
A
So
there's
like
lots
of
flexibility,
but
at
the
end
of
the
day
you
can
never
have
more
than
one
tag
on
a
commit
and
you
can
never
have
like
basically
tags
that
are
out
of
order
chronologically,
if
that
makes
sense
so
like
in
this
case,
we
have
like
a
bunch
of
commits
and
then
there's
a
tag
that
gets
put
on
this
commit.
That's
you
know
not
fceb,
which
is
right
here.
A
Basically,
this
update
rate
file
commit,
and
so
you
know
that,
like
that's
the
the
marker
or
the
line
in
the
sand,
so
anything
that
happened
before
that
basically
would
be
part
of.
Basically
that
happened
between
this.
The
point
where
this
commit
was
tagged
and
the
previous
commit
was
tagged
as
part
of
this
commit.
So
you
like
you,
basically
can
go
from
the
commit
to
determine
the
version
or
the
tag
name
and
then
from
the
tag
like
the
commit
to
the
merge
requests.
A
B
This
kind
of
ties
back
to
what
I
was
saying
before
that
some
people
have
different
strategies
of
tagging.
Their
commits
and
some
people
are
also
only
they're,
committing
to
a
release,
candidate
branch
and
then
the
way
that
they
tag.
It
is
tagging
the
commit
that
pushes
the
release
candidate
branch
to
master
and
then
that
gets
deployed
to
production.
So
there's
like
thousands
of
commits
in
that
release,
candidate
branch
and
the
only
tag
they
create
is
at
the
end
when
they
integrate
that
release
candidate
branch
to
master.
So
that's
like
there's
two
strategies.
A
B
B
Yeah,
which
is
exactly
how
like
people,
are
tagging
in
it
with
a
shell
tag
and
then
updating
the
release
with
the
new
release
branch
tag
like
that's
how
it's
working
today
and
that's
why,
like
release
evidence,
has
the
list
of
commits
and
mrs
in
it
after
it's
been
merged,
took
to
the
main
branch?
Okay,.
C
This
is
we're
working
around
git
limitations
here
and
the
way
it
gets
structured,
there's
a
reason
that
git
is
not
used
in
regulated
industries.
Very
often
it's.
This
exact
problem
is
it's
very,
very
hard
to
ensure
that
every
commit
is
assigned
to
the
correct
version
and
gets
attributed
to
the
correct
thing,
and
it's
very
hard
to
t
your
branches
in
a
regulated
way.
Where
you
say,
I'm
going
to
pick
up
version
10.,
I'm
going
to
make
these
three
changes
and
release
it
as
1.1.
B
Yeah-
and
it
does
make
it
a
little
bit
challenging
whenever
I
also
speak
to
customers
that
are
in
you
know,
like
on-premise
applications
that
they're
deploying
to
customers
where
they
have
like
a
a
license
that
they're
promoting
and
then
they're
making
changes
and
updates
and
patches
to
a
particular
license,
because
they
have
a
binary.
That's
that
is
inside
that
1.2
version
that's
running
on
customer
x,
even
though
current
version
is
3.8,
they
have
to
like
update
all
the
spring
files
or
they
have
to
like
do
whatever,
because
these
have.
B
A
Your
draft
could
be
like
a
target
or
target
could
be
the
draft
or
whatever,
because
I
like,
I'm
also
want
to
build
a
better
relationship
between
issues
and
merge
requests
so
that
you
do
know
that
it's
not
just
related.
It's
like
literally
implementing
this
issue,
and
if
you
do
it
that
way,
then
the
issue
or
the
merge
request
would
inherit
things
like
the
milestone
right.