►
Description
How do you know if you are you making the most of your GitHub Enterprise instance? This talk by CJ Johnson and Lee Faus of GitHub will explore how to leverage key features and tools to establish best practices in an agile environment. We'll look at ways to measure if your team is using GitHub Enterprise effectively and how to socially engineer maximum transparency and collaboration. Focus will be placed on the importance of providing early code reviews using BDD and TDD methodologies. Finally, we will see a ChatOps based Standup tool to keep your team on the same page.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
B
I'm
CJ
Johnson
and
one
of
these
solutions,
engineers
based
right
here
in
HQ,
to
San
Francisco.
Then
we
get
home
about
a
year.
What
would
he
say
pet
names?
My
pets
are
pancakes
and
Larry
Erekat.
What
do
you
get
all
right?
All
right?
Well
without
further
ado,
now,
Lee
I,
don't
know
about
you,
but
I
choose
github,
because
it
makes
me
both
younger
and
better-looking.
B
B
Technical
difficulties,
so
github
com
is
home
to
15
million
users
and
github
Enterprise
is
home
to
thousands
upon
thousands
more.
So
let's
take
a
look
at
why
at
the
heart
of
github
is
the
pull
request?
It's
how
people
contribute
to
your
project?
It's
where
the
conversation
around
code
happens.
It's
the
way
you
can
set
off
automated
tests
and
builds
up
on
the
board.
Here
we
have
the
github
flow
at
the
10,000
foot
level.
What
I
do
is
I,
create
a
branch
off
of
the
main
line
code.
B
My
code
is
merged
into
the
main
line,
otherwise
known
as
the
master
branch,
but
the
thing
is
gap
flow
is
so
much
more
than
what's
on
this
slide
quick
story,
friend
of
mine
who's
sitting
in
the
second
row
up
here,
she's
a
creative
technologist
at
an
ad
agency
and
about
the
time
I
started
at
github
a
year
ago,
is
about
the
time
her
company
moved
from
a
legacy
version
control
system
on
to
github
and
her
life
changed.
One
of
the
things
she
was
worried
about
before
was
looking
foolish
right.
B
Having
people
look
at
what
she
was
doing
before
she
was
ready
to
show
it
now.
What
she
does
is
she
opens
a
branch
and
if
she
has
some
crazy
idea,
she
just
opens
another
branch.
If
it
works
out
great,
if
it
doesn't,
she
deletes
it
and
nobody's
the
wiser
she
doesn't
have
to
worry.
She
doesn't
have
that
self-conscious
concern
anymore,
that's
holding
her
back,
and
that's
just
one
of
millions
of
stories
about
why
github
is
a
success.
B
So
earlier
I
mentioned
there
are
15
million
users
on
github
com
and
when
I
was
thinking
about
standing
up
here
and
conveying
scale
like
the
size
of
15
million,
I
was
trying
to
think
of
a
good
way
to
relate
it
right.
So
here's
my
nerd
cred
one.
If
each
user
on
github
com
worked
on
a
project
and
submitted
one
line
of
code,
it
would
be
equal
to
the
size
of
the
Linux
kernel,
another
one
that
might
resonate
for
some
of
you
is.
B
We
have
built
a
platform
that
supports
more
people
than
the
population
of
Greece
or
Zimbabwe,
the
one
that
works
best.
For
me,
when
I
was
thinking
about
15
million
people.
How
do
I,
how
do
I
convey
the
scale
of
this
is
that
if
each
one
of
those
15
million
users
sent
me
a
one-dollar
bill
CJ
at
github,
if
I
stack
those
dollar
bills
up
on
this
stage,
it
would
be
the
equivalent
of
a
540
story.
Building,
but,
let's
be
honest,
I
wouldn't
stack
them
up.
B
So
the
point
is
this:
with
15
million
users,
we
have
the
opportunity
that
not
a
lot
of
companies
get
github.
Enterprise
is
the
same
code
base
as
github
com
but
package
to
run
behind
your
firewall
on
premises
or
in
the
cloud
and
with
the
lessons
we've
learned
supporting
millions
and
millions
of
users.
It's
on
your
own
platform.
That's
what
you're,
using
earlier
this
year.
Up
on
the
board,
we
announced
our
clustering
solution.
We've
scaled
up,
github
enterprise
services
across
multiple
nodes,
so
you
can
support
thousands
upon
thousands
of
users
on
your
instance.
B
So,
as
your
company
grows,
we
support
you
I
want
to
talk
about
administration
for
a
moment.
So
as
a
solutions
engineer,
I
have
the
opportunity
to
talk
to
customers
every
day
that
are
coming
to
us
from
other
version
control
systems,
and
the
thing
I
hear
most
often
is
that
I've
given
people
their
life
back
incredibly
rewarding
as
a
career
move
right
administration.
So
you
spin
up
an
instance.
It
takes
about
half
an
hour
upgrades,
take
far
far
less
time.
B
B
On
top
of
this,
we
have
an
API
and
web
hooks
that
are
extensive,
very
robust.
So
we
want
you
to
spend
as
little
time
as
possible
getting
together
the
toolchain.
You
want
to
have
your
developers
working
happily
productive,
and
so
you
can
get
out
of
their
way
and
let
them
do
what
they
want
to
do
so
right
now,
I'm
gonna
get
out
of
Lee's
way
as
he
talks
about
making
the
most
of
github
Thank.
A
You
CJ
so
building
on
top
of
what
CJ
said
is
you
sit
there
and
you
think
about
other
applications
that
you
run
inside
of
your
infrastructure
and
when
you're
running
those
other
applications?
Usually
there
are
certain
economies
of
scale
that
you
may
have
around
your
database,
so
we
get
a
lot
of
requests
when
CJ
and
I
first
started
going
out
there
and
talking
to
customers.
The
first
thing
that
I
was
really
shocked
by
is,
but
we
can't
run
a
virtual
appliance.
We
need
to
be
able
to
run
our
own
OS.
A
A
So
as
we
think
about
that
idea
of
using
that
appliance
and
building
better
software,
one
of
the
key
things
that
I
think
a
lot
of
people
miss
when
we
constantly
go
out
and
talk
about
the
pull
request
is
we
think
that
it
is
the
github
way?
Oh
so
I
have
master
I,
create
a
branch
and
then
I
merge
back
in
a
master
and
that's
not
the
only
way
when
we
go
out
and
we
talk
to
customers
is,
there
are
meta
patterns
that
we
can
actually
build
on
top
of
that
particular
workflow.
A
So
when
we
go
out
there
and
we
talked
to
different
customers,
we've
found
that
that
kind
of
boils
down
to
three
different
ways
that
we
can
actually
work
so
and
it's
usually
done
by
the
size
of
the
team.
So
there's
actually
a
pretty
good
workflow
for
when
you're,
actually
working
just
by
yourself
and
most
people
say
yeah
when
I
work
by
myself.
A
Looking
for
some
react,
best
practices
and
they
go
ahead
and
a
stumble
across
your
own
personal
repo
that
you've
written-
and
this
is
somebody
that
just
happens
to
be
a
hiring
manager
for
a
position
that
you
just
applied
for
and
they're
going
in
and
looking
at
you
pushing
the
master
every
time
over
and
over
again
with
really
bad
commit
messages.
It
says
something
about
how
you
think
about
building
software,
one
of
the
things
that
I
actually
learned
from
one
of
our
internal
engineers.
That
just
really
blew
my
mind
was
hey.
A
What
if,
as
an
individual
developer,
I
could
create
my
feature
branch
and
then
off
of
my
feature,
branch
I'll
hook
that
up
to
Heroku
I'll
hook
it
up
the
bluemix
I'll
hook
it
up
to
AWS
code
deploy
and
what
I'll
do
is
on
every
commit.
What
I'll
do
is
I'll
just
go
ahead
and
have
it
go
ahead
and
deploy
my
little
mini
application
as
I'm
learning
and
I
can
go
ahead
and
see
what's
going
on,
then,
when
I
actually
have
something
that's
working,
then
I
can
merge
back
into
master.
Oh
wait.
A
I've
got
all
these
really
small
commits
I'm,
making
all
these
really
small
little
changes.
Well
now,
inside
of
github.com
and
inside
get
a
better
prize,
you
can
actually
squash
all
the
commits,
so
you
can
actually
go
through
and
do
a
whole
bunch
of
really
small
changes
continuously
deploy
all
the
time
and
then
once
you're
ready
to
go
ahead
and
actually
show
that
and
a
lot
of
people
say
yeah
that
what
that
works
on
that
works
great
for
me
as
an
individual
and
github
com.
What
does
that
mean?
For
me?
A
Inside
of
an
enterprise,
well,
how
many
times
have
those
of
us
as
a
developer,
been
asked
by
a
manager
or
by
an
executive
and
say
hey?
Can
you
build
me
just
a
really
simple
proof
of
concept?
Well,
do
I
want
to
do
that?
An
organization
do
I
want
somebody
else.
Do
you
know
who
else
am
I,
collaborating
with
all
those
things
go
into
actually
measuring
the
value
that
we
have.
So
when
we
actually
look
at
github
enterprise.
A
So
there's
different
ways
of
actually
having
different
users,
so
right
here,
I'm
in
chrome,
actually
here
I'm
in
firefox,
so
the
way
we'll
be
able
to
distinguish
the
difference
is
this
is
my
alter
ego
on
the
top
right
hand
corner
this
is
Chewbacca
and
then
what
we
have
is
we've
got
another
browser
window,
and
this
is
my
chrome,
and
here
is
my
alter
ego
up
in
the
top
right-hand
corner,
which
is
Luke.
Now
we
talked
about
this
meta
pattern
around
being
able
to
use
the
github
flow.
A
So
what
I
want
to
do
is
I
kind
of
want
to
walk
you
through
what
this
might
look
like.
We
talked
about
the
individual
user.
What
would
this
look
like
to
a
small
to
medium
sized
team
when
we
say
that
we
usually
mean
somewhere
in
between
10,
to
25
people
inside
of
a
team
and,
let's
say
we're
doing
lean
or
agile
development?
A
So
when
we
actually
go
down
that
path,
one
of
the
things
that
a
lot
of
people
get
stuck
in
is
I've
got
my
project
management
to
over
here
and
I've
got
github
over
here
and
when
we
actually
go
ahead
and
do
that
we
actually
have
two
measurement
points
and
I.
Don't
know
about
you,
but
I'm.
A
horrible
developer.
I
I
will
admit
that
on
stage
I'm
a
bad
developer,
I
was
the
person
at
the
end
of
the
sprint
that
the
project
manager
came
over
to
at
lunch.
A
Letting
me
know
that
I
haven't
updated
my
tickets
for
two
weeks.
That
was
me
so
when
we
would
actually
look
at
our
burn
down,
charts
are
burned
down
charged
for
me,
we're
always
no
work,
no
work,
no
work,
no
work.
Friday
afternoon.
I
did
300
hours
of
work
and
I
did
all
that
in
a
15
minute
span
of
time.
A
Well,
what
I'm
going
to
do
is
I'm
just
going
to
add
a
branch
called
sprint,
ten,
so
most
of
us
when
we're
doing
sprints,
we
do
a
sprint
kick
off.
So
when
you're
doing
the
sprint
kick
off,
you
can
think
of
this
as
a
milestone.
Well,
now
that
I've
got
master
and
I've
got
my
sprint.
Ten
now
off
of
spring
10,
I
can
actually
start
doing
all
of
my
feature
work
so
now
what
I
can
do
is
I've
got
sprint
ten
selected
here.
A
So
if
I
create
another
branch
inside
of
github
enterprise
and
as
I
get
up
com,
it
will
actually
go
ahead
and
mark
this
to
basically
be
sprint,
ten
being
my
tracking.
So
what
I'm
going
to
do
is
I'm
going
to
create,
let's
hear
I'm
in
Luke,
so
I'm
gonna,
say
Luke
I'm
going
to
say,
add
some
text
now.
This
is
something
else
that
we've
actually
just
started
doing
with
some
of
our
some
of
our
engineers.
A
When
we
talk
about
best
practices
internally
is
this
is
something
that
a
lot
of
people
don't
normally
do
as
your
team's
get
bigger.
You
can
see
that
what
I've
done
is
I've
actually
taken.
My
github
ID
I've
made
it
the
name
and
then
I've
done
a
forward,
slash
and
then
I've
added
another
set
of
texts
that
whole
text
just
gives
me
a
different
reference,
but
anybody
else
who
comes
in
and
they
click
on
that
drop
down.
A
They
can
start
typing
in
they
just
start
typing
in
Oh
Luke,
and
what
would
happen
is
they
would
see
all
of
the
branches
associated
with
Luke
I
could
show
you
some
of
our
repositories
that
we
have
internally
and
one
of
the
things
that
a
lot
of
companies
don't
do.
A
great
job
of
is
cleaning
up
branches
that
are
no
longer
in
use.
So
this
way
you
could
go
back
in
and
you
could
actually
type
in
names
or
you
could
have
some
other
naming
convention
that
you
actually
want.
A
A
And
as
CJ
had
mentioned,
is
we
have
this
notion
of
creating
our
pull
requests
so
down
at
the
bottom?
I'm
going
to
go
ahead
and
say
I'm
going
to
add
it
to
my
branch
I'm
going
to
commit
those
changes
and
when
I
go
ahead
and
I
go
back
in
it's
going
to
tell
me
hey,
let
me
go
ahead
and
let
me
compare
this
pull
request
now.
This
is
where
you've
got
to
know
a
little
bit
about
how
github
works.
A
So
if
I
go
ahead-
and
I
want
to
create
my
pull
request
off
of
here-
it's
actually
going
to
by
default
always
think
that
I'm
comparing
back
up
to
master
but
that's
a
drop-down
box.
This
is
one
of
the
things
that
when
I
go
out
there
and
I
see
our
phenomenal
services
team
go
out
and
do
trainings
most
people
completely
gloss
over
that
box.
Up
at
the
top
remember
we
want
this
work
associated
with
our
sprint
that
we're
currently
working
on.
A
And
one
of
those
I'm
going
to
create
the
pull
request
now
this
is
a
workflow
that
most
people
are
very
familiar
with.
If
I
go
ahead
and
I
click
the
merge
button
right
now,
what's
going
to
do
it's
going
to
merge
this
into
my
sprint
ten
and
then
I
can
go
ahead
and
I
can
merge
sprint
ten
through
a
pull
request
back
into
my
master.
Well,
why
would
that
potentially
be
important?
Well
about
six
months
ago,
we
added
a
new
feature
into
github
that
allows
us
to
be
able
to
go
into
chrome.
A
So
what
I
want
to
do
is
I
want
to
restrict
who
can
push
to
this
for
a
lot
of
companies?
We
actually
have
a
need
that
the
person
who
approves
anything
is
at
some
sort
of
audit
or
compliance
level.
So
now
what
I
can
do
is
to
this
pull
request
process.
If
I
go
ahead
and
say
the
only
person
here
that
can
actually
do
this
as
Chewbacca.
A
A
When
we
talk
about
sox
compliance
and
we
talked
about
two-phase
deliveries,
what
you
can
do
is
I
could
actually
now
have
my
Sprint's
actually
be
protected
by
my
scrum
master
or
by
my
team
lead,
that's
a
person
who
can
merge
back
into
the
sprint,
and
then
the
person
who
actually
merges
from
the
sprint
back
into
master
would
be
a
release
manager,
so
you
can
actually
follow
and
start
creating
your
own
processes
you're
not
limited
to
just
working
off
of
master
and
going
to
one
branch.
So
this
is
something
that
hopefully
most
of
you
know
about.
A
The
other
pieces
is
when
we
start
getting
to
some
advanced,
get
flows.
So
now
what
happens
is:
is
those
of
us
at
set
up
our
milestones
inside
of
our
Sprint's,
to
be
every
two
weeks?
How
many
of
you
know
about
the
term
a
lame
duck
developer?
All
right,
so
what
happens
is?
Is
you
go
ahead
and
in
the
second
week
of
your
sprint
you
got
a
two-week
sprint.
It's
Wednesday
and
everything.
That's
left
in
the
backlog
is
sitting
there
and
has
a
story.
Point
of
5
or
higher
I
can't
do
that
in
two
days.
A
So
what
does
the
developer?
Do?
I
can't
do
anything.
I
got
to
sit
there.
I
gotta,
wait.
Gotta,
wait
for
the
next
sprint,
so
I'm
just
going
to
sit
here
and
I'm
going
to
check
my
fantasy-football
scores,
I'm
going
to
go
out
and
do
some
research
on
the
web,
but
what
you
can
do
with
github
is
I
can
actually
go
back
and
now
I'm
going
to
do
this
as
Chewbacca.
A
A
And
now,
when
I
commit
these
changes,
I
now
have
to
feature
branches
off
of
two
different
Sprint's
talking
to
the
same
master.
So
now
you
think
oh
my
gosh,
so
now
I
got
to
go
into
my
command
line.
I've
got
to
go
back,
I've
got
to
do
a
emerged
up.
I've
got
to
go
ahead,
then
I've
got
to
go
back.
I
got
to
do
a
rebase.
I
got
all
that
magic.
I've
got
to
remember
what
all
those
commands
are.
A
A
And
I'm
going
to
merge
this
pull
request,
which
is
going
to
take
me
into
sprint
ten,
and
then
what
happens
is
if
I
go
back
into
the
code.
It's
going
to
tell
me
that
sprint,
ten
actually
has
a
PR
and
also
the
last
one
that
I
just
did
I
have
a
pull
request
as
well.
Let
me
do
this
one
first
just
so,
we
can
get
this
one
out
of
the
way.
A
So
you
can
imagine
here
if
you
were
actually
going
through,
you
could
actually
go
ahead
and
actually
take
the
data
from
here.
You
could
actually
put
and
actually
start
creating
release
notes.
You
can
actually
put
something
in
here
at
the
end
of
the
sprint.
What
are
the
things
that
you
actually
accomplished.
A
A
Okay,
there
was
some
text
in
here
so
now,
how
do
I
get
these
changes
back
into
the
other
branch?
So
what
I'm
going
to
do
is
I'm
going
to
go
back
into
my
pull
requests,
I'm
going
to
create
a
new
pull
request
and
remember
that
drop-down
that
we
talked
about
right
now
is
telling
me
there's
no
changes.
I
can
actually
do
this
in
the
reverse
order.
A
A
You
guys
would
this
is
like
bed
commit
messages
you
guys
would
want
to
go
through
and
actually
fill
these
out.
So
now,
when
I
merge
this,
that
lame
duck
developer,
who
was
now
moved
over
and
starting
to
work
off
of
sprint
11
on
wednesday,
before
the
sprint
was
over,
can
actually
be
working
off
of
another
branch
and
now
my
changes
from
sprint.
Ten
are
now
merged
into
sprint,
11.
So
now
I
can
merge
in
and
make
sure
that
I've
got
clean
history
all
the
way
through
so
other
things
that
we
can
look
at
around
this.
A
B
B
So
success
means
a
lot
of
different
things
right
so
for
some
of
you
success
might
mean
I'm,
onboarding
people
faster
they're,
contributing
to
my
code
base
on
day
three
and
it
used
to
be
bay.
7.
Maybe
success
is
you
are
pushing
features
out
faster
than
you
were
last
year
or
last
month
or
the
last
sprint.
B
Maybe
success
means
that
you're
creating
fewer
bugs
or
that
you're
finding
bugs
and
fixing
them
faster,
or
maybe
it
warms
my
heart,
maybe
you're,
measuring
developer
happiness
and
maybe
you're
measuring
how
developer
happiness
affects
what
you're
pushing
so
metrics
are
not
the
target.
We
know
this
so
who's
ever
been
in
the
room
in
some
meeting
and
somebody
goes.
Oh,
we've
really
got
to
start
measuring
developer
productivity
and
inevitably
a
hand
is
raised,
and
somebody
goes.
B
Well,
without
reiterating
the
goals,
your
team
can
lose
sight
of
what
the
goals
are,
and
they
just
focus
on
the
metrics
right
so
define
the
goals,
and
then
we
use
the
metrics
to
figure
out
how
we're
doing
how's
our
progress.
So
in
github
Enterprise
we
ship
with
charts
and
graphs
about
things
like
commits
code
frequency
contributors.
Also
on
the
appliance
itself.
We
have
an
audit
log
which
tracks
all
user
activities,
including
pools,
pushes
Forks
clones
as
well
as
repository
and
system
information.
B
But
in
addition
to
this
perhaps
most
powerfully,
we
have
an
API
and
web
hooks
which
allow
you
to
check
out
all
sorts
of
things
right.
So
maybe
you're
checking
out
how
many
pull
requests
were
open
in
the
last
sprint
and
of
those
pull
requests.
How
many
were
merged
versus
closed,
maybe
you're,
tracking,
the
number
of
branches
in
a
sprint
or
the
number
of
issues,
or
maybe
the
times
the
label
bug
appeared
on
those
issues
that
was
open
during
that
span.
B
Maybe
I
like
this
one,
a
lot,
maybe
you're
tracking
the
number
of
comments
on
a
pull
request
to
determine
how
collaborative
your
team
is
when
they're
shipping
code
and
whether
or
not
that
affects
your
bottom
line,
so
something
I
encourage
everyone
to
do
is
to
track
and
publicize
now
internally,
but
publicize.
Your
numbers
share
your
metrics
with
your
team.
You
can
do
this
on
github,
wiki's,
github
pages,
the
same
way
that
you
can
enter
source
code
to
let
it
be
available
across
your
company.
B
B
We've
all
known
the
horror
stories
right
I'm
over
here,
making
fifty
line
methods
it's
a
disaster.
There's
it's
really
easy
to
get
into
this
pattern,
where
you're
reinforcing
terrible
behavior
amongst
your
developers
so
think
about
it.
The
only
thing
you're
measuring
is
speed
or
volume
who's
going
to
be
motivated
to
step
up
right
who's,
going
to
step
up
and
take
on
that
terrible
legacy
code
rewrite
or
who's
going
to
solve
that
really
complex
problem.
If
it
means
their
score
is
going
to
be
lower
at
the
end
of
the
day.
A
So
the
only
reason
that
we
bring
up
chat
ups
at
this
particular
point
in
time
is
because,
as
as
CJ
said
in
our
large
enterprise
customers,
developers
are
usually
the
largest
group
of
people,
but
they're,
not
the
only
people,
and
when
we
measure
value
out
of
github.
Some
of
you
have
seen
from
the
keynote
that
what
happens
is
as
soon
as
you
install
one
integration
into
a
repo.
Maybe
that's
Jenkins
travis
CI,
pivotal
tracker
JIRA.
You
have
one
thing
that
now
allows
people
to
be
able
to
see
things
through
a
single
pane
of
glass.
A
That
means
one
less
tool
that
they
have
to
jump
to.
It
makes
github
more
valuable
to
those
folks
inside
of
that
particular
group.
As
you
start
to
add
more
and
more
integrations
on
top
of
that,
first
one,
you
start
to
get
what
we
call
developer
stickiness.
One
of
the
things
that
we
see
is
the
old
trend
inside
of
svn
is
I
would
go
ahead
and
commit
one
time
at
the
end
of
a
day,
because
that
meant
a
round-trip
action
back
to
the
server
and
I
didn't
necessarily
want
to
share
all
of
my
code.
A
I
wanted
to
test
a
whole
bunch
of
things
locally
and
I
wanted
to
make
sure
that
what
I
committed
was
golden
I
didn't
want
it
to
break
anything
else.
Where
get
is
the
exact
opposite
of
that?
So
we
need
to
break
the
trends
of
trying
to
do
one
push
per
day.
So
you
go
in,
you,
see
one
push
and
what
happens
is
there's
36
commits
and
they're
all,
so
you
go
and
look
at
a
pull
request.
A
Somebody
needs
to
do
a
code
review
and
there's
now
all
of
a
sudden
six
thousand
lines
of
code
that
you
need
to
review.
So,
as
we
add
more
and
more
integrations
it's
about
being
able
to
find
the
places
that
we
can
aggregate
this
data.
One
of
the
things
that
CJ
said
that
was
really
important
is
an
individual
metric,
doesn't
necessarily
mean
it's
good
or
bad.
It's
not
binary!
It's
about
inside
of
your
organization,
how
you
correlate
a
metrics
and
it's
not
just
get
up
it's.
A
How
do
I
correlate
all
of
the
other
systems
that
we're
integrating
with
so,
if
you're,
integrating
with
a
CD
pipeline
and
you're,
trying
to
figure
out
just
by
being
able
to
say
that
we
deployed
five
times
in
a
week?
Well
great?
What
did
you
do
with
those
five
deployments
in
that
week?
Did
anybody
go
out
there
and
did
you
automate
your
selenium
tests
and
be
able
to
do
a
full
regression
of
the
website?
Did
you
do
pixel-perfect
evaluations
to
make
sure
that
nothing
shifted
on
the
page?
A
Did
you
also
test
the
mobile
aspects
of
that
particular
website
when
you
deployed
what
are
the
things
that
you
did
with
that
deployment
and
how
does
that
keep
building
time
and
time
again
beyond
just
the
initial
push
or
beyond
the
initial
deployment?
When
we
see
people
elevating
when
we
talk
about
DevOps,
we
said
that
we
talked
about
the
culture
of
transparency,
that
culture
that
we
create
through
a
DevOps
environment
is
allowing
us
to
be
able
to
not
just
automate
the
development
workflow
but
I'm
automating.
A
My
cue,
a
workflow
I'm
automating,
my
operations,
workflow
and
then
I
get
to
a
particular
point
that
I
can
actually
measure
it.
That
is
what
every
VP
of
engineering
every
CTO
every
CIO,
every
vp
of
operations
that
we
ever
go
in
and
talk
to
is,
if
I'm
going
to
spend
money
on
this,
it's
taking
money
away
from
that.
A
A
They
were
talking
about
all
of
this
data
that
they
get
out
of
github,
and
could
I
give
them
an
example
of
what
that
might
look
like,
so
the
easiest
one
that
I
showed
them
was
being
able
to
use
Hugh
bot
as
a
listener,
and
so
here,
inside
of
my
chat,
you
saw
all
the
work
that
was
going
on
well,
I'm,
a
project
manager
as
a
project
manager
I'm
not
going
to
be
sitting
inside
github
just
sitting
there
waiting
sir
commit
commit.
Can
I
wait
for
commit
the
same
thing
for
a
release?
A
Engineer
I,
don't
want
to
be
sitting
there.
I
don't
want
to
be
waiting
for
something
to
be
able
to
say
that
I'm
ready
to
be
able
to
be
merged
when
you
actually
have
this
plugged
in
whether
it
be
HipChat
or
slack
or
rocket
chat.
No
matter
what
those
check
clients
look
like
I'm,
giving
you
an
example
here,
but
you
can
also
customize
these
through
scripts
to
also
do
at
mentions.
A
So
we
could
actually
add
mention
somebody
inside
of
the
chat
so
that
way,
when
they're
sitting
in
their
room
that
they're
normally
sitting
in
to
talk
to
their
colleagues.
What
happens
is
in
another
room?
They
automatically
get
a
notification
that
also
starts
bouncing.
It
starts
flashing
in
the
corner
to
let
them
know
that
something
has
taken
place
and
it
doesn't
always
have
to
be
github.
It
could
be
that
a
build
was
broken.
It
could
be
that
a
deployment
failed.
It
could
be
a
number
of
other
things
that
triggers
an
activity
that
before
was
a
ticket.
A
It
was
a
ticket
that
went
into
service.
Now
it
was
a
ticket
that
went
into
JIRA
was
the
ticket
that
went
in
a
pivotal
tracker.
Well,
I
have
no
idea
that
that
ticket
was
created.
Then
all
sudden
somebody
comes
back
three
days
later
and
goes
hey.
Have
you
taken
a
look
at
that
ticket?
Well,
no
I
was
doing
commits.
I
was
in
my
tool.
A
You
created
that
in
your
tool,
so
being
able
to
create
a
single
location
where
you
can
actually
have
an
honest
conversation
about
what's
going
on
inside
your
organization,
so
the
example
that
I
gave
to
the
people.
This
is
an
inbound
request,
but
things
that
you
can
do
with
the
API
is
when
we
were
talking
about
all
of
the
different
ways
of
collecting
data
inside
of
github
is
if
I
go
in
and
look
at
the
issues.
We
have
this
notion
of
labels.
A
How
many
of
you
are
actively
using
labels
today,
here's
a
tougher
question:
how
many
of
you
have
an
ontology
and
a
taxonomy
for
all
of
your
labels?
Awesome
those
people
actually
can
use
that
data
to
be
able
to
go
back
in
and
actually
query
against
it
to
be
able
to
go
back
as
CJ
was
saying.
How
good
are
we
doing?
How
are
we
collaborating?
What
is
my
developer
happiness?
How
many
issues
are
we
closing?
Did
we
close
an
issue
that
was
labeled
properly?
Those
are
the
kinds
of
things
that
we're
actually
looking
for.
A
So
one
of
my
favorite
examples
is
we
become
a
global
development
society.
How
many
people
here
have
tried
to
schedule
a
stand
up
with
teams
all
around
the
world
somebody's
getting
up
early
so
when
you
have
to
go
ahead
and
do
that
a
lot
of
people
have
moved
to
asynchronous
communication
for
their
stand-ups.
So
what
do
we
tell
people
to
do?
Hey
look?
Can
you
go
into
that
slack
channel,
and
can
you
just
go
ahead
and
put
your
stand-up
in
there
before
you
close
out
your
day?
A
Tell
me
everything
you
did
so
when
you
go
ahead
and
you
do
that
what
happens
is
is
now
I'm
taking
time
again
away
from
committing
code
and
I'm
going
back
and
I'm
trying
to
review
the
work
that
I've
already
done.
Maybe
a
retrospective
is
good,
but
at
the
same
time
you
could
actually
write
a
really
simple
humic
command.
That
basically
goes
back
out.
A
So
here,
based
on
all
of
my
issues
here,
I
could
go
ahead
and
Hugh
bot
stand
up
me.
Basically
I'm
Chewbacca,
going
back
in
looking
at
all
of
my
issues
that
are
assigned
to
me
all
of
my
issues
that
were
closed
yesterday.
All
of
the
work
that
I'm
currently
assigned
to
that
I
have
made
the
label
in
progress
today.
Everything
that
I'm
assigned
to
that
is
actually
in
the
future,
for
as
a
to
do
or
in
the
backlog
or
whatever
label
you
want
to
use,
is
actually
going
ahead
and
being
put
on
deck.
A
Guess
what
as
a
developer,
if
I
could
come
in
every
morning
and
I
did
that
that's
actually
more
important
to
me
actually
doing
the
stand-up,
because
most
likely
somebody
else
has
already
organized
some
work
for
me
and
if
I'm
talking
about
global
development,
what
happens
is
those
types
of
things?
Some
things
happen
within
the
12
hours
between
when
I
went
to
bed
and
I
got
up
in
the
morning
that
somebody
else
has
already
done
a
whole
bunch
of
other
work.
Somebody
else
could
have
come
in
where
I
had
issues
that
are
on
deck.
A
Somebody
else
may
not
have
had
something
on
deck
and
they
automatically
went
ahead
and
did
one
of
my
tasks.
Well,
great
I
can
go
ahead
and
I
can
take
on
another
task.
So
when
we
talk
about
the
measuring
of
the
value
we
like
to
talk
about
the
github
platform,
not
just
talking
about
get
and
talking
about
the
workflows
that
existing
get.
A
So
when
we
talk
about
DevOps,
the
final
piece
that
I
talk
about
is
I
talk
about,
measuring
everything
so
being
able
to
ask
yourself
honest
what
should
I
be
measuring
I
can't
tell
you
that
I,
don't
know
what
your
company's
goals
are.
Is
your
company's
goals
to
be
able
to
move
faster?
Is
it
developer
happiness?
Is
it
going
ahead
and
finally,
defining
a
compliant
strategy
that
you've
been
saying
you
are
going
to
do
for
the
last
10
years,
depending
what
those
goals
look
like.
A
Those
are
things
that
we
can
help
you
with,
but
we
need
to
know
what
the
requirements
are.
There
is
not
just
a
blanket
statement
about
what
you
should
measure.
The
other
thing
is
what
correlation
should
I
make?
What
other
tools
are
important
for
me
to
be
able
to
measure
when
you're
choosing
an
integration?
Don't
always
choose
an
integration?
That's
free
that
doesn't
give
you
a
good
set
of
api's,
because
then
you
can't
cross
correlate
those
items
together
and
then
other
things.
How
do
I
measure
my
sdlc?
A
How
do
I
go
from
beginning
to
end
so
as
we
go
ahead
and
we
finish
up
I
just
want
everybody
to
think
about
what
some
of
these
things
might
be
inside
your
organization
and
I'd
like
to
thank
CJ
for
the
awesome
job
and
from
there
we'll
open
it
up
to
any
questions.
We've
got
about
a
minute
and
a
half.
So
if
anybody's
got
a
quick
question,
we.