►
Description
Release: Creating Releases in GitLab
by Rayana Verissimo, Senior Product Designer – Release
A
Hi
everyone
Iona
I'm
super
excited
to
be
sharing.
What
are
we
doing
on
the
release
stage,
and
today
they
do
some
of
the
steps
we
are
taking
to
improve
the
releases
capability
in
it
lab
just
a
quick
overview.
We
are
part
of
the
release
group
under
the
CIC
section,
so
this
focus
on
release
management
and
release.
Our
quest,
raishin
Reaser
castration
gives
us
the
the
ability
to
create
and
coordinate
complex
releases,
particularly
across
projects
in
the
most
efficient
way
or
currents
with
maturity.
A
Level
is
minimal
and
we
are
aiming
for
a
viable
and
releases
are
a
way
to
track.
The
liberals
in
your
project
and
approach
is
more
on
the
artifact
of
their
release
itself
and
inviting
the
checks
and
steps
into
it
rather
building
a
complex
workflow
so
quickly.
My
goals
for
today
are
to
share
with
you
the
results
of
nuran
visiting
of
UX
for
carfare
releases.
I'm
gonna
highlight
some
of
the
opportunities
we
identified
your
research
and
expose
their
proposed
designs
and
solutions
based
on
the
research,
the
findings
and
also
the
next
steps
cool.
A
Let
me
just
right
now
pin
as
I
mentioned,
this
effort
is
based
on
you
guys
for
card
for
releases
and
for
this
job
to
be
done.
We
are
working
with
multiple
personas
that
share
common
responsibilities
and
stats
in
the
Pipers
workflow.
Our
main
person
identified
is
a
release
manager,
but
pretty
much
anyone
in
project
or
in
the
organization
can
be
responsible
for
releases,
so
meanly
software
and
DevOps
engineers
and
our
job
to
be
done
is
when
tracking
and
important
deliverables
in
my
project
I
want
to
easily
create
and
manage
release
entries,
so
that.
A
Packaged
software
notes
and
files
for
people
to
use
this
was
our
initial
job
to
be
done,
and
the
first
core
after
conducting
heuristic
evaluation,
was
an
F.
The
first
value
experience
do
not
allow
users
to
create
or
update
releases
using
the
UI.
So
that's
pretty
much
the
whole
job
to
be
done.
People
could
only
do
that
through
the
API
so
based
on
the
heuristic
evaluation.
A
I
focus
on
the
most
painful
areas
of
the
workflow
and
easy
repair
is
involved,
creating
it
release
using
the
interface
making
a
clear
differentiation
between
Tennessee
releases
make
it
release
is
easier
to
find
associated
portal
data
with
it
and
also
general.
You
are
verification
and
I
propose
a
series
of
recommendations
and
those
were
implemented,
ones
that
touch
the
UI
or
a
touch
you
re
wax,
but
we
also
did
a
lot
quite
a
bit
improvements
on
the
API
side
as
well,
so
yeah.
A
So
the
goal
for
restoring
the
experience
baselines
were
to
conduct
three
user
interviews
with
both
internal
and
external
customers
responsible
for
release,
management's
and
orchestration
their
organization,
and
because
this
will
provide
availables
insights
and
remove
the
subjectivity
of
the
heuristic
analysis
that
I
perform
the
previous
quarter
and
also
the
intention
was
to
evaluate
our
hypothesis.
One
of
those
was
that
the
small
solutions
proposed
at
their
initial
recommendations
did
affect
the
experience
in
a
positive
way,
so
just
to
see
positive
results
for
the
implementations
and
its
design
proposals.
A
We
also
wanted
to
learn
from
different
personas
and
understand
how
users
are
creating
releases
with
it
lab
and
other
applications
and
we're
going
to
identify
any
roadblocks
users
encounter
when
creating
an
updated
release
using
the
UI,
as
well
as
identify
what
other
UI
UX.
Improvements
are
needed
to
support
users
when
creating
in
updating
a
release
so
I'm
just
quickly
fleshing
out
to
the
user.
A
Didn't
change
a
lot
I'm
not
going
to
dive
into
details
here,
but
it
steps
from
last
year
in
this
year
pretty
much
the
same
users
could
not
create
a
release
through
the
UI.
They
were
able
to
edit
it,
but
not
create
and
ask
you
a
lot
of
struggles.
The
frustration
persisted
and
you
can
see
that
in
the
mirror
board
based
on
user
input
and
the
this
knot
around
the
press
evaluation,
we
did
have
a
few
positives.
A
We
concluded
that
people
do
use
releases
at
least
partially
we'll
get
lab,
but
they
expect
it
to
be
more
powerful.
Participants
also
found
easy
to
add
in
a
release.
They
immediately
recognized
the
action
button
that
we
had
in
the
interface
to
edit
the
release
item
and
ever
overall
satisfied
with
that
experience
and
they're
also
super
happy
with
the
docs
Marcin.
Our
tech
writer
worked
on
improving
the
docs
experience
for
releasing
releases.
So
thanks
so
much
to
Marcy
that
was
awesome
and
moving
forward.
A
Users
would
love
to
see,
for
example,
more
best
practices
on
creating
releases
so
how
to
name
it
and
how
to
use
releases
with
issues
etc,
hours,
learning
opportunities.
We
found
out
that
not
all
tasks
can
be
completed
when
users
are
trying
to
create
a
release
using
it.
Let
be
why
we
already
knew
that,
but
it
was
nice
to
get
so
much
context
from
users
and
understand
different
workflows.
There's
still,
a
lot
of
money
were
working
for
that
requires
context.
A
Switching,
so
you
have
to
go
back
and
forth
through
the
UI
and
the
API
to
fully
create
a
release.
Tags
and
releases
are
confusing.
So
if
you're
not
familiar
with
the
current
application,
you
need
to
create
a
release
through
the
text
page.
So
if
you
want
to
edit
a
release,
you
need
to
go
to
the
releases
page.
People
are
not
super
happy
about
that.
A
Notifications
for
releases
are
hard
to
find
and
can
be
more
powerful.
People
want
to
customize
notifications,
Burundi's
type
or,
for
example,
decide
who
should
be
notified
before
after
release
is
created,
and
the
last
point
was
that
that
was
a
little
support
in
the
UI
that
will
link
to
relevant
information
about
releases,
for
example
in
our
docs,
so
the
score
stay,
as
is
enough.
People
still
cannot
create
a
release.
So
that's
half
of
our
job.
To
be
done,
they
can
add
it,
but
they
not
create
and
yeah
fear.
Not.
A
After
our
ideas
collected,
we
dive
into
some
more
interactive
design
solutions,
and
let
me
focus
now:
let's
see
yes,
so
from
this
whole
experience,
there's
three
men
inside
we
had
a
bunch
of
different
inside
what
are
three
main
ones
that
were
already
the
initial
assumptions
from
the
truck
to
be
done.
Exercise
but
after
collecting
this
data
really
push
it
forward.
A
A
A
So,
for
example,
release
notes,
change,
log
number
of
deployments
in
a
release,
there's
a
lot
of
details
and
we
are
partnering
up
with
plan,
so
hi
Alexis
on
the
bi-weekly
cadence
to
understand
how
releases
should
be
assigned
to
milestones
or
issues
and
how
milestones
are
being
utilized
for
planning,
and
we
come
up
with
the
with
the
insight
that
releases
will
be
a
time
box
that
customers
can
select
and
make
release
is
mandatory.
So
you
can
select,
select
a
tag
name
from
a
pre-populated
list
of
issues
in
the
Mart's
and
work
from
there.
A
So
this
is
an
ongoing
effort.
They'll
help
us
connect
to
our
product
vision
and
we'll
provide
capabilities
for
releases
across
gitlab.
As
a
whole,
so
that's
super
cool
and
yeah
we're
we've
had
it.
The
next
steps
will
continue
using
research
findings
to
help
prioritize
upcoming
deliverables.
I'll
be
working
breaking
down
the
design
decisions
into
smaller
chunks
and
to
identify
why
those
changes
are
valuable.
We
have
an
epoch
to
track.
A
Those
improvements
in
our
goal
is
to
make
releases
wide
by
1300,
so
that
is
close,
and
these
also
aligns
with
one
over
us
OPR
is
that
we
validate
the
karemera
maturity
for
movies,
orchestrations
and
finally,
probably
never
seen
you
again.
Here
is
Corey
talk
to
be
honest,
quarter-inch
of
easing
the
learnings
to
evaluate
the
experience
great
and
that's
about
it.
So
I
would
like
to
thank
you
for
your
attention
and
also
a
special
shout
out
to
Lori.
A
B
Again,
this
is
great
work.
It's
not
a
question,
but
I
wanted
to
say
it
was
great
to
see
how
you
are
taking
the
UX
score
cards
and
really
using
that
methodology
to
push
the
experience
forward
and
then
hearing
you
talk
about
how
you're
working
with
the
plan
team
to
think
about
this.
As
a
larger
experience,
that's
not
just
siloed
your
fantastic
thank.