►
From YouTube: Remote Development Group Conversation Overview
Description
Eric Schurter, Product Manager for Create:Editor, provides context and updates related to the Remote Development category leading up to a public group conversation on 2022-11-02.
A
Hi
everyone,
my
name-
is
Eric
Schroeder
and
I'm,
the
product
manager
for
the
editor
Group,
which
is
part
of
the
create
stage
at
gitlab
and
I'm,
very
excited
to
share
with
you
an
update
on
the
remote
development
category.
We
have
a
group
conversation
coming
up
in
the
next
couple
days
on
November,
2nd,
2022.,
I
hope
you
can
join
me
for
that
synchronous
conversation.
But
if
you
can't
don't
worry,
I
have
some
links
at
the
end
of
this
presentation
for
how
you
can
follow
along
and
I'll
be
happy
to
answer
any
questions
asynchronously.
A
Our
goal
is
to
take
that
collection
of
dependencies
and
components
in
your
local
development
environment,
move
them
to
the
cloud
and
allow
you
to
seamlessly
connect
from
the
web
IDE
or
the
editor
of
your
choice
to
that
environment
and
negate
the
need
to
manage
your
local
environment
at
all
and
the
reason
we're
doing
this
is
because,
frankly,
developers
are
already
hit
in
this
direction.
We've
seen
increased
adoption
of
cloud-based
Ides,
including
our
own
web
IDE,
and
we
think
that
offering
a
more
complete
editing
experience
within
gitlab
will
accelerate
that
transition.
A
A
Customers
from
any
sector
you
can
imagine,
are
reaching
out
and
expressing
interest
in
this.
Whether
there
are
10,
000,
developer,
Enterprises
or
companies
with
20
to
50
developers
on
their
team.
We
think
that
it's
been.
The
adoption
of
these
workflows
have
been
accelerated
a
little
bit
by
the
global
pandemic
and
the
increasingly
remote
Workforce.
A
But,
generally
speaking,
the
majority
of
our
cloud-based
workflows
are
going
to
involve
a
remote
development,
environment
and
cloud-based
IDE
of
some
kind
in
the
near
future
and
those
customers
and
those
developers
that
have
already
adopted
these
workflows
are
noticing
that
the
availability
of
these
remote
development
environments
are
offering
benefits
in
a
variety
of
areas.
First
of
all,
accelerating
onboarding
and
improving
the
developer
experience
they're
able
to
get
people
committing
to
production
in
the
first
day
rather
than
taking
weeks
to
configure
a
new
computer,
or
something
like
that.
A
As
we
build
out
our
offering,
we
have
a
handful
of
guiding
principles.
I
want
to
highlight.
First
off,
we
want
to
be
platform
agnostic,
so
you
should
be
able
to
publish
and
provision
your
remote
environment
on
your
existing
Cloud,
whether
that
be
AWS
or
Google
cloud
or
or
eventually,
our
own
gitlab,
manage
platform
similar
to
our
shared
Runners.
They
should
work
equally
as
efficiently.
A
We
need,
you
need
to
be
able
to
connect
securely
to
the
environment
from
multiple,
multiple
vectors,
whether
it's
desktop
or
web,
in
order
to
be
flexible
and
integrate
this
into
your
team's
workflow
and
then.
Lastly,
the
environments
themselves
should
be
defined
in
an
easy
to
use
format,
that's
versioned
and
stored
alongside
your
source
code,
and
that
makes
it
easier
to
maintain
and
to
collaborate
on
optimizing
those
environments.
A
A
Community
we've
been
working
on
replacing
the
web
ID
with
an
instance
of
vs
code
running
entirely
in
the
browser
which
facilitates
the
connection
to
a
remote
host
that
we
have
proven
that
we
can
connect
to
and
right
now
we're
working
on
iterating
on
our
technical
direction,
for
our
our
more
complete
offering
that
allows
you
to
manage
the
environments,
Within
gitlab,
so
actions
speak
louder
than
words.
If
you
want
to,
you
can
try
out
the
new
web
IDE
it's
behind
a
feature
flag.
If
you're
on
self-manage,
you
can
turn
it
on.
A
It
is
not
feature
complete,
so
it
is
not
available
on
gitlab.com
yet,
but
we
are
working
on
it
once
that
is
available
to
you.
The
ability
to
configure
a
connection
from
a
the
web
IDE
to
a
remote
host
running
vs
code
server
is
available
to
you
and
it
works
great.
You
can
get
a
live
terminal
in
the
in
the
web,
IDE,
and
so
now
that
we've
delivered
that
minimal
experience.
In
the
web
IDE,
the
only
thing
that
doesn't
give
you
is
the
ability
to
configure
and
orchestrate
and
really
manage
those
environments
within
gitlab.
A
So
what's
next,
we've
we've
established
that
you
can
connect
from
the
web
ID
to
a
remote
environment.
So
now
we
want
to
be
able
to
define
those
environments,
dependencies
and
everything
store
them
in
the
repository
and
provision
them
within
gitlab
and
provide
Insight
in
a
dashboard
so
that
you
can
manage
those
resources
appropriately
all
within
gitlab.
Generally
speaking,
this
is
not
a
very
technical
architecture
diagram,
but
it
is
how
all
the
things
kind
of
connect
together
and
I
want
to
run
through
a
few
components.
Real
quick.
A
First
of
all,
as
I
mentioned,
the
Standalone
web
IDE
that
we're
working
on
replacing
the
existing
Monaco
based
web
ID
with
a
vs
code
based
instance
that
runs
entirely
in
the
browser.
You'll
have
a
access
to
extensions,
including
our
own
gitlab
vs
code
extension,
gitlab,
workflow
and
from
there
you
will
also
have
the
ability
to
connect
to
a
remote
host.
But
if
you
don't
want
to
manage
that
remote
host
manually,
what
you'll
be
able
to
do
is
Define
that
environment
in
a
Dev
file.
A
Dev
file
is
an
open
cncf
project
and
it's
supported
by
many
of
the
key
players
in
this
space.
You
are
given
an
extensible
schema
and
inheritance
model,
so
you
can.
You
can
build
very
complex
environments
in
a
Dev
file
and
then
we
will
build
a
custom
server
that
will
communicate
that
will
take
the
the
dev
file
communicate
with
the
gitlab
agent
for
kubernetes
to
provision
and
orchestrate
an
environment.
Based
on
that
description,
once
your
cloud
has
been
once
you're
container
has
been
for
vision
in
the
cloud.
A
We,
this
architecture
supports
being
able
to
Define
what
id
host
we
will
have
running
in
the
container
at
first
we'll
limit
it
to
vs
code,
but
eventually
we'll
be
able
to
do
things
like
offer,
jetbrains
or
Theo
or
or
maybe
even
alternative
editors,
and
then
we
also
realized
that
some
customers,
I've,
said
containers
a
few
times.
Some
customers
may
prefer
not
to
run
containers
themselves,
so
we're
investigating
options
for
Kata
containers
or
using
firecracker
to
to
give
sort
of
the
isolation
and
scalability
benefits
of
a
VM
within
the
the
kubernetes
cloud.
A
Now,
as
I
said,
if
you
want
to
contribute,
if
you
want
to
give
some
feedback,
we
have
some
links.
Our
Direction
page
is
available
and
I'll
put
this
video
on
the
direction
page.
So
you
might
have
found
this
video
from
there.
You
can
click
our
category
of
maturity,
epic
and
see
all
of
our
issues
and
what
we
have
planned
and
then,
in
slack,
if
you're
at
gitlab.
Here
we
have
a
couple
slack
channels
that
we'd
we
do
most
our
work
in.
So
please
drop
me
a
note.