►
From YouTube: UX Showcase: Frictionless runners
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
so
yeah
hi
everyone,
my
name
is
juan
ramirez
and
I'm
the
product
designer
for
runner
and
testing.
But
today
I'm
gonna
be
talking
specifically
about
something
that
we
have
been
doing
in
the
runner
group
and
it's
a
very
interesting
topic.
I
picked
this
topic
because
I
think
that
runners
is
something
that
we
always
hear
about
them.
We
always
know
about
them,
but
I
don't
think,
like
everyone
understands
them
well,
so
yeah,
it's
a
very
interesting
topic.
A
It's
called
frictionless
runners
and
I'm
gonna
be
talking
about
the
problem,
validation
that
we
have
been
doing
around
this,
but
I'm
also
gonna
take
some
time
to
briefly
explain
what
the
runners
are
and
like
the
role
in
the
whole
gitlab
stack.
So
before
I
jump
into
that
yeah,
just
the
the
classic
mention
to
all
the
team
here,
a
lot
of
people
involved
in
this
group.
This
is
a
group
that
has
a
lot
of
interesting
dependencies.
A
It's
very
backhand
and
we
mostly
have
back-end
developers
working
on
this,
but
there's
of
course,
some
front-end
and
some
ui
implications
that
impact
our
customers
and
I'm
gonna
be
talking
about
those
those
things
in
a
little
bit,
all
right.
So
the
goal
or
what
was
the
the
problem
that
we're
trying
to
validate
here?
A
So
if
you
go
to
the
direction
page
in
gitlab,
you
you'll
find
that
there's
a
very
significant
one
three-year
goal
for
the
verify
group
that
that
goal
is
provide
100,
automated
setup
configuration
scaling
and
management
of
the
gitlab
runners
for
medium
to
large
enterprises.
So
this
is
a
very
big
goal.
You
know
it's
somehow
a
little
bit
vague,
because
there's
many
things
here,
like
automation,
configuration
scaling
and
this
this
can
have
many
angles.
A
It
can
be
interpreted
in
many
ways,
but
basically
what
this
means
in
essence,
is
that
what
we're
trying
to
do
with
the
runners
is
allow
our
customers
who
need
them
to
be
able
to
provide
them
or
provision
them
in
a
very
easy
way.
A
We
couldn't
do
our.
We
couldn't
have
our
continuous
integration
offering
if
it
wasn't
for
the
runners
I'll
explain
that
in
a
bit,
so
the
problem
to
validate
here
is
the
runner
installation,
configuration
and
management
are
presumed
to
be
a
hard
manual
process
for
our
customers.
So
what
are
the
challenges
that
our
customers
are
facing
when
they
are
dealing
with
those
runners
and
with
the
runner
so
yeah?
I
I
wanted
to
first
explain:
what's
a
runner,
I
I
don't
think
everyone
here
understands.
A
Well,
what's
a
runner
and
that's
totally
fine,
that's
one
of
the
great
things
about
gitlab.
You
can
get
so
far
with
doing
ci
without
ever
knowing
what's
runner,
because
when
you
use
gitlab.com
they
we
have
our
own
managed
offering
of
of
runners,
and
as
long
as
you
have
a
valid
gitlab
cieml
file,
we
are
gonna,
run
those
jobs
for
you,
we're
gonna,
do
all
the
things
for
you.
A
So
it's
almost
by
design
that
runners
are
a
little
bit
opaque
and
that
yeah
they're
not
necessarily
a
concept
that
you
will
bump
into
frequently,
but
I
think
it's
very
important
to
understand
what
they
are.
So
basically
what
you're
seeing
here-
and
this
is
a
graph-
I
didn't-
do
this
graph.
I
just
found
this
online.
So
it's
it's!
It's
interesting
that
someone
did
the
job
of
making
the
explanation
easier
with
a
graph.
But
basically,
when
you
have
a
gitlab
stack,
you
have
several
things
right.
You
have
your
gitlab
installation.
A
If
you
are
self-hosted-
and
you
also
could
have
your
own
self-hosted
runners
right
and
what
the
runners
are
is
the
runner
is
an
agent
that
basically
takes
the
jobs
that
are
being
created
by
gitlab
and
github,
will
delegate
those
those
jobs
to
the
runner
and
the
runner
will
build
and
do
all
the
executions
that
are
happening
in
the
context
of
that
ci
configuration.
A
So
this
is
a
very
important
difference.
Right,
gitlab
is
one
thing:
gitlab
runner
is
another
thing
most
cases
they
live
in
different
machines.
They
are
operated
in
different
ways
even
internally.
We
have
different
release
processes
for
these
and
we
have
different
release
timelines
for
these.
So
when
13.0
or
13.1
goes
out,
that
doesn't
mean
that
the
runner
is
going
out
with
that
it
usually
ships
ships
with
different
cadences.
It
has
different
dependencies.
A
It's
all
it's
a
completely
different
animal
and
the
interesting
things
about
the
runners
is
that
the
runners
are
yeah
they're,
another
part
of
the
stack
and
you
can
install
them
anywhere
right.
You
can
install
them
locally.
You
can
install
them
on
aws.
You
can
install
them
on
google
cloud,
you
can
use
them
with
kubernetes
with
docker
with
shell
there's,
so
many
things
that
you
could
do
on
props
to
the
runner
team
because
they
have
created
such
a
beast.
A
You
know
it's
an
incredible
piece
of
technology
and
I
don't
think
there's
any
company
in
this
space
that
has
such
a
complex,
build
agent
like
gitlab
runner,
so
yeah,
it's
very
interesting
and
we
have
been
slowly
making
them
more
complex
and
I'm
more
interesting.
A
I
think
one
important
thing
that
I
wanted
to
mention
here
is
that
there's
a
big
difference
between
a
share
runner
in
gitlab.com
and
a
sure
runner
or
like
runner
in
general,
and
the
share
runners
are
the
runners
that
are
provided
by
by
gitlab
and
they
are
managed
by
gitlab
and
those
are
the
ones
that
are
consumed
by
our
customers
through
ci
minute.
A
So
our
customers
pay
for
cme
nodes
and
then
we
basically
out
to
scale-
and
we
have
these
internal
processes
that
allow
any
project
in
gitlab.com
to
delegate
jobs
to
the
share
runners.
I'll
talk
a
little
bit
about
that
in
a
minute.
A
So
those
are
the
runners,
so
the
problem-
validation,
validation.
Research
was
basically
talking
with
customers
trying
to
understand.
Why
are
they
using
self-hosted
runners
when
they
are
using
gitlab.com
right?
Because
if
you're
on
gitlab.com,
you
have
the
the
ones
that
are
managed
with
gitlab?
Why
are
you
choosing
to
pick
another
machine
and
registering
those
runners
in
a
different
machine,
so
yeah
that
there's
an
interesting
angle
to
that?
When
you
see
this,
we
also
were
interested
in
knowing
where
they
are
currently
hosting
the
runners.
A
A
So
the
current
findings
on
and
the
trends-
and
this
is
a
little
bit
fluid
and
it's
gonna
change
because,
as
I
said
before,
runner
is
an
animal.
Many
things
are
happening
and
this
is
a
complex
space
and
competitors
are
also
trying
to
do
many.
A
Many
interesting
things
in
this
space,
but
the
current
findings
are
that,
first
of
all,
people
who
use
self-hosted
runners,
they
do
it
primarily
out
of
security
concerns,
so
they
probably
have
compliance
issues,
maybe
they're
working
with
the
government-
and
I
mean
they
trust
gitlab
because
they
use
gitlab,
but
they
definitely
cannot
trust
that
those
jobs
are
being
handled
in
all
those
compliant
manners.
So
they
have
to
go
on
basically
self-hosted
runner
in
a
machine
of
their
own
and
figure
out
the
security
details
on
their
own.
That's
one
thing
that
we
found.
A
The
other
thing
that
we
found
is
that
aws
seems
to
be
very
popular
option
to
host
runners.
It's
just
basically
what
most
people
pick.
So
that's
an
interesting
finding.
We
also
found
the
gitlab
when
it
comes
to
buying
gitlab
and
kind
of
like
trying
to
justify
gitlab
as
cost
center.
A
Many
people
have
trouble
explaining
the
concept
of
ci
minutes,
and
basically,
customers
want
more
more
predictable
cost
rubrics
and
they
they
really
want
the
runner
to
be
part
of
a
more
holistic
offering
in
terms
of
pricing.
Also,
we
found
that
developers
in
general
don't
consider
the
process
of
installing
a
runner
painful.
I
mean
that's,
that's
an
interesting
finding
because
we
thought
it
was
painful,
but
they
they
have
more
issues
with
configuring
them
and
managing
the
managing
them,
and
especially
when
you're
doing
like
non-kubernetes
installations.
There's
there's
a
lot
of
caveats.
A
A
I
think
it
will
be
ideal
to
you
know,
make
this
better
and
automated.
We
also
believe
that
the
reason
why
they
don't
find
the
installation
problematic
is
this,
because
that's
another
thing
by
design
of
the
runners,
you
do
it
once
and
then
you
forget
about
it.
You
never
have
to
touch
them
again.
Only
for
updating
but
yeah
I
mean
that's
probably
the
reason
they
just
have
to
go
through
the
pain
once
it's
not
a
common
thing,
so
we
explore
many
things
and
we
have
been
exploring
many
things.
A
One
of
the
explorations
that
I
did
was
trying
to
find
the
friction
that
we
have
right
now,
where,
especially
when
they
are
provided
inside
gitlab
in,
what's
supposedly
the
smooth
way
of
providing
them
which
creating
a
cluster
from
gitlab
and
then
installing
them
through
that
cluster
and
yeah,
we
found
that
there's
a
lot
of
cognitive
load,
there's
many
things
that
are
not
working
that
well
and
that's
fine.
Many
of
these
things
are
not
even
our
fault.
A
Many
of
these
things
are
full
of
the
photo
of
aws
google,
google
cloud
that
have
their
own
problems
in
terms
of
ui
and
friction,
but
it's
good
to
understand
that
there's
issues
there
and
that
we
might
need
to
improve
up
on
that.
There
was
a
very
interesting
thing
that
I
I
found.
Someone
mentioned
this
on
the
channel.
There's
this
indie
developer,
who
created
a
website
that
is
called
gitlabrunners.com
and
what
that
service
does,
is
basically
provision,
self-hoster
runners
in
a
managed
way.
A
So
this
person
basically
creates
a
machine
for
you
and
installs
a
runner
for
you,
and
it
basically
makes
very
easy
the
process
of
installing
a
runner
and
they
sell
it
in
a
way
that
it
in
which
they
kind
of
like
try
to
say
that
the
main
benefit
is
speed.
So
it's
interesting
to
see
that
there's
some
kind
of
like
speed
concerns
about
self-hosted,
gitlab
runners,
but
yeah.
A
It's
also
interesting
to
see
that
this
exists
and
it
seems
to
have
certain
demand,
so
it
could
be
potentially
a
business
model
or
a
business
opportunity
for
for
gitlab
down
the
road
so
yeah.
I
did
analysis
on
these,
not
gonna,
go
into
much
detail,
but
it's
I
I
it
also
kind
of
like
show
some
of
the
friction
that
we
have
in
certain
points,
and
we
also
did
an
exploration
analyzing,
the
naming.
So
we
have
a
lot
of
concepts.
We
have
share
runners
match
by
gitlab.
A
We
have
show
runners
in
self-hosted
instances
we
have
group
runners
which
behave
a
little
bit
like
short
runners,
so
there's
many
things
on
these
and
we
have
been
doing
analysis
on
an
analysis
on
this,
because
we
also
want
to
improve
the
naming
and
make
sure
that
we're
not
creating
collisions
in
the
namespace
and
that
the
offering
is
very
clear
to
our
customers
that
when
they
hear
about
a
runner,
they
know
what
the
runner
that
they
are
using
is
doing
all
right.
So
a
lot
of
stuff
going
on.
A
So
we
are
working
in
many
areas
to
improve
this,
and
this
is
gonna
be
a
large
effort.
This
is
start
13.1,
13.2
and
beyond,
but
yeah
the
things
that
we're
working
on
right
now,
it's
basically
improving
the
experience
of
the
gitlab
runner
management
to
match
what
we
have
in
the
self-hosted.
So
this
is
basically
the
idea
of
managing
many
runners
from
a
group
level,
reducing
the
friction
to
get
runner
installation
instructions
right
now,
when
you
do
that,
you
have
to
go
to
the
documentation
open.
The
documentation,
read
a
bunch
of
things.
A
We
are
also
working
in
providing
new
ways
to
provision
runners,
especially
using
infrastructure
as
code
and
using
things
like
terraform
or
aws
cloud
formation.
So
that's
going
to
be
another
interesting
thing
and
we're
also
exploring
the
idea
of
having
one-click
installation
images
through
all
the
cloud
marketplaces
like
aws
marketplace.
Google
cloud
market
marketplace,
digital
ocean
marketplace,
azure
marketplace,
so
that's
gonna
be
another
way
to
make
this
very
frictionless.
A
But
this
is
very
complex.
I
can
keep
talking
about
that,
but
this
is
more
or
less
the
the
picture
that
I
wanted
to
give
you
guys
and
that's
what
I
have
thank
you.