►
From YouTube: Think Big #13 - Release Management
Description
Semantic Release for Release features
A
All
right
we're
here
for
the
13th,
think
big.
We
have
a
guest
here,
Shinya
we're
gonna
talk
about
automatically
inserting
change
log
into
releases.
So
from
a
customer
perspective,
when
we
went
through
the
prototypes
for
the
releases
page,
a
big
request
that
they
had
was
a
flexible
approach
for
automatically
generating
release
notes.
Some
users
want
to
take
real
descriptions
from
issues
and
insert
that
into
the
release
notes.
Some
people
wanted
to
use
get
tags.
Others
were
wanting
to
use,
commit
message
for
merge
requests
and
our
first
issue.
A
Iteration
was
really
automatically
inserting
this
into
a
into
the
release.
Object.
The
release,
notes,
object
from
an
I
could
get
hub.
Repository
called
learn,
a
change
log
which
is
merge,
requests
containing
specific
labels
and
automatically
producing
a
list.
Changes
from
that
I
believe
the
runner
team
has
something
configured
in
this
method,
which
is
what
we
were
initially
going
to
approach
it
as
one
of
the
downside.
A
A
And
evidence
of
change
and
recording
not
and
inserting,
that
into
the
release,
notes
of
the
release,
so
three
main
approaches
that
people
have
communicated
to
us
and
they
would
like
it
to
be
still
flexible
and
the
release
notes
text
box
on
the
releases
page
to
be
overridden
like
if
they
wanted
to
clear
it
out
and
copy/paste
a
formatted
text
option.
So
that
was
another
sort
of
acceptance
criteria.
C
B
B
B
B
Development
practice
or
like
a
comic
missus
practice,
so
with
this
whole
users
have
to
keep
commit
message.
Conscious
that,
like
the
each
commit
message
had
sir
type
of
change
with
some
feature
were
fix
or
the
breaking
change,
our
documentation,
page,
etc,
and
then
they
add
the
body
explanation
of
the
change
and
the
the
tool.
The
semantic
release
is
going
to
collect
all
of
the
messages
and
then,
like
smartly,
detect
them.
What
message
it
has
to
included
in
a
specific
tag
so
that
generated
by
semantic
relays
includes
all
of
their
the
changes.
B
So
I
was
just
playing
around
Symantec
release
and
then
how
release
Noda
is
created,
and
so,
like
I,
created
a
bunch
of
comets
like
there's
a
specific
convention
that
it
has
to
start.
The
commit
message
has
to
start
from
the
tinge
type
in
this
case
video
future
and
then
the
title
or
explanation
for
the
change
and
then
these
change.
The
comic
message
is
automatically
included
like
this.
As
a
release,
note
afterward
that
comet
wherewhere
did
committee
went,
but
these
days
release
messages
like
this
one,
the
futures,
the
futures
breaking
change.
B
B
B
A
Now
we
do
have
in
our
tech
evaluation
evaluating
Symantec
releases
as
the
tool
of
choice
here
so
I
think
it's
really
cool
to
see
you
down
with
us,
because
it
really
is.
We
know
that
it
works
and
we
could
implement
it
Nathan.
Do
you
have
any
thoughts
on
this
I
know
you
created
that
ad
for
ad
first-class
semantic
versioning
to
releases
would
love
to
hear
your
perspective.
D
Yeah
that
could
definitely
pie
into
this.
That
idea
was
about
just
being
able
to
understand
that
version
as
a
semantic
release,
and
then
we
could
do
things
like
e-even
on
that
page
that
shouldn't
just
demoed.
For
example,
version
1.3
appeared
above
version
3,
which
is
because
it
was
published
after,
but
if
we,
if
the
application
could
understand,
however,
semantics
release
works,
it
could
sort
them
based
on
the
major
version,
minor
version
and
stuff
like
that.
So
that's
what
that
issues.
I,
wouldn't
say
it's.
E
A
A
B
B
It's,
given
that
you
have
a
milestone
like
there
is
a
release
associated
it
or
like
O'neal
at
one
point
or
how
do
we
generate
changelog
from
there?
The
one
idea
is
that
collecting
all
module,
requests
and
sorting
it
by
levels
may
be
like
features
by
feature,
will
buy
back
by
I,
don't
know
documents
and
then
list
of
all
titles
of
March,
I,
guess,
I.
B
B
A
I
do
know
that
there's
larger
enterprises
that
have
their
own
scripting
and
tooling
around
tags
and
generating
like
an
aggregator
I
think,
is
what
t-mobile
calls
it,
for
example,
and
they
have
like
a
job
that
just
collects
all
of
the
titles
of
the
merge
requests
and
the
they
link
it.
The
link
the
merge
request,
and
sometimes
they
provide
other
details
like
issue
descriptions
or
three
using
issues.
B
A
Yeah
I
have
talked
to
him,
we're
in
about
that.
That's
something
that
he
has
a
lot
of
hopes
for
because
he
thinks
it's
pretty
manual
and
painful
for
their
organization
right
now.
It's
an
image
so
I
agree
that
this
is
why
it's
a
top
priority
for
us
cuz.
It's
the
quality
of
life
feature
for
release
managers,
which
is
the
persona
that
release
management
is
tackling.
Obviously,
whether
there's
like
the
technical,
build
managers
that
there's
cruft
that
we're
trying
to
remove
from
their
job
and
this
copy-pasting
from
either
merge.
Request.
A
Titles,
merge,
request
descriptions,
issue
descriptions,
commit
messages.
We
just
need
to
eliminate
it
and
it's
trying
to
find
the
path
to
does
the
quickest
adoption
for
internally
and
from
Aaron's
perspective.
He
says
you
know
we
could
use
a
tool
or
we
could
use
just
get
tags.
It
really
will
be
like
an
enforcement
across
the
company,
though
we
do
have
an
issue
about
making
use
of
the
releases
feature,
though
we
can
create
a
specific
one
in
regard
to
release,
notes
and
start
documenting
more
around
that.
D
B
Not
big
tweak
just
like
the
Symantec
release
by
default,
it's
configured
for
github,
so
you
need
to
add
a
configuration
file
for
semantic
release
that,
like
it,
that
tool
has
to
use.
He
left
it
has
to
connect
to
get
love
and
then
basically
the
configuration
file.
It's
just
I,
don't
fight
lines
and
that's
it.
It
works
smoothly.
It
worked
just
quickly,
cool.
B
This
is
really
clever
idea
that
works
for
a
lot
of
organizations,
I'm,
not
sure
if
it
fits
in
gillip
like
its
a
huge
project
and
it's
the
release,
release
processes
like
so
complicated
and
then
but
like
for
small
projects
like
they
just
want
to
start
using
releases.
It's
it's
a
great
tool
that
they
they
they
can
just
release
that
there
are
projects
nicely
and
with
just
a
few
key
configurations.
D
You
think
of
any
reason
why
it
wouldn't
work
for
us
to
use
like
semantic
commit
messages
here.
I
get
love
like
I'm
thinking.
It
would
basically
be
the
same
as
how
we
create
our
change
logs.
Currently,
like
we
kind
of
we
have
to
decide
at
that
point
in
time,
whether
it's
a
fix
or
a
future,
and
we
put
the
name
like
we
basically
has
been
moving
that
information
into
the
commit
message.
A
We
could
start
with,
like
the
runner
team,
who
has
scripting
right
now
without
semantic
release
and
consider
like
adopting
semantics
release,
went
from
a
dog
fighting
strategy
approach
and
that's
a
smaller,
more
local
project,
and
then,
of
course,
we
can
use
it
for
pages
and
release
CLI,
so
I
think
we
can
have
like
three
projects
that
we
can
adopt
semantic
versioning
across
to
test
these
cases.
I
am
a
little
worried
about
like
from
an
internal
like
get
lab
organization.
A
The
change
management
there
I
don't
know
like
how
hard
it
will
be
for
Moran's
team
to
transition
this,
and
if
all
the
teams
or
all
the
developers
are
okay
changing
the
way
they
rate
commit
messages.
That's
what
we'd
be
asking
right
for
the
adoption.
Semantics
release
has
changed
the
way
you
write,
commit
messages,
yeah.
B
D
B
A
Think
we
just
need
to
commit
to
one
direction
that
works
and
tested
internally
and
then
offer
the
ability
to
turn
it
off
so
that
if
you
want
to
use
your
own
script
or
want
to
do
something
else
for
generating
either
versions
or
release
notes,
we
can
do
that.
The
benefit
of
semantic
versioning.
Is
that
someone
tool
right?
A
You
get
the
increment
of
the
version
and
the
release
notes,
but
other
customers
may
want
to
generate
semantic
versioning
in
a
different
way,
especially
if
they
aren't
using
semantic
versioning
as
a
nomenclature
they're
using
a
different
version
18,
and
they
may
want
to
separate
release.
Notes
from
that
method.
I
mean,
of
course
you
can
override
all
of
that,
either
by
scripting
the
API
and
changing
the
name
or
going
in
the
UI
and
editing
the
name.
It's
just.
How
do
we
reduce
the
friction
of
the
doctrine?
I.
D
Think
it'd
be
really
cool
if
it
was
kind
of
on
by
default
that,
if
you
started
starting
to
get
louder,
engine
started
committing
with
semantics
like
conventional
commits,
then
we
just
magically
started
grading
releases
based
on
that,
like
that
was
kind
of
a
default
settings.
I,
don't
know
how
realistic
that
is,
but
it
could
be
kind
of
cool
yeah.
B
A
A
B
D
Yeah
yeah
and
I
like
to
see
that
in
national,
it's
it's
towards
all
that
release
information
in
the
git
repository
like
we're,
not
I,
like
that,
a
little
better
than
pulling
it
out
of
merge
requests
or
issues
to
me.
That
feels
a
little
more
like
we're.
Storing
everything
in
the
get
repository
which
is
kind
of
cool.
B
A
A
A
This
is
a
little
out
of
my
technical
steps,
but
from
what
I
understand
is
that
it's
its
own
tool
that
calls
the
runner
and
calls
the
rail
side,
and
it
is
more
than
just
pinging
the
rails
API,
because
it's
executing
jobs
and
passing
that
logic
back
to
the
runner.
So
it's
doing
more
of
the
heavy
lifting
than
the
rail
side
typically
would
be
doing.
I
can
send
you
the
project
and
I'm
sure
you've
seen
it
before,
but
that's
my
understanding
is
that
it
has
like
two
sides
of
it.
B
A
A
Here,
I'll
cut
it.
This
is
the
readme
for
it.
It's
nearly
done.
We're
testing
it
with
the
runner
side
right
now
from
an
end-to-end
perspective,
and
it
has
its
own
like
docker
image
and
then
I'll
have
other
images
in
the
future,
but
you'll
be
able
to
use
the
yamo
file
to
generate
a
release,
but
you
can
also.
C
A
With
the
intent
is
that
that
release
job
will
automate
any
of
these
manual
actions
that
a
release
manager
would
be
doing.
In
addition
to
you
facilitating
like
the
manual
intervention
of
a
non-technical
like
if
you're
a
project
manager
and
you're
managing
releases
and
you're,
not
you
know
how
to
access
to
a
demo
file
you'll,
be
able
to
create
a
release,
tag
in
the
UI
and
associate
the
milestones
and
track
progress
from
that
view,
as
well.
A
D
A
I
think
that
all
of
these
features
are
sort
of
related
in
that,
if
we
want
the
releases
page
to
be
able
to
distribute
packages,
it
would
be
helpful
with
this
package,
where
packages
were
also
version
and
if
they
had
their
own
release,
notes
attached
to
them.
So
that's
kind
of
why
I'm
bringing
it
up
in
the
context
of
this
conversation,
yeah.
B
So
that's
a
like
when
we
try
to
build
a
very
fast
release.
Page
it
has
slowly
brought
up
and
like
one
release
could
have
her
multiple
assets,
package,
stock,
image
and
link.
I
said,
unfortunately,
we
didn't
have
enough
time,
so
you
just
shipped
like
asset,
but
it's
really
cool
to
have
her.
Finally,
assets
for
releases
and
or
just
like
using
the
package
feature
it's
totally.
It's
totally
legit
made.
B
A
Think
one
challenge
that
I'm
starting
to
also
be
circus
with,
is
this
potential
of
an
endless
scroll
for
releases
page.
So,
like
lengthy
releases,
if
we
do
have
multiple
asset
links,
multiple
binaries,
especially
if
and
the
continuous
deployment
work
stream,
where
there
may
be,
teams
that
are
generating
release
tags
with
every
commit
which
is
a
push
at
will
model.
So
they
could
have
like
50
release
tags
generated
in
a
week
for
every
release
that
they
make
to
a
production
environment.
I
mean
it
has
their
commit
message,
and
you
know
they're
not
like
aggregating
it.
A
A
B
The
rental
inquiry
space
I
don't
have
concerns
on
the
performance,
I
think
it's
just
like
showing
that
I
made
the
data.
So
it's
really
fine,
like
even
like
showing
the
link
for
downloads.
That's
really
fine,
I,
don't
particularly
see
a
performance
concern
or
release
page
except
evidence
may
be
evidence
like
yeah
the
last
time
we
had
a
conversation
in
the
issues
that
evidence
try
to
record
all
of
the
issues
out
a
milestone
or
like
something
like
that,
like
there
are
tons
of
issues
or
issues
in
issue,
information
recorded
in
them
JSON
and
those.
A
A
Good
memory
on
that
that
was
a
really
long
time
ago,
Shin,
yet
a
really
long
time
ago.
So
we
have-
and
we
still
have
two
issues
out
there.
So
we've
decided
that
we're
we've
removed
issues
from
it,
but
we'll
be
able
to
provide
a
hash
for
the
mr
and
then
that
would
be
like
the
source
of
change
for
the
chain
of
custody
anyways,
because
an
issue,
it's
so
loosey
goosey
it
tied
to
a
merge
request.
You
could
have
you
know
just
because
you
linked
a
merge
request
in
a
comment.
A
It's
going
to
be
tied
to
that
issue.
So,
but
if
that
change
made
me
not
really
there's
that
issue,
so
the
source
of
change
being
the
merge
request
is
what
we're
doing
and
then
I
think
we
have
a
couple
of
like
optimizations
and
you
know
using
like
a
Jason
B
file
or
some
change
to
make
that
a
little
bit
more
performant,
cuz
you're.
A
Absolutely
right,
like
we
can't
have
issues
and
merge
request
in
that
file,
and
then
we
change
some
stuff
around
like
on-demand
release,
evidence
generation
and
made
that
a
premium
feature,
which
will
then
mean
that
I
think
customers
will
have
to
pay
for
storage
too,
as
they
start
to
generate
more
files
like
that.
So
we'll
have
to
see
what
kind
of
implications
that
means.
A
Request
that
we
got
was
I
want
to
I,
have
a
release,
tag
that
is
I've
generated
at
the
beginning
of
the
month,
and
it
was
my
first
commit
for
my
release
and
it's
targeting
a
branch
of
future
branch
that
will
then
merge
in
a
master
and
will
deploy
to
our
environment.
So
this
this
release
is
a
tag
with
the
first
commit
that
started.
The
branch
and
they've
been
appending,
more
merge,
requests
and
additions
to
that
release
tag.
A
So
they
wanted
to
snapshot
the
state
of
the
feature
branches
production
before
they
merged
into
master
over
time
and
compare
that
so
they
didn't
have
like
a
the
to
me.
They
didn't
have
like
a
truly
continuous
delivery
or
a
deployment
model
and
that
they
were
always
merging
the
master,
keeping
master,
green
and
making
master.
You
know
the
most
recent
thing
that
you
would
then
deploy
from.
A
B
Like
this
pretty
little
in
a
stack,
it
was
just
only
one,
and
then
this
like
a
draft
pre-release
release,
is
continuously
being
updated.
Multiple
changes
in
semantics
release,
usually
privilege
tags
are
separated,
who
some?
If
you
make
a
change
like
at
first
you
make
a
pre-release
branch
pretties
tag,
then
it's
like
version
2.0
beta,
dot,
zero
and
then,
when
you
make
a
new
the
new
change
then
like
1.1
and
dot
T,
the
the
last
digit
is
being
incremented.
So
basically
it
doesn't
update,
what's
published
already,
always
creating
a
new
things.
B
A
B
A
I
would
say
at
least
75%
of
the
request
is
hey
I,
want
to
support
an
annual
or
quarterly
release
for
my
legacy
product
and
then
anybody,
that's
small
medium-sized
business,
so
the
mid-tier
market,
mostly
our
premium,
our
silver
customers
and
our
free
users
are
all
about
CD
and
they
just
want
to
tag
the
version.
That's
life
today.