►
Description
Hosted by:
Kai Hilton-Jones, Solution Engineer, GitHub
Featuring:
Cyril Lakech, AXA France
Thomas Jansen, SAP
Lothar Schulz, Zalando
Alex Lindley, HSBC
Hear from technologists from SAP, Axa, HSBC and Zalando about how their software development and delivery architectures are designed with considerations for the user, the IT infrastructure and the business goals. Find out how their solutions meet all of their technical and operational requirements, while optimising common quality attributes such as performance, security, and manageability.
At Satellite 2017, attendees came to exchange cutting edge practices on how to bring together the people and tools you need to build great software. Watch the recordings to find out what GitHub's been working on, and hear how other teams use the GitHub ecosystem to customize the way they work.
We'll be getting together again in San Francisco on October 10th-12th for GitHub Universe. We hope you'll join us for three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
Hello,
everyone
welcome
to
the
customer
panel
at
satellite,
so
my
name
is
Kyle's
and
Jones
and
I
head
up
the
solutions:
engineering
team
for
github
in
Europe,
which
means
that
you
know
I
have
the
privilege
of
working
with
enterprise-grade
companies
across
Europe.
You
know
in
a
technical
space,
so
we've
worked
with
companies
such
as
the
ones
represented
here.
You
know
over
the
last
sort
of
a
couple
to
three
years
and
it's
always
been
a
pleasure
to
do
so.
So
without
further
ado.
A
I
am
delighted
to
present
the
the
panelists
here
today,
so
they've
all
been
key
to
the
modernization
initiatives
at
their
respective
companies,
and
so
they
have
a
huge
amount
of
insight
to
to
tell
us
about
today.
So
I'm
really
excited
about
you
being
here.
So
thank
you
very,
very
much
so
from
right
to
left.
We
have
Thomas
Hanson
from
sa
P.
We
have
sue
deal
Lokesh
from
AXA
in
France.
We
have
lotus
roots
from
Zalando
in
germany
and
we
have
Eric
and
Milan
from
exact
software
in
the
Netherlands.
A
B
So
my
name
is
Thomas
I'm
working
for
sa
P
R,
which
is
I,
guess,
apparently
the
largest
business
software
development
organization
in
the
world
arm,
and
there
I'm
heading
the
well
developer
experience.
We
call
it
initiative
so
taking
care
of
our
internal
developers
that
they
have
best-in-class,
tooling
and
also
trying
to
modernize
that
towards
cloud
development.
Ok,.
D
A
A
In
some
of
the
details,
I
asked
a
lot
of
people
about
what
it
means.
I
got
a
whole
bunch
of
different
answers,
so
you
know
it
means
different
things
to
different
people,
so
maybe,
as
the
first
question
I
am
I
can
ask
each
of
you
in
turn.
You
know
what
springs
to
mind
when
you
think
about
modernizing
software
architecture.
You
know
what
is
the
desired
outcome
of
that
modernization
as
well
within
your
organization.
So
maybe
it
starts
sorry
with
it
with
Eric
right.
E
Yeah,
so,
if
I
think
about
architecture,
it's
it's
the
full
process
of
going
from
your
business
requirements
to
actually
working
software,
but
it's
it's
much
more
than
of
just
the
technical
components.
It's
about
how
everything,
also
in
organization
and
from
a
technical
perspective,
works
together
to
achieve
that
goal
and
I.
Think
what
now
in
this
area
where
modernization
is
really
important,
they
have
that
speed
there,
that
you
can
quickly
try
something
else
for
your
customers
and
I
have
validation
on
that.
So
the
speeds
to
get
your
idea
into
production
is
really
important
which
needs
yeah.
A
E
D
Like
to
underline
that
feedback
cycles,
so
this
is
really
important.
We
have
quick
feedback
cycles
for
all
the
customers.
You
can
envision
like
for
most
of
us
that
most
likely
developers
who
want
to
test
the
code
and
also
want
to
deploy
their
code,
but
also
end
customers
right.
So
if,
if
there
are
requests
or
if
you
can
somehow
improve
your
product,
you
should
be
able
to
do
that
as
soon
as
possible.
I
would
like
to
add
one
more
notion
which
is
about
the
requirements
you
mentioned.
D
C
C
We
have
a
lot
of
interp
ability
between
our
very
different
companies
on
software,
so
we
have
to
change
the
way
we
design
the
software
to
be
able
to
connect
on
to
evolve
the
real
quickly
on
we
have
to
to
open
the
software
or
other
other
teams
on
other
companies
to
be
able
to
to
contribute
to
your
platform
in
order
to
add
some
features
and
to
integrate
their
own
software
into
yours.
So
it's
a
it's
a
quite
new
way
to
to
design
the
software.
A
C
Have
to
be
supported
by
the
sea
stars
level
of
the
company,
because
this
evolution
starts
a
long
time
ago.
But
if
we
do
it
only
at
the
developer
level,
it's
quite
hard
to
to
travel
real
huge
impacts
all
over
all
over
the
company.
But
when
you
CIO
or
CEO,
is
telling
you
that
you
have
to
collaborate
on
to
share
with
all
different
entities.
It's
it's
quite
easy,
and
then
you
have
to
set
up
different
tool
set
to
be
able
to
to
go
from
from
this
mindset
to
the
to
the
real
project.
C
So
we
we
set
up
few
different
tools
and
that
we
integrate
into
the
information
system
to
be
able
to
collaborate
on
together,
and
then
we
have
to
to
leverage
the
knowledge
of
the
IT
knowledge
of
every
everyone
in
the
company
and
the
we
we
just
learn
from
from
each
other
on
which
share.
We
share
a
lot
more
than
before,
by
organizing
some
developer,
submit,
for
instance,
on
some
conferences
like
here
to
share
unto
to
be
able
to
collaborate.
Healthier.
Thank.
B
F
B
A
So
you
know
be
more
worried
for
and
be
more
collaborative,
but
at
the
same
time
comply
with
the
regulations
and
they
and
the
legal
requirements
for
the
company
as
well.
Okay,
great
so,
and
to
put
this
sort
of
a
little
bit
more
into
context,
context
for
the
audience
you
know,
can
you
give
the
audience
a
feel
of
how
your
teams
actually
work?
You
know,
could
you
describe
sort
of
a
typical
application
lifecycle
within
your
team
within
your
company
and
how
that's
changed
over
time?
C
The
life
cycle
of
applications
changed
a
lot
now
we
have
some
short
latin
shot
iteration
between
between
each
prediction
milestone,
but
we
change
the
way
we
collaborate
on
the
code.
Now
every
line
of
code
I
have
to
the
review
in
a
code
review
not
not
not
necessary
in
their
review,
but
we
using
we
are
using
a
lot.
Tour
request
are
in
more
and
more
teams
across
the
company.
The
pull
request
is
not
battery.
C
You
can't
had
code
to
the
software
on
production
without
a
bit
having
at
least
one
people,
maybe
four
people
in
different
independent,
the
teams.
Each
team
decides
of
the
steps
to
be
able
to
to
add
some
code
in
production,
and
this
is
one
one
thing:
that's
changed
a
lot
another
one
is
that
now
we
want
to
reuse
a
lot
of
code
and
a
lot
of
hath-set
between
teams.
We
don't
want
that
every
team's
we
have
the
will
between
each
project.
C
So
we
have
some
common
hazards
in
tellers,
for
most
of
all,
most
of
them,
then
can
be
easily
shared
across
the
company
and
we
have
the
same
quality
gate
for
all
these
artists
code
and
we
had
a
lot
a
lot
of
more
automation
in
the
way
we
process
code,
and
so
we
are
moving
to
the
develops
more
and
more.
We
could
speak
about
that
sort,
but
whenever
I
think
so
we
let
the
other
one
to
to
also
to
the
question
too.
D
So,
as
of
now,
our
application
lifecycle
is
like
always
divided
into
four
four
parts.
Part
one
is
planning
part
two
is
developing,
but
three
is
mostly
deploying
and
past
four
very
important,
often
forgotten
retirement.
So
most
likely
no
software
runs
forever.
Where
do
we
come
from
more
or
less
from
a
monolith?
D
We
are
quite
sunburned
and
working
with
it
and
we
go
for
years
now,
but
it's
still
an
ongoing
effort
for
a
micro
service
approach.
So
those
steps
apply
now
to
micro
services
and
yeah
with
those
micro
services
you
you
have
to
make
sure
that
they
can
talk
to
each
other,
somehow
most
likely
in
most
of
the
cases
via
ET
item
for
this
API.
You
need
to
make
sure
that,
and
there
are
certain
rules
in
place
and
as
Lorie
and
talked
about
this
morning
about
this
open
source
geared.
F
E
So
what
you
see
in
a
typical
flow
is
and
development
happens,
and
then
there
is
a
formal
code
review
moment
it
takes
until
the
last
at
the
next
day.
Until
you
get
some
feedback,
then
a
Quality
Engineer
will
have
Luke
test
it
and
then
it's
merged
by
somebody
else
which
can
oversee
all
the
processes
that
are
part
of
the
malla
list
and
well
finally,
it's
merged
and
then
well,
something
can
be
do
it
can
be
deployed,
but
there
is
still
and
a
big
regression
test
in
the
end.
E
Yeah
and
it
can
feel
for
all
kinds
of
reasons
based
on
the
development
work
that
has
been
done
by
all
the
different
teams.
So
that's
the
classic
model.
That's
not
giving
us
the
speed
we
want.
So
if
you
look
at
the
modernized
model,
indeed,
as
my
neighbor
we're
also
looking
into
micro
services
and
splitting
up
the
big
part
that
we
have
in
smaller
solutions
and
they
were
adopting
github
we've
been
running
a
pilot
with
that
for
one
year
now
and
there
you
see
that
is
in
the
pull
request.
E
You
try
to
tackle
all
the
collaboration
aspects
already
so
another
form
of
cultural
few
moments
that
make
it
part
of
the
pull
requests,
as
integrations
running
there
to
have
feedback
on
that
as
quickly
as
possible,
without
going
through
all
these
different
stages.
But
having
that
integrated
to
go
quicker
to
to
prediction,
that's.
A
It
thank
you
so
we're
about
half
way
through
so
modernization
means
change
and
change
is
never
easy.
As
we
all
know-
and
you
know
you,
you
need
to
have
a
slide
sort
of
cultural
shift
to
be
able
to
support
that
modernization
whatever
modernization.
That
is.
How
do
you
handle
that
you
know?
How
do
you
handle
the
cultural
aspect,
the
people
aspects
Thomas?
A
B
A
very
good
question
I
mean
usually-
and
this
applies
also
on
how
we
introduced
github,
for
example,
at
our
company.
It
was
basically
a
bottom-up
approach.
Yeah,
so
usually
we
tried
systems
out.
We
have
a
few
teams
using
it,
and
then
we
get
the
feedback.
You
know
we
see
what
works
well,
what
doesn't
work
well
and
then
we
grow
from
there.
F
B
I
think
the
usual
approach,
then
those
team
we
can,
you
know,
have
that
reference
tailor
to
other
teams
and
if
they
like
it,
they
can
adopt.
It
I
think
you
know,
being
such
a
large
company,
they're,
always
options
on
how
to
do
certain
things.
At
least
you
know
on
a
day
to
day
basis
for
development
workflows
and
then,
from
a
cultural
point
of
view,
it's
a
classical
change
management
process.
B
A
We
start
with
a
small
team,
and
then
you
prove
success
to
that
team,
and
then
you
roll
it
out
to
two
over
there
yeah.
Okay,
another
question,
maybe
for
you
Thomas
quickly
before
I
move
on
is,
is
how
do
you
measure
that
success
within
that
team?
How
do
you
know
if
that's
change
that
modernization
has
been
successful.
B
By
a
couple
of
things,
of
course,
we
talked
to
them,
but
we
also
have
structured
approaches
for
our
internal
tooling.
We
do
surveys,
you
know
like
standard
measurements,
on
how
well
people
you
know
like
it.
How
was
the
end
user
experience
how
well
they
can
perform
certain
tasks,
monitor
that
on
a
continuously
basis
from
our
department
and
then
treat
you
know
see
where
we
can
improve
so.
A
C
Measure,
if
things
are
going
well
or
not,
we
measure
the
incident
of
the
satisfaction
of
the
customer,
though
it's
a
quite
easy
way
to
to
know
if
we
are
doing
better
or
not
I'm,
sorry
for
the
change
of
the
culture.
I
agree
with
the
small
stuff,
with
a
small
thing
on
them.
They
were
spread
too
horrible,
the
world
and
I.
C
Think
when
you
choose
a
tool
there
is
a
mindset
behind
the
tool,
so
I
think
that
that's
why
we
chose
github
as
a
code
source
software,
because
when
you
choose
get
up
everything,
if
its
first
github
Enterprise
Edition,
this
mean
you,
you
want
to
be
more
hope
and
everyone
will
just
check
what
is
github
in
the
company
I'm
saying:
oh,
we
chose
the
company.
That
is
a
the
one
of
the
leader
in
the
hope
and
sauce
area.
So
this
change
a
lot
the
way
people
think
then
on
the
again.
C
If
we
want
that
the
people
change
our
mind
on
the
agree
that
we
have
to
share
to
share
more
on
to
be
more
open,
we
have
to
organize
a
lot
of
havens
of
you
have
tool
you
have
to
learn.
You
have
you,
you
have
to
to
do
to
work
all
to
alter
all
together,
it's
quite
hard
from
from
from
from
from
the
security
point
of
view.
C
F
E
Employee
engagement
is
one
of
our
strategic
pillars
of
the
of
the
strategy
we
have.
So
it's
really
important
that
something
like
this.
This
changes
also
Ravin
up
from
the
bottom,
and
what
we
did
with
introducing
github
is
that
we
indeed
started
small
with
a
couple
of
teams,
and
then
we
actually
relied
on
surveys
asking
the
teams
how
they
felt
about
it,
but
there
how
they
perceive
the
change.
E
For
instance,
we
asked
questions
like
how
would
you
rate
our
company
as
a
whole,
if
you
would
adopt
well
this
too,
or
what,
if
we
stay
with
our
existing
two
and
they
have
two
great,
maybe
so,
for
instance,
that's
really
a
night
and
day
difference
so
to
shore
engineers.
It
can
really
make
a
big
impact
on
on
their
daily
work
and
yeah.
E
A
Rate
journey,
okay
right
so
move
on
to
to
security.
I
know
we
sort
of
touched
upon
security
earlier,
but
you
know
security
is
obviously
important
for
all
of
you,
but
also
an
open
and
collaborative
environment
for
the
developers,
and
so
how
does
that
play
with
each
other?
How
do
you
ensure
that
the
application
is
still
secure
while
still
fostering
an
environment
of
collaboration
within
your
organization?
Booter.
D
First
of
all,
I
believe
you
should
reconsider
if
your
security
guidelines
rules,
measurements
whatever
is
in
players-
are
really
needed.
So
maybe
this
is
there
just
for
legacy
reasons
and
it
was
just
there
and
that's
why
we
need
it.
Maybe
this
is
not
always
true
anymore,
but
I'm,
pretty
sure
in
large
organizations
you
have
to.
D
You
have
to
have
a
certain
security
and
rules
and
regulations
in
place
and
we'll
try
to
incorporate
them
into
the
development
work
into
the
developers
workflow
and
it's
frictionless
as
seamless
as
possible
possible,
and
we
are
on
our
way,
so
we
we
there're
still
a
lot
of
stuff
to
do
for
us,
but-
and
the
key
here
is
I,
think,
automation
and
tooling
right.
So
whenever
you
identify
a
certain
area,
when
you
need
to
introduce
route
regulation
processes,
we
always
try
to
support
it
with
tools,
our
frameworks
and,
ideally
the
customer.
D
A
D
And
ideally
even
you
know,
often
those
are
configuration
files
or
similar
things,
and
the
developer
does
not
really
experience
that
right.
It's
like
files,
starting
with
a
dot
and
some
file
systems.
You
don't
see
them,
you
don't
have
to
touch
them,
they
were
just
there.
It
just
works.
Okay,
that's
what
we
are
striving
for.
C
E
Too,
we
combine
those
two
with
also
looking
into
the
integration
so
for
automation,
for
in
CGS
tools
like
sonar
cube,
which
can
integrate
and
give
you
also
security
warnings.
We
are
using,
for
instance,
better
code
hub
for
measuring
code
quality
and
also
that
makes
sure
that
you're
not
yeah.
Let
you
stay
in
a
position
that
you
do
not
overlook
these
things
absolutely
yeah,
but.
A
B
Well:
okay,
all
right
cool,
maybe
one
thing
to
add
us
in
securities
and
very
interesting
topic,
especially
on
cloud
services.
We
are
trying
out
some
tools
right
now
who
do
like
the
next
thing:
okay,
who
actually
create
pull
requests
whenever
they
find
something
you
know
so
conceptually.
You
just
merge
it
in
the
patch
files.
Those.
D
B
Of
workflows
are
enabled
you
know
by
the
ecosystem
and
I
think
those
are
the
exciting
integrations.
Just
you
know
the
scanning
part
and
so
on
and
so
forth.
We're
doing
that
for
years,
but
really
getting
you
know
from
a
bot
like
a
pet
request
for
security
issue
it.
It
is
for
me,
that's
kind
of
a
newer
thing:
okay,.
A
Okay,
so
five
minutes
ago
so
see
this
is
a
github
conference,
your
github
customers,
you
know
I,
know
I'm
interested
in
how
you
use
github
at
at
your
company,
I'm
sure
the
audience
is
as
well.
Maybe
you
can
describe.
You
know
how
how
you
use
github,
what
impact
that
has
had
within
your
organization,
luta.
D
First
and
foremost
for
us,
it's
the
go-to
place
for
source
code
for
every
developer
at
Fernando
and
because
you
have
to
have
your
source
code
edit,
our
internal
github,
in
order
to
deploy-
and
there
are
only
a
few
cases
when
you
don't
want
to
deploy
on
top
of
that,
it
becomes
more
and
more
the
place
to
document
your
processes,
your
software,
whatever
and
in
the
past
years,
I
often
went
to
wiki's
or
other
collaboration
software
to
find
some
documentation.
Nowadays,
it's
almost
always
links
to
get
up
pages
and
also
in
in
our
internal
checks.
D
We
see
that
that
more
and
more
of
those
links
and
the
thing
about
how
whole
github
is
more
and
more
used
is
visualizations,
like
the
pull
request,
the
deployment
status
as
CI
status,
visualizations
and
serums,
those
and
machine-learning
graphs
or
stuff,
like
that.
Those
are
the
three
main
areas
like
AC
in
our
organization.
Right.
A
E
That's
a
big
impact
bit
get
out
of
it
so
easily
to
to.
If
you
have
some
code,
look
in
the
history,
fine
back
the
pull
request
it
introduced
it
and
what
you
see
is
when
people
work
in
the
pull
request,
they
also
describe
their
what
they
are
actually
building,
sometimes
putting
designs
in
it,
and
that
information
is
really
helpful
later
on
to
look
at
how
did
people
build
a
system
and
with
github
you
can
find
all
that
documentation
like
in
the
open
source
rocks
thanks.
A
C
Unpacked
that
github
as
on
the
enterprise
is
it
answers
to
to
share
some
some
codes
and
some
assets
across
the
group.
We
have
about
30
and
different
entities.
All
over
the
world
on
the
each
entities
are
their
own
assets
to
do
some
very
simple
stuff
on
now.
We
can
share
it
using
github
and
we'll
we
don't.
We
don't
share
only
code
which
we
can
share,
for
instance,
the
developer
guideline
for
also
all
the
group
when
we
are
pushing
some
new
methods
on
new
process
in
the
in
the
code
like
CIT
D
on
some
software
craftsmanship.
C
Anything
we
we
contribute
to
the
to
the
developer
guideline
on
the
different
people
from
from
different
entities
can
give
their
in
other
insights
into
into
this
the
guideline,
and
then
we
we
can
finish
a
new
version
of
the
guidelines
and
we
should
follow
these
guidelines
in
different
entities.
Okay,.
A
So
you
are
all
sort
of
technical
leaders
in
your
fields.
You
know
what
sort
of
exciting
new
technology
sort
of
has
attracted
your
attention.
What
are
you
excited
about
it
at
the
moment?
You
know,
that's
something
that
you
want
to
have
a
play
with
something
you
think
might
you
know
have
benefits
of
the
future
of
you
know
the
tooling
you
use
and
the
software
development
there.
Is
there
anything
that
you're
it's
coming
in
front
of
mind
for
you,
Thomas.
F
B
D
Serverless
architecture
and
cluster
management
and
you're
really
passionate
about.
We
do
a
lot
of
stuff
in
the
cloud.
However,
if
you,
if
you
have
a
lot
of
instances,
you
have
to
manage
them
somehow
and
there
is
cluster
management
solution
or
there
are
cluster
management
solutions
of
the
solutions
out
there.
We
I
think
we
should
use
and
they're
done
really
interesting
and
even
one
step
further.
D
Maybe
you
don't
need
instances
or
notes
anymore,
because
you
just
have
servers,
I,
see
tectors
and
you
just
have
your
lambdas
and
they
just
do
what
you
want
and
I
mention
it
already
machine
learning
to
automate
things
to
to
foresee
what
what
developers
customers
want.
It's
also
really
interesting
I
believe.
A
Perfect
so
I
think
sort
of
we're
running
out
of
time.
Now,
unfortunately,
I
could
talk
to
you
all
day.
Maybe
you'll
be
floating
around
here
for
the
next
few
hours.
In
case
you
know,
people
want
to
talk
to
you
in
more
detail,
but
it's
been
very,
very
interesting
about
learning
about
your
role
and
about
sort
of
the
technologies
you
use.
So
thank
you
very
much,
I.
Think
a
big
round
of
applause
for
the
panelists.