►
Description
Watch this video of Bryan Cross for a tour of the exciting additions and changes to the GitHub User Experience we introduced at GitHub Universe. Learn how to automate code through PR Auto Merge, how to push code to GitHub with #Codespaces, our new Discussions, GitHub Dark Mode features and so much more.
All to make your experience as a developer just a bit smoother.
2:06 - Intro
3:23 - Demo Start
3:51 - GitHub Discussions
8:48 - Managing Dependencies
14:28 - Pull Request Auto Merge
17:51 - Enable Dark Mode
19:23 - Codespaces
29:11 - Issue labels and automatic workflows
VS Code container examples: https://github.com/microsoft/vscode-dev-containers/tree/master/containers
Join our next talk on What's next for DevOps! : https://github.co/next
Highlights from this video:
"For public repos now you can configure GitHub discussions, and the way that you do that is inside of your repo. Click on the settings tab and then scroll down on that initial page until you get to the features section here and just click the box for discussions. It's as easy as that and then when you scroll back up you're going to see that there's now a discussions item on your repo."
"Fundamentally discussions are designed to be different from issues so when we think of issues. They're to talk about an issue right so they're generally designed to be somewhat focused we're talking about a specific thing often in association with the work or the code that we're actually working on, and issues often lead to pull requests right so very much about specific aspects of our workflow. Discussions on the other hand are intended to be much more free form much more open and much more wide ranging. For example this might be a way for you to interact with your user community around broader questions like how do i use your tool, what are the pros and cons of your tool, what are the philosophical implications of what you're writing here."
"Now we're going to go on and check out possibly the most exciting the most complex and I think the most far-reaching and impactful of the features that we released at GitHub Universe and that's something called GitHub Codespaces.
Now before I get into that spoiler alert we're going to talk about a demo that we're working on here that really exercises a lot of the other features that we released at universe and that we released since then so if you weren't aware we now support multiple really as many environments as you like. You can have manual gateways so that somebody has to manually approve when code can be deployed to a given environment, and of course you can also specify secrets that are scoped to a specific environment."
"So VS Code what's that doing in there? These look like settings for visual studio (VS) code that i might have on my desktop for my visual studio code fat client. Right? Setting up tasks debug launch profiles and things like that well that's odd normally we don't store that in the repository..."
A
A
Hey
everyone
welcome
to
another
wonderful
demo
days.
It
is
friday,
it
is
also
the
end
of
january.
How
has
everyone's
january
been
pretty
pretty
chill
right.
Super
chill
january
hello
to
everyone
from
iran,
hello
to
our
friends
from
india,
always
happy
that
you
stay
up
so
late
to
watch
us.
So
it's
nice
to
see
you
all
here
good
morning,
good
evening,
good
afternoon.
Good
night
hope
you
all
have
had
a
good
january
and
have
an
exciting
weekend
planned.
Some
of
you
may
already
be
on
your
weekend.
A
B
B
So
today,
what
we're
going
to
talk
about
are
some
of
the
releases
that
came
out
of
github
universe
recently,
in
this
case,
what
we
inside
of
github,
call,
i2c
or
idea
to
cloud
but
which
you
as
developers
or
users
of
github,
probably
just
think
of
as
things
that
make
github
cool
to
use
and
make
my
life
working
in
github
easier.
So
without
further
ado,
let's
switch
over
to
the
the
screen
share
and
we
will
take
a
look
at
the
first
of
these
items,
which
are
discussion
so
get
up
discussion.
B
So
github
released
discussions
for
teams
a
while
back
and
those
have
been
pretty
well
received
and
pretty
cool,
but
those
are
really
oriented
more
around
discussions
inside
of
an
organization
not
really
oriented
towards
the
outside
world,
so
for
public
repos.
Now
you
can
configure
github
discussions
and
the
way
that
you
do
that
is
inside
of
your
repo
click
on
the
settings,
tab
and
then
scroll
down
on
that
initial
page.
B
Until
you
get
to
the
features
section
here
and
just
click
the
box
for
discussions,
it's
as
easy
as
that
and
then,
when
you
scroll
back
up
you're,
going
to
see
that
there's
now
a
discussions
item
on
your
repo.
So
what
do
we
do?
Well,
let's
click
on
discussions
and
and
see
what's
up
so
when
we
set
up
discussions,
github
provides
a
sort
of
a
sample
item
here.
So
here
is
a
an
initial
discussion.
B
Obviously,
there's
trade-offs
there
right
the
more
categories
you
have,
maybe
the
more
granular
you
can
split
up
your
community
but,
of
course,
there's
more
maintenance
and
it
can
be
more
complex.
So
these
are
the
four
that
are
built
in,
and
so
let's,
for
example,
select
a
q,
a
topic,
and
I
could
say
how
do
I
enable
discussions?
B
B
So
very
much
about
specific
aspects
of
our
workflow
discussions,
on
the
other
hand,
are
intended
to
be
much
more
free
form,
much
more
open
and
much
more
wide,
ranging
so,
for
example,
this
might
be
a
way
for
you
to
interact
with
your
user
community.
Around
broader
questions
like
how
do
I
use
your
tool,
what
are
the
pros
and
cons
of
your
tool?
What
are
the
philosophical
implications
of
what
you're
writing
here?
B
Discussions
like
that
now
earlier
we
talked
about
the
ability
to
customize
the
list
of
categories,
and
you
can
certainly
do
that
over.
On
the
left
hand,
side
by
clicking
on
the
pencil
icon
here
are
the
four
categories
that
already
exist.
We
can
edit
these
if
we
want
to-
or
we
can
create
a
new
category.
So
I
could
call
this,
for
example,
demo
days
discussions
about
demos
and
we
can
choose
from
a
couple
of
different
formats,
so
a
question
and
answer
format
will
provide
that
up.
B
B
And
there
you
go
so
I
have
now
created
a
new
discussion,
so
this
feature
is
in
beta,
but
it
is
available
so
go
out
and
give
it
a
shot.
We're
super
interested
in
your
feedback
and
would
love
to
know
how
you're,
using
discussions
to
really
broaden
the
conversation
and
expand
the
reach
not
only
of
the
work
you're
doing
but
of
your
thoughts
of
your
ideas,
your
influence
on
the
on
the
broader
world.
B
So
that's
discussions
and
next
I
think
we're
going
to
move
on
and
talk
about
some
of
the
things
that
we're
doing
to
make
it
easier
to
manage
dependencies
inside
of
your
repos.
So
here's
a
common
scenario:
I've
got
a
repository
here.
I've
got
a
couple
of
commits
into
this
repo
everything's
looking
good
and,
as
you
can
tell,
there's
no
depend-a-bot.
B
There's
no
dependable
warning
here
warning
me
that
that
I
have
issues
with
with
dependencies
right.
There's
it's
completely
clean,
which
is
great,
except
of
course,
I'm
going
to
need
to
add
some
dependencies.
Obviously,
in
order
to
to
finish
my
project.
So
let's
go
ahead
and
do
that
I'm
going
to
head
over
to
my
coding
environment
and
I
want
to
make
sure
that
I'm
in
the
right
repo
and
we're
going
to
check
on
our.
B
B
And
reopen
it,
so
that's
my
bad
for
not
doing
that
ahead
of
time.
Take
a
look
at
files
changed
right.
So
really
all
we're
really
doing
here
is
adding
a
whole
bunch
of
open
source
dependencies.
Now
our
repo
is
pristine.
At
this
point
we
don't
have
any
vulnerabilities
in
our
repo,
but
how
do
we
know
if
that's
the
case
after
we
merge
this
code
right?
I
can
look
in
here
and
I
can
get
a
pretty
good
sense
for
the
dependencies
that
are
being
added.
B
It's
a
little
bit
harder
to
do
that
for
the
packagelock.json
file,
because
that
includes
all
of
these
sub
dependencies
for
the
package.json
file.
It's
really
big.
It
can
be
really
hard
to
sort
of
figure
out.
What's
going
on,
so
we
have
expanded,
github's
rich
div
capability
to
provide
an
intuitive
look
at
these
dependencies
so
that
it's
much
easier
for
you
to
tell
at
a
glance
which
dependencies
are
being
introduced
and
which
are
are
being
removed
in
a
particular
operation.
B
So
when
I
click
on
the
rich
diff
button
over
here
to
the
right,
we
can
see
all
of
these
dependencies
here
in
a
much
more
readable
and
easy
to
understand
format.
So,
couple
of
things
to
note,
first
of
all,
yes,
it
looks
like
if
I
merge
this
pull
request,
I
will
in
fact
introduce
a
vulnerability
into
my
code,
so
I
will
I
will
destroy
that
pristine
state
of
my
repository
so
cool
at
this
point.
At
the
pull
request
stage,
I
can
decide
what
to
do
about
this.
B
Do
I
want
to
go
ahead
and
merge
it
and
take
care
of
it
later
or
do
I
want
to
take
care
of
it
right
now,
and
this
is
just
one
aspect
of
what
we
at
github
really
mean
when
we
talk
about
that
industry,
buzzword,
shifting
security
left
right,
so
we
want
to
be
able
to
be
aware
of
and
deal
with
all
security
issues
as
early
in
the
development
process,
as
we
possibly
can.
So
in
this
case,
I
can
prevent
this
vulnerability,
potentially
from
ever
getting
anywhere
near
my
main
line
branch.
B
Okay,
so
that's
a
vulnerability.
We
also
see
the
little
plus
icon
here
in
the
upper
left.
That
means
that
this
is
being
added
if
it
were
a
minus
icon,
that
would
mean
that
that
dependency
is
being
removed,
and
more
than
that,
I
can
actually
click
on
these
individual
hyperlinks
here
for
each
of
these
dependencies
and
go
directly
to
the
repo,
for
example,
that
contains
that
dependency.
B
B
B
I
think
I
have
added
some
dependencies
to
my
repo
so
yep
there
we
are
so
no
longer
pristine,
but
the
pinnabot,
of
course
has
reliably
and
faithfully.
Let
me
know
that
I
have
now
got
some
vulnerabilities
in
my
in
my
repository
okay,
so
that
is
what
we
call
dependency
review.
So
if
you
want
to
look
that
up
in
the
documentation
or
elsewhere,
it's
github
dependency
review.
B
Personally,
I
as
a
developer,
think
that
everything
that
the
github
can
do
to
make
me
aware
of
security
issues
as
early
in
the
development
process
as
possible
will
improve
the
security
of
my
code
and,
ultimately,
particularly
for
those
of
us
developing
for
open
source,
improve
the
overall
security
picture
for
all
of
open
source
and
software
in
general.
Okay,
dependency
review
all
right.
B
So,
let's
move
on
now
and
take
a
look
at
a
another
capability
that
we
introduced
into
the
platform
that
we
call
pull,
request,
auto
merge
and
if
you've
ever
heard
me
speak
before
you
know
that
I
often
say
that
I
think
that
github
is
a
fantastic
software
company.
One
thing
we're
not
super
good
at
is
naming
things
so
yeah,
that's
exactly
what
it
is
auto
merge.
B
So
here
I've
got
another
repo
and
I've
got
a
pull
request,
but
this
pull
request
is
broken
because
there
is
a
one
of
these
build
jobs
is
actually
failing.
So
what
can
we
do
about
that?
And
the
answer
is
enable
auto
merge.
Auto
merge
fundamentally,
is
nothing
more
than
a
merging
a
pull
request
when
all
of
the
conditions
that
are
necessary
for
that
pull
request
to
merge
are
met.
B
So,
for
example,
if
you
used
branch
protection
to
make
a
a
a
job
required,
as
we
have
done
here,
then
you
can't
merge
the
pull
request
until
that
job
returns
successfully,
but
with
auto
merge.
We
can
do
that
automatically.
So,
let's
first
of
all
figure
out
what's
wrong
with
our
code
and
then
enable
auto
merge.
After
we
fix
it
and
watch
this
just
disappear,
so
it
looks
like
it
looks
like
somebody
has
actually
broken
the
test.
B
So
what
I'm
going
to
do
is
I'm
going
to
go,
enable
auto,
merge
and
then
I'm
going
to
fix
that
and
then
we're
going
to
let
that
job
run
and
see
if
this
pull
request
just
magically
merges.
So
again,
it's
in
the
settings
section
there
is
an
allow
auto
merge
button.
This
is
a
beta
feature,
go
ahead
and
check
that,
and
then
you
have
to
enable
it
individually
for
each
pull
request.
B
B
Because
I
cut
out
all
of
the
stuff
that
takes
time.
Basically
all
we're
doing
here
is
your
standard
node
stuff
we're
going
to
build
it,
we're
going
to
run
ci
and
then
we're
going
to
run
npm
test,
and
now
that
I
fixed
the
test,
it
should
actually
work
all
right.
There
we
go.
There's
our
test
results,
love
the
full
annotation
in
the
in
the
logs.
The
job
is
complete.
Let's
head
over
to
the
pull
request,
oh
my
goodness,
it's
gone
because
it
auto
merged.
B
So
if
you
are
in
a
situation
where
you
are
sort
of
shepherding
a
whole
bunch
of
pull
requests
through
this
process,
this
will
save
you
from
having
to
remember
to
go
back
in
and
actually
manually,
merge
all
of
those
pull
requests
once
the
builds
and
tests
are
completing.
So
this
is
a
feature.
That's
been
requested
for
a
long
time,
and
it's
here
so
pull
request.
B
Is
this
I'm
going
to
click
on
my
personal
profile
up
here,
I'm
going
to
click
on
settings
down
here
in
the
middle
of
that
menu
and
then
you're
going
to
see
this
little
new
cartouche
here
and
a
completely
new
item
in
the
account
settings
menu
which
is
appearance,
and
we
have
two
choices
here:
I'm
going
to
select
dark
mode
and
boom
just
like
that
I've
got
dark
mode.
So
what
does
it
look
like?
It's
actually
quite
lovely.
B
Let's
head
back
over
to
that
pull
request,
we
were
just
looking
at,
for
example,
and
take
a
look
at
what
this
looks
like
when
it's
rendered
in
dark
mode.
I
just
think
it's
absolutely
lovely,
so
the
colors
are
great.
Folks
did
a
ton
of
work
on
this
and
in
typical
github
fashion,
it's
extremely
smooth
and
just
looks
fantastic.
So
there
you
go
dark
mode.
B
I'm
not
sure
that
that's
necessarily
the
best
for
demos
like
this,
however,
so
I'm
going
to
go
ahead
and
turn
mine
back
to
light
mode,
just
while
I'm
actually
on
the
air
with
all
of
y'all,
so
yeah
dark
mode
check
it
out
it's
in
your
settings.
Now,
if
you
have
dark
mode
on
everything
else,
and
you
work
in
a
dark
basement
like
I
do
sometimes,
then
github
won't
be
the
only
thing.
That's
spoiling
your
your
ambiance
okay.
B
Now
before
I
get
into
that
spoiler
alert
we're
going
to
talk
about
a
demo
that
we're
working
on
here
that
really
exercises
a
lot
of
the
other
features
that
we
released
at
universe
and
that
we
released
since
then.
So,
if
you
weren't
aware,
we
now
support
multiple,
really
as
many
environments
as
you
like.
You
can
have
manual
gateways
so
that
somebody
has
to
manually
approve
when
code
can
be
deployed
to
a
given
environment
and
of
course,
you
can
also
specify
secrets
that
are
scoped
to
a
specific
environment.
B
Now
we're
not
focusing
on
environments.
We
did
that
a
couple
of
weeks
ago
with
james
and
his
in
his
amazing
demonstration.
But
again
I
wanted
to
just
make
folks
aware
of
these
amazing
capabilities,
so
this
particular
demo
is
interesting.
What
we're
doing
is
we
are
creating
a
simple
bookstore
application
and
deploying
it
to
not
one
but
two
cloud
platforms
so
down
here.
I've
got
an
azure
environment,
I'm
going
to
right,
click
on
that
and
open
it
and
I've
got
a
gcp
environment.
So
now
I'm
looking
at
the
github
deployments.
B
These
are
all
the
deployments
to
this
environment
and
when
I
click
on
view
deployment,
I
actually
see
my
application.
So
this
is
this
simple
bookstore-like
application
on
azure
and
if
you
look
down
here,
we've
included
the
version.
So
now
we
can
make
that
tie
back
from
the
application
artifacts
that
were
actually
deployed
to
our
production
environment.
We
can
tie
those
back
easily
to
a
specific
tag
or
release
inside
of
github.
So
here
is
the
gcp
deployment,
I'm
going
to
click
that
and,
as
you
can
see,
I
actually
now
have
a
real
multi-cloud
environment.
B
So
some
point
soon
we're
going
to
walk
you
through
step
by
step.
How
you,
too,
can
set
up
a
multi-cloud
deployment,
leveraging
get
actions,
get
up,
workflows
and
github
environments,
but
that's
not
really
the
star
of
the
show
here.
The
start
of
the
show
here
today
is
how
we
actually
work
on
this
code,
so
looking
in
here,
you're
going
to
see
a
couple
of
things
that
you
might
not
recognize
or
that
you
might
think
shouldn't
even
be
in
this
repository,
so
vs
code.
B
What's
that
doing
in
there,
these
look
like
settings
for
visual
studio
code
that
I
might
have
on
my
desktop
for
my
visual
studio
code,
fat,
client,
right
setting
up
tasks,
debug
launch
profiles
and
things
like
that.
Well,
that's
odd!
Normally
we
don't
store
that
in
the
repository
and
then
there's
this
dev
container
folder.
What's
going
on
in
the
dev
container?
B
Well
I'll
show
you
right
after
I
fire
up
get
up
code
spaces,
so
I'm
going
to
click
on
the
code,
tab
I'm
going
to
click
on
the
code
button
as
if
I
were
going
to
clone
this,
but
I've
got
more
options
now
than
I
did
before
this
release,
and
one
of
those
is
open
with
codespaces.
So
if
I
click
on
that,
I'm
going
to
see
the
code
space
that
I
created
a
couple
of
days
ago
for
this
repository
or
I
can
create
a
new
code
space.
B
What
I'm
going
to
do
in
this
case,
though,
is
go
ahead
and
click
on
the
code
space
that
I
created
so
code
spaces
are
specific
to
an
individual
user,
so
each
user
would
have
their
own
code
space
potentially
to
work
on
a
given
repository
and
what
code
spaces
are
think
of
it
as
visual
studio
code
with
all
the
bells
and
whistles
all
the
settings,
all
the
extensions,
all
the
plugins
everything
running
in
a
container
in
the
github
environment.
So
what
does
this
mean?
B
So
one
of
the
first
things
that
you
have
to
do
is
set
up
your
environment,
and
this
can
take
anywhere
from
a
day
to
a
couple
of
days
to
a
couple
of
weeks,
making
sure
that
everything's
installed
dealing
with
all
the
conflicts
between
the
various
things
that
you
have
to
have
installed
in
a
workstation
virtual
machines
can
make
this
a
little
bit
easier.
But
there's
a
lot
of
overhead
around
that
as
well.
B
What
code
spaces
brings
to
the
table
is
the
ability
to
set
up
a
standard
development
environment
as
a
backer
for
a
essentially
a
web
browser
instance
of
vs
code.
So
as
an
administrator
or
somebody
who's
responsible
for
a
development
team,
no
longer
do
you
have
to
allow
developers,
days
or
weeks
to
to
get
set
up
instead
and
we'll
go
back
and
take
a
look
at
that
dev
container
folder.
B
You
basically
specify
all
of
the
settings
and
features
that
you
want
enabled
in
your
codespace
for
this
particular
repository.
So
codespaces
is
running
in
a
container
and
you
can
specify
what
container
that
is.
We've
got
that
right
there.
You
can,
for
example,
forward
ports.
So
in
this
application
we
want
to
forward
port
8080
out
of
the
code
space
and
5432
as
well
for
the
debugger,
so
that
we
can
actually
run
and
debug
code
live
in
our
codespace.
The
same
way
that
we
would
in
vs
code
on
our
desktop.
B
You
can
install
any
of
the
extensions
that
you
like
to
use
in
your
desktop
version.
There
are
no
restrictions
on
those
whatsoever
and
you
can
even
set
up
sql
tools
and
other
interactive
tools
that
extend
the
visual
studio
code
experience.
So,
let's
switch
back
over
to
our
container
and
we're
actually
looking
at
dev
container.json
and
walk
through
some
of
the
capabilities
of
this
of
this
code
space.
So
obviously
everything
works
exactly
the
way
that
you
would
expect
if
you
were
using
regular
code
spaces.
B
Let
me
show
you
what
I
was
meant
earlier
about
the
database
capability
so
down
here.
The
sql
tools
that
are
defined
in
my
devcontainer.json
right
here-
click
on
that
and
if
I
click
on
the
database
and
enter
the
password
and
now
what
I've
got
essentially
is
an
interactive
sql,
editor
right
here
in
my
environment,
so
I'll
just
enter
a
simple
query:
we're
going
to
run
that
on
the
active
connection
and
we
should
get
some
results
back
from
my
database.
So
this
is
the
actual
database
that
we
are
going
to
run.
B
B
You
can
also
run
your
tests
from
inside
of
a
codespace
as
well.
So
if
I
click
on
the
little
beaker
and
I
open
up
bookstore
advance
and
click
on
one
of
these
tests-
and
I
can
go
ahead
and
run
these
tests-
let's
use
the
in
memory
database
for
this,
because
it'll
probably
be
faster
and
again
it
works
exactly
the
same
way
that
tests
would
work
on
your
desktop.
B
We
can,
for
example,
click
down
here
on
the
test
results
and
we
get
the
test
report
so
again
almost
impossible
to
tell
that
you're
not
working
on
your
desktop,
of
course,
as
a
developer,
at
least
for
me
as
a
developer.
Interactive
debugging
is
one
of
the
most
important
things
that
an
ide
like
vs
code
brings
to
the
table
and,
of
course,
that's
going
to
work
just
fine
here
as
well.
So
I'm
going
to
click
on
the
debugging
icon.
B
My
launch
configuration
again
is
already
a
part
of
the
files
that
are
part
of
the
container
that
backs
this
particular
code
space.
So
I
don't
even
have
to
set
up
my
my
debug
launch
configurations,
I'm
going
to
go
ahead
and
just
start
it
up.
It's
going
to
start
running.
Obviously
it
takes
it
just
a
little
while
to
to
get
going
and
then
we
should
be
able
to
to
open
up
that
particular.
B
To
open
up
the
application
here,
one
thing
that
is
a
little
bit
random
sometimes
is
where
it
tells
you
where
the
actual
ports
are.
So
yesterday,
when
I
was
doing
this,
it
was
down
here
in
this
section
now
I
can't
seem
to
find
where
the
ports
are,
and
that
is
the
demo
gods
biting
me
in
the
back
of
the
neck.
For
for
some
reason,
perhaps
I'm
not
living
my
best
life,
but
typically
the
it's
going
to
create
a
a
url
that
you
can
access
and
actually
interactively
debug.
B
Your
application
inside
of
your
code
space
and
the
last
thing
that
I'm
going
to
show,
of
course,
is
the
fact
that
everything
from
code
spaces
works
exactly
the
way
that
you
would
expect.
First,
let
me
stop
this
and
then
we're
going
to
disconnect,
and
now
I'm
also
going
to
stop
jetty
here,
all
right.
So
all
my
services
are
stopped
and
I
am
good
to
go
now
all
of
the
tasks
that
I've
configured
for
my
desktop
vs
code
also
work
here.
B
So,
for
example,
if
I
have
a
task
that
I've
set
up
to
add
some
code
as
part
of
this
demo,
I
can
do
it
right
here,
so
I
can
just
click
on
this
and
it's
going
to
add
a
bunch
of
code
for
a
feature
that
I
want
to
add
to
my
to
my
code
and
then
I
can,
of
course,
click
on
the
source
code
section
and
push
that
code
up
to
github.
So,
let's
take
a
look
at
this
application.
B
So
I
actually
did
that
yesterday
because
it
takes
a
while
for
all
these
workflows
to
run
and
again
I
can
click
on
the
deployment
here
and
I
can
actually
see
my
test
version
of
this
application
once
again
with
the
tag
down
here
at
the
bottom.
That
allows
me
to
relate
this
test.
Instance
of
my
application
back
to
a
specific,
commit
specific
tag
inside
of
github,
so
notice.
In
this
case,
we've
got
this
star
rating
feature
here
at
the
bottom.
B
This
is
the
feature
that
we're
adding
and
it's
not
present
in
the
production
version
of
this
application.
So
when
I
commit
this
pull
request,
all
of
this
is
going
to
get
built
and
tested
again
all
the
containers
are
going
to
get
built
and
then
the
finished
application
will
be
deployed
to
both
azure
and
google
cloud
at
the
same
time
and
that
star
feature
will
again
show
up
here
in
this
production
environment,
so
code
spaces.
We
could
sit
and
talk
quite
a
long
time
about
code
spaces,
but
I
really
think
the
takeaway
is
is
this.
B
First
of
all,
it
is
a
browser-based
experience
that
is
effectively
exactly
the
same
as
the
desktop
experience
for
your
developers.
The
advantage
for
teams
and
even
individuals
is
that
you
can
configure
a
standard
development
environment
as
a
container
and
a
specification
in
a
repository
and
do
that
for
all
of
your
repo.
So
what
does
this
mean?
You
hire
a
new
developer.
A
new
developer
comes
to
your
team.
Their
ramp
time,
at
least
as
far
as
setting
up
their
environment
is
concerned,
goes
from
a
day
a
week.
B
In
my
case,
it's
usually
like
two
weeks
down
essentially
to
nothing.
We
have
essentially
completely
eliminated
the
need
to
create
your
dev
environment
in
the
first
place
and
if
you've
done
this
sort
of
work
for
any
length
of
time,
you
know
that
you
periodically
have
to
nuke
your
development
environment
from
orbit
in
order
to
get
rid
of
all
the
craft.
B
So
in
github
we
aspire
to
the
ideal
of
storing
everything
as
code
in
a
way
that
it
can
be
collaborated
on
easily
by
individuals
inside
of
github
differed,
built,
compiled
and
tested
so
development
environment
as
code
joins
infrastructure,
as
code
joins
configuration
as
code
and
with
get
of
advanced
security
security
as
code
all
right.
So
that's
what
I've
got
today
again,
we
are
highlighting
our
i2c
or
id
idea
to
to
cloud
releases
today.
B
Really
what
that
means
is
the
stuff
that
we
are
bringing
to
the
table
to
to
just
make
your
life
easier,
more
fun
and
more
delightful.
And,
of
course,
please
don't
forget
that
the
star
of
the
show,
at
least
at
the
universe,
presentation,
was
github
dark
mode,
so
give
dark
mode.
A
shot
check
out
dependency
review,
create
some
discussions
and
spin
yourself
up
some
code
spaces
so
pretty
much
at
github.
I
don't
work
anymore
in
my
desktop
vs
code
ide.
B
B
Yeah,
so
the
github
documentation,
of
course.
Oh
one
thing
I
forgot
to
mention
speaking
of
documentation
is
that
microsoft,
being
microsoft
and
github
being
github
we're
not
going
to
just
leave
you
with
a
cool
new
feature
like
codespaces,
without
a
literal
ton
of
example,
container
specifications.
So
you
don't
have
to
start
from
scratch.
B
You
can
go
to
the
microsoft
vs
code,
dev
dash,
containers,
repo
and
avail
yourself
of.
However
many
there
are
in
here,
it's
probably
close
to
a
hundred,
and
basically
you
just
pull
this
folder
over
put
it
in
your
dev
container,
folder
and
you'll
be
using
this
particular
configuration,
so
yeah
documentation,
obviously
check
out
vs
code
dash,
dev
dash
containers
and
the
github
community
on
the
github
forums
as
well.
So
lots
of
places
to
go
for
additional
information.
A
Awesome
and
if
anyone
has
any
general
questions,
you
can
always
go
to
github.comunity
and
ask
over
there
that's
a
great
place
to
to
find
out.
You
know
what
what
else
is
going
on.
There
are
always
tons
of
things
going
on
here
at
github,
and
one
more
thing
that
is
coming
out
really
soon
on
february.
4Th
is
we're
going
to
have
a
talk
on
what
is
next
for
devops
and
that
one's
going
to
be
a
really
cool
panel.