►
From YouTube: Лучшее из GitHub Universe 2020
Description
19-го января 2021 в 19:00 по московскому времени мы проведем обзор лучших моментов конференции GitHub Universe 2020. Мы покажем самые интересные моменты из более чем 40 докладов Universe с русскими субтитрами!
Темы обзора включают:
- Новые функции в GitHub Enterprise Server 3.0
- Codespaces
- Actions
- CodeQL
- Application Security Practices
- Работа инженеров GitHub над уменьшением "технического долга" в платформе GitHub
- Советы от наших партнеров по разработке программного обеспечения
Мы приглашаем вас присоединится к просмотру обзора на канале youtube.com/github. После просмотра, у вас будет возможность пообщаться с представителями GitHub и обсудить ваши вопросы и предложения!
A
A
A
A
B
A
A
A
C
Good
morning
welcome
to
github
universe.
Today
we
are
going
to
walk
you
through
how
we
use
github
at
github
and
along
the
way,
show
you
some
of
the
really
cool
new
features
we've
been
building,
let's
check
it
out.
I
start
my
morning
with
the
github
mobile
app.
I
check
out
my
notifications
and
I
catch
up
with
my
favorite
communities.
C
C
D
With
github
mobile,
not
only
do
I
get
push
notifications
for
things
like
comments,
but
I
can
keep
working
on
any
of
my
repositories,
no
matter
where
I
am,
let's
jump
to
neo's
pull
requests
and
take
a
look
with
ui
changes
like
this.
Sometimes
it's
hard
to
know
if
everything's
working
just
by
looking
at
the
diff.
D
C
Tens
of
millions
of
developers
use
github,
but
so
do
hundreds
of
thousands
of
companies,
including
some
of
the
biggest
in
the
world.
For
those
users,
we've
been
hard
at
work,
adding
all
the
new
features
you
saw
today
to
github
enterprise
server,
so
you
get
all
the
power
of
the
best
teams
in
the
world
running
on
your
company's
network.
That
includes
github
actions,
packages,
code
scanning
and
support
for
the
native
github
mobile
apps.
All
of
this
is
available
in
a
major
new
release.
We
call
github
enterprise
server
3.0.
B
B
E
E
Our
enterprise
server
includes
github
actions,
packages,
advanced
security
code
scanning
and
secret
scanning,
and
also
comes
with
support
for
our
ios
and
android
apps.
As
I
mentioned,
one
of
the
big
things
that
we've
been
working
on
this
year
is
to
add
gear
events
to
the
enterprise
cloud
audit
log,
and
I'm
just
going
to
show
you
briefly
how
that
works.
E
E
I
can
query
both
git
and
github
events
at
the
same
time,
if
you
want
to
or
just
one
or
the
other,
you
can
also
export
those
get
events
to
say
and
your
github
events
next
year
we'll
be
adding
those
get
events
to
this
ui
as
well
just
want
to
touch
briefly
on
some
branch
protection
rules
and
how
we're
extending
them.
You
might
have
seen
a
little
bit
of
this
in
the
keynote
if
you
managed
to
watch
it.
E
So
here
I
have
a
couple
of
branch
was
set
up,
which
means
that
any
code
changes
need
to
be
reviewed.
First
of
all,
by
a
third
party
and
then
by
my
code
owners.
Normally
often
a
security
or
expert
team
before
they're
merged
in
github
has
also
recently
expanded
the
same
concept
to
environment
protection
rules.
So
if
you're
using
github
actions
for
your
ci
cd
flows,
you
can
put
in
checks
on
environment
deployments.
E
E
We
can
see
a
pull
request
that
has
been
merged
in
and
then
deployed
through
my
environments
and,
as
per
my
rule,
it
has
been
approved
by
me.
This
is
one
of
the
biggest
things
that
we've
shipped
in
the
last
few
months
and
in
this
fame
we're
now
announcing
a
new
change
to
how
we
release
enterprise
server.
E
We
will
start
every
feature:
release
with
a
release:
candidate,
build
that's
a
build,
that's
gone
through
full
github
testing,
but
one
that
we're
putting
out
there
for
you
to
pick
up
test,
try
bash
around
and
give
us
feedback
on,
and
when
we're
happy,
based
on
your
feedback
that
it
is
very
stable
release
we'll
ga
it.
I
think
this
is
going
to
make
a
big
difference
to
the
overall
reliability
of
the
product,
and
I'm
excited
for
this
change.
So
github
has
really
built
the
community
standard
for
automation
with
github
actions.
E
Now
our
security
capabilities
have
grown
massively
over
the
last
year.
Advanced
security
offers
both
code
scanning
and
secret
scanning,
which
are
automated
security
scanning
tools
and,
in
addition
to
that,
our
dependency
alerts.
Automated
security
fixes
in
the
advisory
database
and
making
sure
that
both
private
and
open
source
repos
are
staying.
Secure.
A
F
Hi
everyone,
I'm
bailey,
I'm
here
with
matthew
and
we're
both
product
managers
on
github
code
spaces.
Earlier
there
we
announced
github
code
spaces
at
satellite
and
the
excitement
from
the
community
was
overwhelming,
to
say
the
least.
It
was
amazing
just
how
excited
the
community
was
to
be
able
to
have
a
cloud
dev
environment,
so
you
can
go
from
a
repo
on
github.com
to
a
running
code
space
within
seconds
without
any
setup
or
configuration
github
code
spaces
are
instant
cloud
developer
environments
code
spaces,
provide
you
with
a
machine.
F
F
The
goal
for
most
of
us
is
to
write
great
code
that
ships
value
to
our
customers,
the
open
source
community
ourselves.
Whoever
that
audience
is
the
goal
is
not
to
spend
your
time
doing:
local
dev,
environment
management,
although
it
can
consume
a
lot
of
your
time,
and
it
may
not
be
your
job.
Your
company
might
have
a
person
or
a
team
where
this
is
such
a
problem,
that
it's
become
their
job.
F
G
The
way
we
get
to
code
spaces
is
right
from
this
page.
We
can
go
to
the
code
button
and
right
inside
this
drop
down.
We
can
open
this
project
inside
of
a
codespace,
so
let's
go
ahead
and
do
that
and
talk
about
what's
happening
and
what
that
offers
us
for
this
project.
So
I've
created
this
code
space.
I
was
using
it
pretty
recently
and
I'm
going
to
jump
in
and
just
resume
an
existing
code
space.
G
So
you'll
see
we
connect
here
and
we
land
in
what
fields
and
really
is
vs
code
and
it's
vs
code
in
the
browser
and
for
me
personally,
this
feels
a
lot
like
home
and
the
reason
is
because
I
use
the
github
dark
theme
and
this
is
using
the
github
dark
theme.
But
if
I
had
another
theme
I
could
have
that
set
up
and
synced
across
my
code
spaces
as
well.
G
You
can
see,
I
have
my
custom
bash
prompt
here
and
my
dot
files
are
synced
over
automatically.
So
I
really
have
everything
that
makes
this
feel
like
I'm
developing
locally
you'll
even
see.
There
are
some
extensions
that
aren't
standard
here
that
don't
come
automatically
out
of
the
box,
so
I'm
also
able
to
bring
in
the
extensions
that
I'm
used
to
that.
I
like
to
work
with
and
use
them
all
inside
of
the
browser
for
this
code
space.
I
have
an
editor.
I
have
an
editor
in
the
cloud.
G
G
G
So
what's
going
to
happen
here
is
we're
going
to
connect
to
a
forwarded
port
from
this
code
space
and
it's
going
to
load
our
app
so
you'll
see.
I
have
this
app
called
haikus
for
mona
and
we
have
some
of
those
octa-cats
that
martin
was
just
talking
about,
and
I
have
little
haikus
that
we've
written
about
some
of
these
octa-cats,
and
this
is
really
cool.
I'm
running
a
node
app.
It
has
a
postgres
database
backing
it.
G
It's
not
super
complex,
but
I'm
able
to
get
the
full
app
running
with
a
container
for
my
web
service
and
with
a
container
for
my
database.
I
can
interact
with
it.
I
can
do
everything
I
would
do
to
build
this
app
locally
and
that
port
is
just
forwarded
on
securely
to
me,
but
we
also
again
have
vs
code
here,
so
we
can
do
more
than
just
run
our
app.
We
can
debug
our
app.
G
So
let's
go
ahead
and
run
this
app
with
our
debugger
attached.
So
you'll
see
we
have
the
app
our
port.
3000
is
forwarded
again
and
what
we're
going
to
do
here
is:
let's
just
set
a
breakpoint,
so
I'm
going
to
create
a
little
bit
more
space
here
and,
as
I
said,
this
is
a
pretty
basic
node
express
app
and
we
have
some
endpoints
that
are
defined
here
and
we
have
this
endpoint
for
for
the
heart
experience,
so
I
can
go
ahead
and
heart,
something
and
like
it
and
the
counter
goes
up.
G
We
hit
our
breakpoint,
so
we
can
jump
over
here.
We
can
actually
look
at
the
stack.
We
can
look
at
the
request
that
came
in
here.
We
can
step
through
this
function.
This
is
super
powerful.
I'm
able
to
you
know,
run
a
full
debugger
of
my
app
in
the
browser,
but
I
also
like
to
spend
a
lot
of
my
time
using
vs
code
locally,
and
I
want
to
go
from
vs
code
and
connect
to
my
codespace,
and
I
can
do
just
that.
G
So
what's
going
to
happen
here
is
this
is
going
to
take
a
second
it's
going
to
set
up
our
connection
and
then
we're
going
to
have
our
entire
code
space
in
just
the
state
that
it
was
right
because
we're
connected
to
that
remote
machine.
So
you
can
see
my
changes
are
here
and
I
can
go
ahead
and
if
we
want
to
make
our
commits
from
here
updates
for
live
demo
and
go
ahead
and
make
our
changes,
everything
looks
good
and
let's
go
ahead
and
push
them.
G
So
if
I
go
back
to
the
web,
we
can
see
this
full
end
to
end
I'm
going
to
use
the
command
line
with
this
nifty
little
trick
to
go
back
to
the
repo
and
you'll
see
updates
for
live
demo.
Here's
our
commit
you'll
see
that
it
kicked
off
github
actions.
So
it's
now
running
my
tests
and
we
did
all
of
this
from
the
code.
A
H
Github
actions
has
grown
massively
right
now
we
run
about
75
million
jobs
at
the
slide,
says
73,
but
I
looked
this
morning's
about
75
million
different
jobs
a
month
across
a
wide
variety
of
workloads.
Ci
is
probably
the
most
common
thing
that
people
absolutely
automate,
but
the
amazing
growth
has
really
come.
I
think,
due
to
the
community
and
if
we
look
across
sort
of
all
of
the
different
ci's
that
happen
on
github.
H
We
definitely
believe
actions
is
by
far
the
the
number
one
we
we
seem
to
do
the
most,
at
least
from
what
we
can
see.
We
actually
see
closer
to
10
000
different
actions
used
across
different
organizations,
and
we
think
that's
pretty
incredible,
because
that
means
people
are
are
both
using
the
community,
but
also
taking
advantage
of
of
using
actions
within
their
own
organizations.
H
H
If
you
look
at
our
public
roadmap,
we
have
something
called
manual
approvals,
so
this
is
configured
on
your
repo
settings
outside
of
the
workflow
and
when
you
try
to
deploy
to
a
given
environment,
if
a
set
of
reviewers
is
required,
the
system
will
pause
that
job
before
it
ever
goes
to
a
runner
and
send
out
a
series
of
notifications
and
require
a
person
in
this
list
or
or
somebody
in
a
team
to
come
and
say
it's
okay.
For
that
job.
H
To
continue
to
deploy
to
that
environment,
we
heard
from
a
lot
of
people
that
you
know
they
want
to
be
able
to
track
what
is
currently
in
a
particular
environment
whether
that
environment
is
production
or
if
that
environment
is
a
staging
or
whatever
starting
to
build.
This
new
activity
log
here
is
is
part
of
our
goal
to
to
really
move
in
that
direction,
and
this
is
kind
of
where
this
kind
of
four-ish
new
capabilities
comes
in,
because
this
deployments
view
actually
exists
in
github.
H
We
wanted
to
give
you
a
much
better
way
to
visually
track,
how
your
workflows
are
progressing.
You
know,
as
you
have
these
more
complex
workflows,
particularly
ones
that
do
sort
of
pipeline
style
deployments
to
different
environments
or
maybe
have
rich
matrices
or
other
concepts
having
the
ability
to
see
where
those
go
and
sort
of
track
their
progress.
H
At
this
very
visual
level,
we
think,
improves
just
the
overall
usability
of
actions,
the
usability
of
more
complex
workflows
and
the
ability
to
debug
potential
issues,
and
we've
also
started
to
do
some
other
work
to
integrate
in
other
places.
I
think
you
saw
in
the
keynote
nat
had
a
really
neat
little
vignette
at
the
end
where
he
launched
dark
mode,
and
you
saw
sort
of
a
sneak
preview
of
some
work,
we're
doing
with
the
mobile
app.
H
We've
also
done
a
lot
of
work
with
the
team
who
works
on
the
slack
integration
to
integrate
those
there
and
you'll
start
to
see
these
roll
out
again,
and
we
we
think
that,
as
we
use
all
of
these
endpoints
for
github,
we
can
really
help
drive
that
culture
of
of
rapid
deployment
and
unblocking
your
team
from
where
you
are
exactly
how
you
need
to.
We
think
that
pull
all
those
things
together
really
do
add
up
to
the
ability
to
do
very,
very
rich,
continuous
delivery
workflows
with
github
actions.
H
I
I
One
other
thing
that
I
also
added
to
in
my
my
workflow
is
adding
lighthouse
now.
Jake
jarvis
actually
has
this
lighthou
lighthouse
action,
and
the
one
thing
that
I
do
for
my
deployments
is,
I
deployed
to
netlify
and
the
reason
why
I
chose
this
is
that
every
time
there's
a
netify
deploy
preview
on
my
project,
which
is
open
source.
I
actually
get
an
entire
preview
directly
linked
inside
of
my
pull
request,
which
is
beautiful,
because
I've
been
using
this
other
action.
I
I
built
called
logify,
which
also
brings
my
previews
into
the
deployment
logs.
First
and
foremost,
I
don't
have
an
example
about
this
in
cd,
yet
because
it
again
they
just
launched
yesterday.
But
what
I
like
about
this
is
that
I
get
lighthouse
scores
every
time
I
open
a
pr.
So
if
I
have
a
pr
from
someone
else,
because
I
just
open
source
project
anybody
else
in
the
community,
I
actually
can
find
out
if
I've
got
like
a
degradation
of
my
lighthouse
core
or
performance
or
accessibility
right
there.
I
In
line
with
the
pr
and
when
I
talk
about
sort
of
identifying
repetitive
tasks.
Every
time
I
open
up
a
pull
request.
I
want
to
make
sure
accessibility
and
performance
do
not
go
down.
I
want
them
to
stay
consistent
or
go
get
better,
so
I
bring
that
up
because
with
the
lighthouse
action,
I
can
actually
embed
those
lighthouse
scores
within
my
action
logs.
I
So
that
way,
not
only
in
my
actual
logs,
but
also
in
the
pr
comments,
and
it's
all
powered
from
this
one
action
which
is
beautiful
and
like
you're,
probably
thinking
you
know,
lighthouse
is
already
embedded
in
chrome
like
you
just
open
up
the
chrome
tab
and
like
this
know
what
you're
doing
and
check
that
before
you
merge
the
pr
and
the
thing
is,
I
won't
do
that.
I
won't
do
that
for
anybody's
prs.
I
J
I'm
really
excited
about
talking
about
building
your
community
with
github
discussions
which,
as
of
tuesday,
is
available
for
all
repos
and
public
beta,
and
so
thousands
of
you
have
turned
it
on
since
then.
I
want
to
quickly
talk
about
the
open
source
ecosystem
and
why
github
discussions
exist
in
the
first
place.
J
J
We
want
to
keep
q
a
and
conversation
separate
from
github
issues,
but
we
also
don't
want
those
to
be
completely
detached
either.
Their
relationship
is
important,
so
you
can
think
of
github
discussions
as
the
living
room
of
your
open
source
community.
If
you
haven't
enabled
discussions,
yet
I'm
going
to
show
you
how
now
so
to
start
you're
going
to
want
to
go
to
your
repos
settings
page
and
then
you
can
go
on
that
default.
J
Now.
If
you
have
issues
that
should
be
discussions,
you
can
cover
those
individually
convert
them
in
or
in
bulk.
So
if
you
wanted
to
do
it
in
bulk,
you
can
go
here
to
the
label
section
here.
We
selected
the
question
label,
obviously
probably
the
best
one,
for
that
is
a
q,
a
category
and
there
you
go.
J
All
you
have
to
do
is
click
that
button
and
you're
going
to
convert
those
from
your
issues
over
to
your
discussions,
and
you
can
see
that
over
on
your
discussions,
page
every
repository
comes
with
a
default
set
of
four
categories:
general
ideas,
q,
a
and
show
and
tell
but
these
can
be
modified.
I
think
the
most
important
thing
about
categories
is
that
you
get
to
set
the
tone
here
to
help
the
community
know
what
to
expect
and
where
to
go.
Let's
get
directly
into
the
mechanics
of
marking
an
answer.
J
So
anyone
with
triage
plus
access
or
the
author
can
do
this,
and
this
is
kind
of
what
it
looks
like
when
you
find
an
answer
to
a
question.
You
can
click
on
the
check
box
and
a
great
box
will
appear
and
you
can
see
who
marked
the
answer
and
it'll
be
recorded,
so
you
can
even
see
who
marked
it
right
underneath
now
we
have
all
the
tools
that
we
need
to
manage
existing
discussions.
Let's
talk
really
briefly
about
some
enhancements.
J
We
have
to
improve
the
community's
interactions
and
first
things:
first,
you
can
see
right
here,
there's
a
leaderboard
on
the
right-hand
side
and
it
shows
people
with
the
most
answered
discussions.
Finally,
I
wanted
to
briefly
talk
to
you
about
what
you
can
do
with
triager
write,
maintainer
and
admin
permissions
and
as
far
as
discussions
go,
people
with
write
maintain
admin.
Access
can
basically
do
the
same
thing
with
two
exceptions.
J
So
people
with
maintain
and
admin
access
can
enable
discussions
together
from
the
settings
page
and
also
they're,
the
only
ones
who
can
create
and
edit
categories,
but
otherwise
they
have
the
same
permissions.
And
that's
basically
it
that's
what
you
have
so
we
talked
about
getting
started
categories.
New
discussions,
marking
answers
how
you
can
use
the
information,
the
site
to
provide
recognition
and
how
to
moderate
and
keep
the
community
healthy.
So
here's
an
example
here
where
snowpack
has
used
the
a
pin
discussion
as
their
change
log,
and
so
it's
kind
of
pinned
at
the
top.
K
K
Github
is
where
the
world
builds
software
over
50
million
developers,
trust
github
to
collaborate,
test,
build
and
deploy
code,
including
over
70
percent
of
the
fortune
50..
In
fact,
in
the
last
year,
over
60
million
new
repo's
were
added,
and
over
1.9
billion
contributions
were
made.
Those
are
some
seriously
big
numbers.
The
stability
and
resilience
of
our
global
platform
is
critical
to
providing
developers
with
a
platform
they
can
count
on.
Github
enterprise
is
built
on
the
same
principles
as
github.com
and
as
a
result
benefits
from
the
years.
K
We've
spent
optimizing
the
platform
to
be
trusted
reliable
and
resilient
from
day.
One
we've
focused
on
building
great
products
and
experiences
for
the
developers
who
spend
their
days
or
their
nights
on
github
from
pull
requests
to
code
spaces
actions
to
code
ql
and
everything
in
between
our
vision
is
to
build
the
home
for
all
developers,
whether
they're
working
on
a
fun
side,
project
or
building
mission,
critical
software
for
fortune
500.
K
L
We're
going
to
talk
about
this
state
of
security
today,
so
my
favorite
analogy
for
this
is
imagine
that
you
just
built
your
most
amazing
favorite
mansion
and
you
have
just
installed
all
the
most
expensive
furniture
and
all
the
most
expensive
appliances,
and
you
just
forgot
to
install
doors.
So
this
is
sort
of
how
we
treat
security
today
we
just
kind
of
say:
okay,
we
have
time
for
this.
We're
just
gonna
first
deliver
on
all
of
the
features
and
then
we're
gonna,
basically
add
some
locks
on
the
doors
and
some
doors
to
our
mansion
right.
L
Because
features
is
what's
important.
If
we
look
at
the
chart
of
how
we
deliver
code,
then
we
actually
see
that
the
more
lines
of
code
we
write
the
more
security
threats
we
actually
introduce,
and
so
we
don't
learn
from
our
mistakes.
We
just
basically
continue
committing
bugs
and
moving
on
and
just
like
committing
secrets,
committing
security
vulnerabilities
into
our
main
code
base,
and
despite
that,
as
developers,
we
often
treat
it
this
way.
So
we
just
basically
say:
okay,
it
works
in
dev.
So
it's
security
problem
now
right,
so
I
have
developed
my
code.
L
Basically,
we
have
about
45
million
estimated
developers
and
only
70
000
estimated
security
researchers
in
the
world.
So
today
I'm
going
to
basically
talk
about
how
github
can
help
you
fix
your
security
issues
for
you.
So
we
have
a
large
number
of
features
in
on
github
advanced
security
that
can
help
you
integrate
security
into
your
developer
experience.
So
it's
not
extraordinary
to
what
you
do,
but
rather
it's
shifted
all
the
way
left
and
integrated
into
your
development
lifecycle.
L
So
basically
we
help
you
secure
multiple
parts
of
your
code,
so
we
help
you
secure
the
supply
chain,
the
code,
the
development
life
cycle
and,
of
course,
your
platform.
But
today
I'm
gonna
talk
specifically
about
the
code
part,
so
we
can
see
that
almost
fifty
percent
of
all
the
breaches
in
the
world
actually
include
stolen
credentials
and
yet
we're
pretty
bad
about
not
committing
these
credentials
or
these
secrets
into
source
control.
L
As
repositories
and
this,
where
secret
scanning
actually
comes
in,
so
we
have
different
sort
of
different
oriented
features
for
public
and
private
repo,
so
I'm
going
to
start
with
public
repos
for
public
reapers.
We
actually
have
secret
scanning
for
a
number
of
years
already
and
we
are
doing
it
at
massive
scale.
We're
scanning
about
150
million
pushes
a
week.
L
So
basically,
we
then
send
the
matches
to
a
partner,
verify
endpoint,
and
then
the
partner
can
verify
if
it's
a
real
secret
or
if
it's
not
and
then,
depending
on
what
the
partner
wants
to
do
with
this.
Sometimes
they
revoke
the
secret,
and
sometimes
they
also
email,
the
user
right.
So
basically,
we
have
this
process
in
which
completely
transparent
to
the
user.
In
some
cases,
your
secret
actually
got
gets
revoked
by
the
partner,
and
so
your
secret
is
no
longer
in
the
repository.
A
A
M
So
github
code
scanning
earlier
this
year,
we
announced
it
and
code
scanning
does
exactly
what
it
says.
On
the
tim.
It
scans
your
code
for
security,
vulnerabilities
and
any
alerts
we
find
in
pull
requests
or
automatically
flagged
up
to
you
so
that
you
can
fix
them
before
you
merge
the
code
changes
into
your
main
branch
that
particular
code
patterns
could
be,
for
example,
a
server
side,
template
injection
vulnerability
when
you
run
codeql,
whether
that's
in
code
scanning
or
on
your
own
local
machine.
M
The
first
thing
it
will
do
is
it
extracts
all
of
the
source
code
that
you
have
into
a
special
relational
database
in
a
way
it's
similar
to
a
mysql
or
a
postgres
database.
It's
a
very
special
one,
though
special
purpose
built
read-only
one.
We
call
it
a
ql
database
and
just
like
with
my
sql
and
with
postgres,
you
can
run
queries
against
that
database
and
in
fact,
a
code.
M
Ql
query
looks
a
bit
like
a
sql
query,
but
it's
a
lot
more
powerful
I'll
show
you
one
in
in
the
live
demo
that
I've
got
now
a
code.
Qr
query
is
a
way
to
sort
of
interrogate
and
explore
your
source
code.
A
very
simple
query
might,
for
example,
look
for
a
variable
called
password
that
you
then
write
to
a
plain
text:
log
file,
more
advanced
security
analysis,
more
advanced
queries
do
very
intricate
flow
analysis.
They
track
where
user
control
data
enters
your
application.
M
M
Now,
in
a
way,
every
query
captures
the
security
knowledge
of
a
security
researcher,
and
by
codifying
that
knowledge,
that
we
can
apply
it
at
a
massive
scale.
So,
for
example,
we
run
kql
against
hundreds
of
thousands
of
repositories,
and
every
single
query
result
that
we
get
is
a
is
an
alert
in
code
scanning.
N
N
Those
are
things
that
get
allocated
to
features
whatever
you're
allocating
your
people,
your
money
and
your
time
to
those
are
the
features
you're
working
on
whether
you're
calling
calling
them
a
feature
or
not
and
then
features
well,
generally
speaking,
if
you
build
it,
you're
gonna
make
sure
that
it's
regularly
tested
you're
gonna
make
sure
that
it
works.
The
way
that
you
want
it
to
and
you're
gonna
make
sure
that
it
continues
to
get
enhanced
over
time.
N
N
So
why
isn't
security
considered
a
feature,
and
this
is
kind
of
an
interesting
topic,
because
one
of
the
things
that
I'll
often
ask
dev
teams
after
they've
done
some
security
review
of
their
applications
is
they'll
say:
do
you
have
a
banking
app
on
your
phone
now
that
doesn't
always
translate
depending
on
where
you
are
in
the
world?
Some
cash
heavy
cultures,
don't
really
use
banking
applications
might
do
ecommerce,
but
alaska
dev
ar
are
you
using
some
some
sort
of
financial
transaction
application
on
your
phone
and
the
answer
is
almost
universally
yes.
N
I
like
to
say
this
is
kind
of
like
the
faucet
that
you
go
to
or
the
sink
that
you
may
go
to
and
when
you
turn
that
left
knob,
you
expect
the
water
to
be
hot.
That's
universally
true,
you
didn't
have
to
ask
anyone
for
it
and
you
didn't
have
to
tell
the
plumber
to
install
it
that
way.
It's
just
the
way
that
that
operates,
and
so
in
a
lot
of
ways.
N
That's
the
way
that
people
think
of
security
today
is
it's
one
of
those
utilities
that
you
just
expect
it
to
be
there
and
expect
it
to
work
as
intended.
There
are
benefits
to
treating
security
as
a
feature,
a
good
example
of
that,
as
attack
complexity
increases.
One
of
the
things
that
I
like
to
think
about
here
is:
why
are
phishing
attacks
still
so
prevalent,
because
people
fall
for
them?
N
It
ends
up
being
state
actors,
as
opposed
to
cheeky
kids
on
the
internet,
for
example,
and
so
that
way
your
application
will
be
a
little
bit
more
robust
and,
quite
frankly,
you're
out
running
a
majority
of
the
bears.
Of
course,
it
also
differentiates
your
project
or
your
product
if
you
think
about
apple,
for
example,
they're
almost
universally
known
for
a
lot
of
the
security
and
privacy
implementations
that
they've
put
in
place.
We
can
also
look
at
examples
within
the
software
development
landscape,
such
as
react
versus
angularjs
back
in
the
day
angularjs.
N
And,
of
course,
once
you
go
ahead
and
invest
in
security
as
a
feature,
it
allows
you
to
save
time
and
money.
It's
that
return
on
investment
that
compounding
interest
that
allows
you
to
actually
go
ahead
and
focus
on
other
investments
and
experimentation
so
that
you
can
grab
more
market
share
and,
of
course,
differentiate
your
product
and
then
pay
down
those
other
technical
debts
that
you
might
be
encountering
and
then,
of
course,
in
terms
of
some
tools
that
you
can
use.
I
like
to
say
with
static
analysis.
Github's
advanced
securities
toolset
is
phenomenal.
N
If
you're
on
the
github
platform,
which
I
would
think
that
you
probably
are,
if
you're
watching
this
and
then,
of
course,
osp's
dependency
check
tool.
If
you
need
another
thing
to
go
ahead
and
look
into
the
environment
and
make
sure
that
things
are
working
appropriately
and
the
libraries
you're
using
are
fresh
and.
A
O
Here
at
github,
we're
really
focused
on
understanding
security
from
the
developer's
point
of
view,
because
empowering
developers
to
build
secure
code
is
one
of
the
best
ways
to
move
the
needle
on
your
security
story.
Now,
there's
a
ton
of
great
data
in
the
state
of
the
octoverse
report
this
year,
but
one
of
the
things
that
I
like
to
point
out
is
how
developers
introduce
security
vulnerabilities
at
a
relatively
constant
rate
with
every
line
of
code.
That's
written
and
that's
not
me
criticizing
developers.
O
I
don't
write
the
code
and
I
know
just
how
hard
it
is.
This
should
really
underscore
that
writing
secure
software
is
really
hard.
It
doesn't
matter
how
smart
your
team
is.
It
doesn't
matter.
You
know
how.
Well
you
hire,
there's
a
reason
that
mitre
has
so
many
different
cwe
buckets
it's
because
as
humans
we
tend
to
introduce
the
same
kinds
of
problems
over
and
over
again,
around
83
percent
of
applications
have
at
least
one
security
vulnerability
in
them.
O
Organizations
that
adopt
devsecops
practices
run
and
run
security
scans
daily,
reduce
their
mean
time
to
remediate
security
problems
by
around
72
versus
organizations
that
run.
You
know
just
a
few
times
a
year,
so
that's
why
we
at
github
have
been
hard
at
work,
with
a
collection
of
security
solutions
that
we
call
github
advanced
security
within
github,
advanced
security.
We've
got
three
major
product
areas.
O
O
Finally,
secure
secrets:
we
know
credential
leaks,
are
a
huge
problem
both
for
security
and
reliability.
Reasons
I
mean
have
you
ever
tried
to
roll
keys
on
an
app
where
someone
hard-coded
credentials
into
the
source
code
instead
of
putting
them
into
the
key
vault?
It's
not
going
to
be
a
good
day.
You're
going
to
cause
an
outage
and
everyone's
going
to
be
unhappy,
so,
let's
drill
in
dependency
review
is
a
brand
new
capability
that
we
unveil
unveiled
here
today.
O
O
That's
why
we've
made
it
really
easy
to
view
results
in
code
scanning
super
easy
by
integrating
those
alerts
into
pull
requests
and
making
sure
the
developers
are
only
blocked
when
they
introduce
a
net
new
vulnerability
in
their
code.
That
way,
when
you
have
a
lot
of
security
debt,
it's
not
going
to
come
up
every
day.
It's
not
going
to
slow
you
down,
it's
still
there
and
we
hope
you'll
fix
it.
But
it's
not
in
your
way.
Codeql
is
the
semantic
analysis
engine
that
powers,
our
own
security
analysis.
O
Now
a
lot
of
static
analysis
tools
out
there
do
things
like
use,
regular
expressions
or
look
at
bytecode
to
try
and
figure
out
what's
happening,
codeql.
We
actually
map
all
the
code
in
your
repository
into
a
graph
database,
and
this
is
a
special
because
it
allows
security
researchers
to
reason
over
that
code
and
develop
queries.
O
This
scans
the
full
history
of
your
repositories,
and
it
provides
users
with
a
native
experience
for
triaging
secrets
that
we
find
in
your
code
as
much
as
this
is
a
security
feature.
It's
also
a
reliability
feature
we're
working
from
with
everyone
from
you
know:
big
clouds
like
aws,
azure
or
google,
through
developer
tools
like
npm,
twilio,
hashicorp
or
blooming.
B
B
P
P
We
just
released
the
state
of
october's
report
last
week.
It
was
a
birthday
present
to
myself
and
everyone
else.
We
took
a
slightly
different
approach
this
year,
so
in
addition
to
sharing
with
the
world
how
github
has
grown
and
changed,
we
also
did
some
deep
dives.
We
had
quite
a
year.
We
have
now
grown
to
over
56
million
total
developers
on
github.
P
P
Many
people
are
both
working
longer
hours
and
getting
more
done,
we
saw
contributions
to
open
source
jump
initially
40
compared
to
last
year
and
then,
when
they
settle
out,
they
settle
out
at
about
25
increase
compared
to
the
previous
year.
We
found
that
once
an
open
source
repo
starts
using
actions
on
their
pull
requests.
P
What
some
of
our
other
analysis
found
is
that
some
of
the
best
ways
to
invite
and
encourage
and
foster
newcomers
to
stick
with
the
community
are
with
issues
the
challenge
with
issues
that
can
burn
out
maintainers.
So
the
exciting
thing
is
that
we
also
found
that
one
of
the
best
ways
to
encourage
newcomers
is
with
discussions.
P
P
P
It's
a
lot
like
inner
source
right.
We
have
so
many
things.
We
have
expertise.
We
have
process,
there's
so
many
things
that
we
could
share.
We
found
that
any
piece
of
code
or
any
repo,
has
a
59
chance
of
getting
a
security
alert
in
the
next
year
of
those
active
repositories
with
supported
package
ecosystems.
P
Most
vulnerabilities
are
mistakes;
only
17
of
them
are
explicitly
malicious
things
like
backdoor
attacks,
and
they
result
in
only
point
two
percent
of
alerts
in
the
in
the
very
commonly
and
most
used
repos
and
most
use
files.
Eighty-Three
83
of
of
these
vulnerabilities
are
the
result
of
mistakes.
So
it's
important
to
remember
anyone.
Anyone
can
make
a
mistake
and
anyone
can
insert
a
mistake
into
your
code
base
so
by
leveraging
the
power
of
community.
P
A
Q
Q
One
was
around
both
the
outer
loop,
how
you
deploy
software,
but
also
our
observability,
both
observability
during
a
deploy
and
then
just
generally
speaking,
another
big
set
of
work
streams
was
around
the
inner
loop
and
testing.
That
is
when
someone
is
coding,
they're,
making
a
build
locally,
they're
running
tests,
all
of
those
kinds
of
things
and
then
the
final
loop
was
final
work
stream
was
specifically
around
reliability.
Q
What
parts
of
the
system
do
we
need
to
make
better
and
stronger
so
that
you
know
the
site
is
always
up
always
serving
our
customers
in
all
cases,
and
so
we
organized
across
those
we
had
objective
leads,
who
kind
of
looked
at
each
one
of
these
three
and
then
underneath
them.
We
created
virtual
teams
of
work
stream,
leads
to
tackle
very
specific
problems.
Ultimately,.
R
We
selected
these
as
some
of
the
work
streams
that
the
projects
that
we
were
gonna
work
on.
First,
we
wanted
to
look
at
how
we
could
speed
up
our
artifact
builds
and
we
need
some
more
progressive,
rollout
stages
and
automation
around
them,
and
we
noticed
that
there
were
recurring
themes
of
deployment
problems
that
we
could
eliminate.
That
could
take
care
of
that
need
for
manual
intervention.
R
First,
we
added
several
reliability
features
and
thankfully
we
were
able
to
maintain.
We
were
able
to
do
this
without
adding
friction
right.
We
were
able
to
maintain
that
critical
cue
to
deploy
time
that
we
watch,
because
we
shave
time
off
elsewhere
and
we've
seen
our
deployment
frequency
bump
up
we're
often
delivering
over
100
pull
requests
a
day
to
github.com.
Now
the
number
of
deployment
rollbacks
we
have
to
do
are
fewer
and
fewer.
It
saves
so
many
hours
of
deployment
interruptions
each
week
this
past
month
alone.
It
was
down
another
15
percent.
R
Last,
let's
see
the
time
to
resolve
incidents
when
they
do
happen
is
vastly
improved,
and
I
want
to
mention
a
thing
that
I
was
super
excited
to
see
happen
here.
We
set
up
a
mirror
of
our
github
repository
so
that
we
can
build
and
deploy
github
still
when
github
isn't
available
the
thing
that
we
do
it
when
it
is
and
another
one
I'm
super
excited
about,
is
that
we're
enabling
merge
queues
for
more
of
our
repositories.
R
So
many
teams
had
opportunities
to
work
together
on
things
that
we
wouldn't
ever
get
a
chance
to
collaborate
on
normally
and
the
results
of
that
have
been
so
positive.
But
really
how
do
we
keep
this
up?
That's
what's
really
important,
so
we
have
now
what
I
like
to
call
anti-slip
measures
in
place
formally
here.
We
call
it
our
fundamentals
program,
but
for
every
improvement
that
we
make,
we
set
new
benchmarks.
We
raise
that
bar.
We
monitor
them
and
tweet
to
understand.
Does
something
need
to
be
nudged
a
bit
right.
R
We
have
that
additional
visibility
to
make
it
a
lot
easier
to
have
these
conversations
with
product
managers
and
engineering
leaders,
and
it
makes
planning
able
to
factor
this
in
better
and
at
least
be
more
aware
of
what
we're
going
to
set
aside.
If
we're
choosing
to
do
other
things
right
and
we're
continuing,
and
we
continue
partnering
and
working
with
other
teams
who
would
really
like
to
contribute-
and
this
is
helping
us
work-
smarter
and
be
more
effective
and
really
get
that
high
performing
thing
without
having
to
work
longer.
S
Hours
we
leveraged
our
products
issues,
actions
workflow
integrations.
We
focused
on
the
key
metrics
to
identify
bottlenecks
and
found
a
maintainable
and
a
reusable
solution.
We
ultimately
built
an
internal
tool
that
supports
our
developers
and,
at
the
same
time,
acts
as
a
guardrail
for
product
qualities
and
as
for
numbers,
we
reduce
our
ci
time
to
13
minutes,
making
our
ci
workflow
three
times
faster.
Then,
as
an
added
bonus,
we
reduced
our
compute
cost
down
by
a
fourth.
S
This
was
improvement
done
just
in
one
of
the
work
streams
in
the
larger
and
in
the
larger
initiative.
There
was
a
lot
more
improvement
as
liz
talked
about,
but
we
focus
on
the
fundamentals
of
development
tracking
down
important
metrics,
deploy
frequency
change,
fail
to
rate
time
to
restore
a
service
and,
of
course,
what
I
fix
lead
time
to
change
above
and
beyond
numbers.
S
Github
engineering
work
together
to
identify
prioritize
plan
swarm
on
the
most
important
impactful
issues
that
matter
to
us.
We
brought
together
teams
from
different
part
of
organization
to
work
on
the
fundamentals
and
what
warms
my
heart,
the
most,
is
how
we
were
able
to
focus
on
our
engineering
platform.
Cracking
down
technical
debt
making
engineering
improvements
so
that
we
could
continue
to
build
the
best
in
class
developer
products
for
you.
T
T
At
intuit
we
have
six
big
groups
across
multiple
continents
and
multiple
time
zones,
engineers
and
other
technologists
focus
on
delivering
solutions
declared
as
priority
by
their
groups.
We
have
aggressive
schedules
to
deliver,
features,
fixes
and
products
to
millions
of
customers
and
speed.
Yes,
it's
a
necessity,
but
man
to
get
there.
There
are
some
challenges
we
solved
it
by
taking
inspiration.
U
From
open
source,
we
implemented
a
solution
that
included
an
inner
source
model.
Inner
source
takes
the
principles
of
open
source
into
the
enterprise
environment
in
resources.
It's
a
great
tool
to
help
break
silos,
encourage
internal
collaboration,
accelerate
new
engineering
onboarding
and
identify
opportunities
to
even
contribute
back
to
open
source.
U
You
will
for
sure
need
leader
support
in
order
to
provide
you
know,
time
for
training
of
their
engineers,
time
for
their
engineers
to
adopt
engineer
guidelines
and
make
the
technology
changes
and,
like
I
mentioned
before,
you
need
to
create
a
set
of
unified
guidelines,
also
identified
your
model
teams.
These
themes
that
are
going
to
be
like
I
mentioned
foundational
capabilities
in
each
of
the
business
units
that
you
have
conduct
workshops
to
teach
how
to
do
in
your
source.
T
T
That
you
teach
what
inner
sources
now
you
heard
about
the
benefits
for
at
a
high
level
for
engineers.
We
also
wanted
to
let
you
know
that
many
engineers
told
us
that
by
allowing
us
allowing
engineers
to
contribute
to
other
repos,
they
were
actually
investing
in
their
craft
and
that
they
were
learning
new
skills
and,
in
addition
to
the
engineers
there
were
other
stakeholders
that
really
do
benefit
the
other
one
is
our
internal
and
external
customers,
and
our
customers
definitely
said
that
wow,
the
the
products.
T
Not
only
are
they
delightful,
but
when
there's
a
problem
you
get
that
fix
out
right
away
now
for
the
business
brazil
did
mention
the
business
earlier
for
the
business
not
only
was
their
speed
and
delivering
solutions
and
and
products
to
customers,
but
there
was
definitely
higher
engagement
from
our
engineers
or
from
product
development
teams,
and
we
believe
that
that
and
we're
starting
to
see.
You
know
some
data
on
this,
but
we
believe
that
higher
engagement
leads
to
higher
higher
retention
of
top
tech.
V
O
O
We
just
started
spending
more
time,
trying
to
understand
the
like
treat
them
as
users
and
understand
their
challenges
start
advocating
on
their
behalf
and
then
trying
to
provide
them
solutions
that
sort
of
meet
their
growing
needs
and
kind
of
meet
them
where
they
are
so.
This
meant
approaching
platforms
and
infrastructure
and
tooling,
with
sort
of
the
same
user-centric
or
product-based
approach
mindset
that
we
do
everything
else
so,
like
our
frontline
associates
and
our
customer-facing
experiences.
O
Sometimes,
if
you
don't
know
where
you
came
from
or
where
you
started
or
where
you
are,
and
so
I
think
you
know
figuring
out
what
to
measure
and
what
to
improve
is
really
important.
So
that's
been
difficult
in
it.
I
mean,
I
think
you
know
almost
forever,
but
I
think
it's
changed
a
lot
in
the
last
few
years
and
and
a
lot
of
that
has
to
do
with
the
work
that
you
know
the
for
nicole
forsgren
and
gene
chem
and
the
others
have
done
over
the
years
with
the
devops
handbook
and
accelerate.
O
So
the
four
key
metrics
that
we
learned
about
an
accelerator
has
been
a
really
liberating
thing
for
me.
In
my
space
I
mean
a
lot
of
the
stuff
that
we
used
to
do
that.
You
know
felt
good
or
felt
like
the
right
thing
to
do.
I
mean,
for
the
first
time,
in
a
long
time
like
it's,
quantifiable,
it's
tangible
and
it's
measurable,
and
that's
really
liberating.
W
Impact,
my
name
is
hung
brownson
and
I'm
the
chief
architect
and
lab
manager
at
r3m's,
corporate
research
and
development
group.
I'd
like
to
share
with
you
our
journey
today
from
scientific
poster
sessions
to
get
our
global
actions,
how
we've
accelerated
our
digital
innovations
by
extending
github
into
model
hub
platform
and
using
booster
as
that
interface
with
github.
We
have
drastically
shortened
the
time
it
took
for
our
modelers
to
onboard
new
models
from
weeks
to
days.
W
We've
also
tripled
the
number
of
models
since
launch
launching
booster
with
github
this
spring.
The
results
have
been
fabulous:
we've
accelerated
our
modeling
platform
usage
and,
more
importantly,
we
accelerated.
Our
research.
Github
has
helped
3m
transform
in
a
number
of
different
ways
by
automating
our
three-person
folklore.