►
Description
Since a few years git became an integrated part of SAPs development landscape. Not only from a source code versioning point of view but also processes and tools start to evolve surrounding git at SAP.
With TwoGo by SAP, SAP offers a free ride sharing service which was the first SAP product to implement daily deliveries using Continuous Delivery and DevOps techniques. And GitHub plays a major role in these processes for TwoGo. Learn which role GitHub takes as a DevOps tool for TwoGo enabling them to delivery daily.
A
B
B
My
name
is
dieg
lehmann.
I
obviously
work
for
sap
and
I
work
for
sap
since
14
years
about
14
years
now.
I
started
in
development
mainly
java,
and
got
into
technical
operations,
and
this
is
what
I
love
to
do
right
now,
I'm
mainly
evangelizing
devops,
that
was
for
the
enterprise,
contingency
continuous
delivery
inside
the
company,
and
beside
that
I
try
to
keep
the
balls
up
in
the
air
for
this
website.
Togo.Com.
B
B
Sap,
I'm
not
sure
whether
you're
all
aware
of
that
it's
one
of
the
companies
that
most
likely
you
never
really
got
in
touch
in
first
place
with,
but
I'm
quite
sure
any
one
of
you
touches
products
that
runs
for
sap
systems
several
times
a
day.
We
are
the
largest
business
software
in
the
world.
We
are
founded
1972..
B
When
we
talk
about
development
at
sap
and
about
these
19000
developers,
you
first
have
to
understand
that
in
the
core
the
sap
system,
the
business
logic,
is
implemented
in
our
own
property
language,
which
is
called
abba.
Abba,
is
short
for
advanced
business
and
application
programming,
and
I
confess
a
look.
It
looks
a
bit
scary
when
you
first
look
at
it
and
if
you
don't
have
any
cobol
knowledge,
because
it's
mainly
influenced
by
that
it's
about
13
years
old
and
it's
extremely
good
and
powerful
in
its
own
universe.
B
In
the
sap
system,
it
lives
there
with
an
own
ide,
not
this
one.
This
is
up
up
in
eclipse,
but
it
hits
its
own
ide
version,
control
system,
lifecycle,
tools,
everything
you
need
to
manage
and
control
the
software.
Now
you
might
ask
why?
Because
we
are
shipping
standard
software,
so
the
business
software
we
are
shipping
most
likely
won't
fit
to
your
company
enterprise.
B
When
you,
when
you
buy
it
out
of
the
box,
you
need
to
adopt
it
and
therefore
we
we
always
ship
the
source
code
which
is
written
in
up
up,
and
you
need
to
modify
that
create
new
stuff
upon
that.
So
you
basically
do
a
lot
of
modifications
into
that,
and
so
the
the
oil
rig
a
hospital
or
your
car
manufacturer,
they're,
basically
running
all
the
same
core
just
with
their
own
adoptions
right.
B
B
B
B
If
you
want
to
try
it
out,
it
says
sap.github.io,
and
so
we
are
a
lot
into
this
agile
thing,
and
this
is
also
where
my
team
comes
into
play
because,
as
I
said,
we're
doing
a
lot
of
on-premise
software
software
that
we
sell
to
customers
that
they
run
on
their
own
side,
but
sap
decided
that
it
wants
to
become
a
cloud
company
and
it
needs
a
lot
of
cloud
knowledge
for
that
and
there
my
team
came
into
play
that
we
said.
Okay,
we
are.
B
So
this
is
my
team.
This
is
what
we
do.
We
are
doing
a
cloud
cloud-based
ride,
sharing
service
for
the
enterprise,
that's
what
the
marketing
people
say.
So
basically,
we
take
care
about
all
the
commuters
that
commute
today
commute
to
work
every
day
in
the
morning
and
go
back
in
the
evening.
This
is
our
main
focus.
B
B
So
if
we
go
out
now
and
tell
our
customers
now,
every
day
you
can
download
a
complete
new
version
of
your
business
suite,
they
would
go
nuts
because
they
have
large
landscapes
own
it
departments
that
run
their
software
just
to
ensure
that
all
things
work
and
they
have
so
many
modifications-
are
done
onto
that
system
that
that
would
be
held
for
them.
So
we
are
used
to
have
deployment
cycles
of
once
a
year,
maybe
twice
a
year,
the
first
ones,
maybe
once
a
quarter.
B
So
if
I
say
we
are
doing
this
daily,
this
is
like
light
speed
for
sap
right,
and
so
what
I
want
to
tell
you
now
is
a
little
bit
how
git
helped
us
in
this
approach
and
yeah.
This
is
we
we
started
as
an
internal
project
and
where
we
had
three
weeks,
the
deployment
cycle,
which
is
also
still
quite
fast
right.
B
If
you
come
from
once
a
year
and
then
we
put
on
continuous
delivery,
a
lot
of
devops
practices,
we
changed
from
traditional
scrum
to
kanban,
like
approach
and
underneath
that
that's
what
I
will
outline
you
is
many
things
from
the
github
enterprise
that
we
use,
and
I
know
you're
all
quite
familiar
with
skit.
I
don't
need
to
explain
that
to
you.
You
can
explain
it
to
me
and
you
know
it
better.
B
On
continuous
delivery,
I'm
not
sure
just
like
the
baseline
about
continuous
delivery
is
that
you
want
to
get
feedback
fast
along
your
development
process.
So
why
do
you
want
faster
feedback,
because
it's
less
waste
because
less
waste
is
less
cost
blah
blah
blah?
You
can
read
that?
What
has
to
stick
in
your
mind
is
faster.
Feedback
is
a
good
thing.
You
want
to
have
fast
feedback
in
order
to
deliver
fast
and
there's
a
term
that
continuous
delivery
created
or
brought
in
just
called
the
deployment
pipeline.
B
This
is
our
deployment
pipeline.
I
know.
Sometimes
it
looks
a
bit
similar.
The
labels
are
different,
but
this
is
how
we
implemented
it.
It's
basically
always
dealing
with
the
same
thing.
Code
changes
start
on
the
left
side
and
you
somehow
try
to
manage
the
code
to
get
fast
to
the
right
side
to
go
productive
right.
B
So
if
you
look
into
this
in
detail,
it
all
starts
off
with
the
developer
that
grabs
a
ticket
or
a
story
or
a
feature
request
or,
however,
you
call
it
in
your
company
and
this
all
these
stuff
for
us
is
stored
in
github,
and
then
he
has
a
ticket.
He
knows
what
he
needs
to
do.
Then
he
fetches
all
the
latest
changes
from
our
central
github
repository
and
he
starts
working
on
the
change
and
then
he
does
a
local
build
with
maven.
B
This
is
where
you'll
find
all
kind
of
ci
servers.
We
have
a
bunch
of
jenkins
servers
here
for
us
that
basically
pull
down
all
the
changes
from
the
central
github
repository.
They
build
it
locally
to
see
how
well
all
the
changes
play
play
together
and
once
the
builds
and
tests
they
fire
a
whole
length
of
tests
on
that.
And
if
all
this
succeeds,
the
commit
gets
a
little
green
check
mark
in
github.
B
B
So
the
main
thing
here
is
that,
besides
we
have
a
different
set
of
tests
there
that
we
use
anonymized
productive
data
here,
because
we
found
out-
and
many
of
you
might
know
that
as
well
test
data
is
cool
test.
Data
is
great
for
testing
fast
and
getting
faster
feedback,
and
remember.
Faster
feedback
is
a
good
thing.
B
We
aim
to
get
that,
but
first
test
data
has
some
has
some
problems,
because
it's
somehow
artificial,
where
production
data
is
created
out
of
real
users,
and
they
sum
how
manage
it
to
sometimes
create
data
that
you
don't
expect
or
don't
expect
in
that
manner.
In
that
way,
that's
one
thing
where
productive
data
is
different.
The
second
thing
is
where
productive
data
is
different
and
it
makes
sense
to
test
against
it
to
test
against.
It
again
is
that
it
comes
in
quite
massively
right.
B
B
If
the,
if
the
developer,
wants
it
on
the
commit
stage,
you
can
also
operate
with
the
same
anonymous
productive
data,
but
usually
test
data
is
okay
there
and
once
this
is
all
set,
the
stuff
moves
over
to
the
productive
stage,
where
the
user
can
actually
do
something
with
the
code,
and
we
monitor
that
with
all
kind
of
solutions
that
we
have
in
place
here
and
what
is
what
most?
What
is
what
what
is
most
worse
to
mention
here
is
that
all
our
server
setup
is
scripted
and
we
use
chef
for
that.
B
So,
basically,
all
our
server
setup
is
scripted
and
versioned
in
github.
So
is
the
complete
server
configuration
in
github
and
all
the
build
jobs,
the
test
jobs,
the
jenkins
setup.
Everything
is
scripted
in
chef
and
in
github,
or,
to
put
it
shortly,
we
do
infrastructure
as
code.
That's
everything
now
enough
of
this
github
counting.
What
I
want
to
outline
with
always
emphasizing
github
is
that
you
see
that
it's
quite
central
for
us
and
it's
along
the
deployment
pipeline.
You
basically
always
touch
github,
and
this
is
by
intention.
B
We
always
want
github
to
be
the
central
hub
for
everything
that
the
that
the
user,
or
that
the
developer
approaches
first,
where
you
can
see
the
status,
so
it's
not
only
as
a
version
control
system,
along
with
accompanying
the
deployment
pipeline,
but
also
in
the
artifacts
repository.
We
use
many
artifacts
repository
like
a
nexus
for
deploying
our
war
files
and
java
files
that
we're
generating,
while
code
passes
through
the
deployment
pipeline,
but
also
jira
and
but
also
the
issue
tickets
from
from
from
github.
B
Now.
One
thing
that
you
might
ask
yourself
is:
how
long
does
it
take
from
left
to
right?
Because
I
said
we
tried
to
get
this
fast,
and
I
also
gave
the
answer
it's
basically
one
day
and
if
you
look
at
this
into
a
branching
model,
this
looks
more
or
less
like
this.
It's
the
def
branch,
which
is
the
top
of
it.
This
is
where
the
developers
work
on
where
they
do
their
commit
on,
and
this
basically
reflects
the
commit
and
the
integration
stage
we
saw
earlier.
B
Then
we
have
the
acceptance
branch,
which
basically
reflects
this
acceptance
stage
that
we
just
saw
so
a
lot
of
qa
stuff
is
going
on
here
and
we
have
the
master
branch,
which
is
representing
the
the
code
which
is
currently
running
productively,
and
then
we
have
also
a
git
tag.
On
the
same
on
the
same
commit
now,
you
might
wonder
why
there
is
a
difference
between
the
acceptance
and
the
master.
There's
this
one
commit
that
is
going
aside
there.
B
So
if
we
do
sub
daily
fixes
for
the
website,
because
something
is
dramatically
broken
and
we
need
to
change
that
asset
and
we
can't
wait
for
the
next
day
happens,
sometimes
so,
but
there's
at
least
always
one
commit
which
is
as
we
are
using
maven
and
maven
has
this
snapshot
idea
and
released
version
idea,
and
this
is
basically
the
the
commit
where
we
remove
the
snapshot
from
the
version
so
where
we
release
where
we
set
the
release
version
of
the
of
this
thing.
So
that's
mainly
the
the
main
reason.
B
We
have
to
make
sure
that
everything
worked
would
work
out.
Fine
then
we
deploy
the
the
stuff
to
the
production
system
and
automatically
also
set
the
master
branch
to
the
same
level
as
the
acceptance
branch.
We
create
the
the
git
tag
with
the
new
version,
and
this
is
more
or
less
done
on
more
or
less
done
completely
automatically
for
us,
so
releasing
the
stuff
and
doing
all
the
changes
in
git
is
just
pressing
one
button.
So
it's
one.
B
B
B
So
what
I
again
wanted
to
try
to
show
you
is
this.
This
idea
that
it's
we
are
using
good,
but
the
main
idea
is
that
we
always
integrate
everything
all
our
tool,
our
processors,
somehow
with
with
github,
not
that
we
completely
put
it
on
github,
but
they
all
have
to
integrate
somehow
with
github,
because
we
want
the
developers
and
every
basically
everyone
in
the
team
to
always
keep
track
of
the
changes.
B
What's
going
on,
what's
coming
next
to
the
productive
system,
to
find
it
in
one
place,
and
this
is
github
for
srd
the
enterprise
github
and
that's
why
we
love
it,
and
so
we
do
technical
documentations.
Also
on
that
and
yeah,
we
basically
use
it
for
a
lot
of
stuff,
also,
for
example,
for
our
kanban
board.
As
I
said
earlier,
I'm
quite
evangelizing,
this
devops
and
devops
for
the
enterprise
on
the
company.
B
B
B
But
what
for
me
there's
one
thing
which
is
basically
missing
about
the
social
coding
thing
of
github,
where
I
think
there
is
a
hidden
pearl
in
it
that
I
see
in
our
team,
where
I
could
say,
there's
a
little
devops
tool
in
in
github,
and
this
is
this:
it's
not
in
the
editor.
It
is
the
editor
because
now
you
might
say
well,
I
I
have
emacs
and
I
use
vim
and
they
are
more
powerful
than
the
editor.
So
why
is
he
so
happy
with
a
simple
editor?
B
Because
you
are
the
developers
and
my
goal
is
to
incorporate
everyone
in
the
team?
So
if
there
is
some
label
misspelled
in
some
language
or
some
glossary
or
some
some
term
wrongly
defined
in
the
past,
our
solution
managers
all
the
non-techie
people.
What
did
they
do
they
they?
Basically
they
went
to
a
developer
and
said:
well,
you
have
to
change
80
files,
because
this
term
we
defined
it
now
different.
B
Can
you
just
change
that
and
then
the
developer
went
nuts,
and
then
you
say
you
can
do
that
by
your
own
and
then
he
went
along
to
the
place
of
the
the
manager
and
showed
him.
This
is
the
decline
you
have
to
install.
This
is
how
stuff
works,
and
this
just
doesn't
work.
Now,
with
this
simple
plain
editor:
what
does
our
solution?
Managers
program
managers?
Translations
guy?
Do
they
go
there?
They
find
the
stuff,
they
click
the
edit
button.
They
change
their
stuff,
they
press
commit,
it
will
be
live
tomorrow.