►
Description
Presented by: Robbie Ostrow
Vanta’s engineering team grew from five to 55 in the last two years, but the team’s ad-hoc development environment scripts weren’t keeping up. Learn how Vanta adopted Codespaces organization-wide and how Vanta’s tiny Platfom Engineering Team maintains robust, speedy development environments for everyone—all without sacrificing the infinite customization that Vanta’s developers crave.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Hey
everyone
thanks
so
much
for
joining
me
in
this
virtual
session
scaling
vanta's
engineering
team
with
code
spaces,
I'm
Robbie
ostrow
these
days,
I
manage
the
platform
engineering
team
Advanta,
where
we're
trying
to
make
Internet
Security
less
hard.
Since
I've,
been
at
vanta,
we've
grown
from
three
to
330
people,
which
means
that
we're
constantly
looking
for
tools
that
can
grow
with
us
without
catastrophically
breaking
or
requiring
constant
maintenance.
A
Getting
the
right
tools
to
set
up
our
developers
for
success
is
probably
the
most
important
thing
we
can
do
to
ensure
we
can
continue
to
ship
great
features
quickly.
Today's
session
is
going
to
cover
what
we
look
for
in
a
developer
environment
and
how
we've
been
using
Code
spaces
to
meet
those
needs.
Every
single
one
of
our
developers
relies
on
code
spaces
today
for
every
line
of
code.
They
contribute
to
vanta
before
I
shell,
too
much
for
code
spaces,
though.
A
Let's
take
a
quick
tour
of
the
history
of
vanta's
developer
environment,
which
I'm
going
to
guess
matches
that
of
a
great
many
of
you
in
the
audience
who
have
scaled
a
startup
from
zero
to
one
phase.
One
you're
developing
on
your
laptop
you're
just
messing
around
with
an
MVP,
and
you
can't
justify
the
overhead
of
a
whole
development
environment.
After
all,
everyone
has
basically
the
same
context
and
can
debug
everything.
A
Phase
two
you've
started
to
hire
and
still
haven't
invested
in
a
ton
of
developer
tooling,
but
you
have
a
collection
of
scripts
that
generally
work
to
do
some
common
actions,
maybe
they're
even
Consolidated
in
a
makefile
by
now,
you've
upgraded
some
machines
in
the
cloud
because
a
you
figured
out,
you
should
be
developing
on
Linux,
not
your
fancy
new
Macbook
and
B.
You
need
a
little
more
Firepower
because
you
decided
your
tiny
startup
needed
to
run
kubernetes
phase
three.
A
It's
becoming
clear
that
new
developers
are
struggling
to
uncover
all
of
the
tips
and
tricks
that
you've
gathered
over
the
years.
Despite
your
best
attempts
at
documentation,
it's
time
to
build
a
bunch
of
internal
tooling
to
abstract
away
the
complexity
of
setting
up
and
maintaining
a
full-fledged
development
environment
and,
finally
phase
four.
You
realize
that
there
must
be
a
better
way:
vanta,
isn't
a
developer
tools,
company
we're
a
security
company.
A
We
should
be
focusing
on
our
comparative
advantage
and
Outsourcing
the
complexities
of
managing
developer
machines
to
software
much
more
battle
tested
than
our
brittle
set
of
scripts,
that
we
maintain
on
a
part-time
basis,
going
through
these
four
phases
of
fanta
over
the
course
of
about
three
years.
We
learned
a
lot
of
lessons
about
what
we
want
our
steady
state
to
look
like.
We
discovered
that
any
effective,
modern
developer
environment
must
be
fast,
it
must
be
ephemeral
and
it
must
be
standardized,
let's
start
with
what
it
means
to
have
a
fast
Dev
experience.
A
First
of
all,
developer
machines
must
be
fast
to
spin
up.
We
don't
want
an
engineer
to
waste
the
first
half
hour
of
every
day,
provisioning
a
new
machine
and
definitely
don't
want
a
new
hire
to
be
discouraged
when
it
takes
them
an
entire
day
to
set
up
their
machine
for
the
first
time.
We
want
Dev
machines
with
all
of
our
services
available
in
under
five
minutes,
even
though
we
have
dozens
of
microservices
to
build
that
together
take
over
an
hour
to
set
up
so
we're
left
with
a
pretty
fundamental
issue.
A
We
want
developers
to
be
making
progress
on
the
order
of
minutes,
but
getting
from
git
clone
to
a
working
developer.
Environment
takes
about
an
hour
even
on
a
powerful
machine.
When
code
spaces
released
the
pre-builds
alpha.
We
realized
that
it
might
be
the
solution
to
our
problems.
Of
course
it
was
an
alpha,
so
it
did
come
with
some
of
its
own
problems,
but
we
got
the
feature
working
in
under
a
day
after
trying
to
optimize
our
own
builds
for
months.
We
can
also
trigger
pre-builds
on
demand
when
we
have
a
cash
busting
change
on
Main.
A
Instead
of
wasting
their
whole
first
day
at
work
to
spin
up
a
code
space,
a
developer
just
has
to
run
GitHub
code,
space
create
or
click
the
button
in
the
console.
These
code
spaces
are
fully
fledged
servers
that
can
be
sshed
into
profiled
messed
about
with
and
have
arbitrary
software
installed.
This
video
is
showing
me
creating
a
code
space
and
connecting
to
it
for
the
first
time.
This
is
the
slowest
part
of
the
workflow,
but
it
still
completes
in
well
under
a
minute.
You've
probably
noticed
that
I
have
multiple
code
spaces
running.
A
There's
no
reason
to
do
all
your
work
on
one
we're
not
prescriptive
about
the
workflow
here,
but
most
people
have
a
code
space
per
feature
Branch
this
seems
expensive,
but
since
codespaces
shut
themselves
off
when
they're
idle,
it's
no
big
deal.
In
fact,
even
though
code
spaces
are
more
expensive
per
hour
than
the
corresponding
machines
on
AWS
or
gcp,
we
found
that
our
month-over-month
costs
are
flat
or
even
lower,
because
machines
aren't
running
when
people
are
asleep
or
in
a
long
set
of
meetings.
A
The
key
thing
to
notice
in
this
video
is
that,
when
I
list
the
running
services
on
a
brand
new
code
space,
we
already
have
a
bunch
of
microservices
running
any
developer
can
run
an
arbitrary
set
of
Services,
of
course,
but
we
found
that
setting
up
Engineers
with
a
default
minimal
set
is
a
key
way
to
make
them
feel
confident
about
their
developer
environments
and
not
disrupt
their
flow.
Not
only
is
it
important
to
us
that
these
machines
are
fast
to
spin
up,
they
also
have
to
be
asked
to
develop
within.
A
We
have
a
pretty
massive
typescript
code
base,
Advanta
that
can
make
the
typescript
language
server.
Really
sad,
we
also
love
our
lint
rules
and
code
generation
which
slow
down
development,
if
not
configured
correctly.
Luckily,
codespaces
supports
big
machines
that
allow
us
to
develop
effectively
and
remember.
Most
important
stuff
is
already
cached,
so
developers
can
rebuild
or
navigate
or
code
base,
with
ease
every
minute
that
a
developer
is
waiting
for
their
code
to
type
check
or
for
their
Editor
to
autocomplete
is
a
minute
they
could
be
doing
something
more
effective.
A
So
fast
is
important
for
us
wanting
fast
Dev
machines
is
table,
sticks
obvious
and
non-controversial
Dev.
Machine
ephemerality,
as
a
virtue,
might
be
a
more
interesting
point.
Let's
start
with
an
axiom,
Dev
machine
Divergence
is
evil.
Different
people
with
different
setups
are
just
impossible
to
debug,
monitor
or
write
effective
tooling,
for
let's
take
a
quick
example
of
something
we
do
all
the
time
upgrade
some
software
for
all
of
our
developers.
Npm
is
a
classic
example,
because
developers
on
different
versions
of
npm
are
liable
to
commit
different
package.jsons,
causing
lots
of
pain
with
long-lived
Dev
machines.
A
You
may
be
thinking
that
we're
damaging
the
developer
experience
by
not
allowing
this
careful
cultivation
not
so
we
found
that,
with
the
exception
of
maintaining
command
history,
which
we've
built
some
tooling
for
this
forces
developers
to
actually
interrogate
why
their
machines
needed
to
be
in
such
weird
states
to
begin
with
and
encourage
them
to
build
tooling.
So
the
whole
team
can
benefit
from
their
interesting
hacks.
All
developers
also
have
a
recent
snapshot
of
our
entire
staging
environment,
so
they
don't
ever
have
to
worry
about
running
migrations
locally.
A
This
ephemerality
has
allowed
us
to
tell
developers
Advanta
that
we
only
support
code
spaces
that
are
up
to
seven
days
old.
We
no
longer
have
to
worry
about
backwards,
compatibility,
we're
ensuring
that
we
aren't
breaking
old
workflows.
The
latest
workflow
is
the
only
workflow
our
platform
team
is
Tiny
and
it
has
a
ton
of
responsibilities,
Beyond,
maintaining
the
developer
environment,
so
reducing
our
support
burden
here
is
critical
to
being
an
effective
team.
This
goal
of
ephemeral,
Dev
machines,
is
really
in
service
of
standardization
across
all
of
our
developers.
Now
what
does
standardization
actually
get
us?
A
Besides,
easier
debugability,
we
found
that
standardization
in
the
right
places
eliminates
whole
classes
of
questions.
We've
set
these
code
spaces
up
such
that
port.
Forwarding
always
works.
Eslint
always
has
enough
memory,
the
amount
of
documentation
that
has
become
defunct
because
of
their
standardization
is
mind-boggling,
since
we
just
don't
get
these.
Why
is
this
thing
broken
in
questions
anymore?
Standardization
is
great,
but
we
have
highly
paid
software
Engineers
who
depend
on
their
favorite
tools
to
perform
their
craft.
A
I
myself
will
absolutely
refuse
to
work
if
a
cow
does
not
tell
me
a
fortune
every
time,
I
open
up
a
new
console.
So,
of
course
we
encourage
people
to
bring
their
dot
files.
Codespace's
first
party
support
for
pre-builds
and
for
DOT
files
is
the
perfect
combination
allowing
us
to
ensure
the
core
developer.
A
Experience
always
works
for
everyone,
but
allowing
developers
to
install
the
tools
and
customizations
they
need
on
top
all
this
together
and
a
lot
more
that
I
don't
have
time
to
cover
today
meant
that
the
whole
event
engineering
team
was
thrilled
to
move
from
ad
hoc
Dev
machines
on
AWS
to
code
spaces.
We
started
considering
the
migration
of
January
of
this
year,
moved
everybody
in
February
and
have
been
happy
ever
since,
and
in
the
rare
times
we
were
unhappy.
The
code
spaces
team
has
been
an
incredible
resource.
A
The
migration
was
a
surprisingly
painless
experience
and
while
it
did
require
a
few
extra
pings
to
some
stragglers,
it
honestly
wasn't
much
harder
than
the
migrations
we
had
been
doing
constantly
just
to
get
people's
long-lived
death
machines
in
the
same
state.
I'll
leave
you
with
four
final
tips:
first
use
pre-builds
to
do
as
much
work
as
possible.
Computers
are
cheaper
than
people,
but
make
sure
you
monitor
when
those
builds
fail
and
fix
them
immediately.
These
cached
builds
are
only
useful
if
they're
relatively
recent.
This
is
one
of
the
core
responsibilities
of
our
on-call
engineer.
A
Second,
encourage
your
team
to
use
short-lived
code
spaces
because
Dev
machine
Divergence
is
the
devil.
Third,
codify
necessary,
developer,
workflows
and
settings
in
your
shared
config.
This
will
eliminate
an
entire
class
of
bugs
and
finally
check
out
other
features
of
code
spaces.
We
love
using
Code
spaces
as
shared
preview
environments
using
public
URLs
and
configuring
code.
Spaces
to
sign
commits
for
us
there's
also
an
incredibly
tight
integration
with
vs
code
that
all
of
our
developers
use.
It
seems
like
the
editor
Wars
are
finally
over
there's
a
lot
to
discover
outside
the
broad
Strokes.