►
From YouTube: Commit San Francisco 2020: Axway's Journey To The Cloud
Description
As change agents for data integration, keeping pace and adapting quickly to today’s fast and fluid digital customer compelled Axway’s globally distributed R&D team to move their DevOps to the cloud. In this talk by Axway's VP of Cloud Operations, Eric Labourdette, and Vince Stammegna, senior director of engineering, SaaS | DevOps | Cloud, see how they leveraged Gitlab and other value stream tooling to drive their digital transformation from an on-premise Internet Service Provider to a Cloud Provider.
Follow their Continuous Integration to Continuous Security and Delivery journey to learn how they:
* Achieve 26x faster release cycles and 100% developer adoption
* Enable collaboration for multiple teams across continents and timezones
* Simplified their source code repository administration
* Implemented world-class integrations and flexible API-enabled, seamless workflows
Slide deck: https://drive.google.com/file/d/1Xey3tUYhgQDOvHra4Qv507Y_tHJx7rd5/view?usp=sharing
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Thanks,
so
welcome
to
this
presentation
today
we're
going
to
talk
about
XY
transformation
to
the
cloud.
So
this
is
not
a
technical
presentation.
We
just
go
through
the
change
transformation.
We
did
from
an
organization
standpoint
from
the
DevOps
and
the
cloud
moving
to
the
cloud.
So
I
would
start
with
this
eye.
Level.
Presentation
and
Vince
will
continue
with
going
into
more
details
from
a
DevOps
standpoint.
A
So
anyone
ever
heard
about
xwy
raise
your
hand
a
few
people
from
gitlab,
I
guess
yeah,
so
you
know
I,
don't
know
we're
known,
but
it's
a
quite
interesting
company.
Historically,
we
are
a
software
on
premise
of
a
vendor
and
we
are
specialized
in
integration
patterns
such
as
new
b2b
message,
file,
transfer
or
an
API
gateway,
and,
interestingly
enough,
we're
here
to
provide
your
the
tools
for
transformation
of
our
customer
so
and
we
need
our
own
transformation
you're
starting
in
2015,
and
we
don't
talk
about
that.
A
So
what
we
do
what's
a
product
do
is
about
to
give
you
an
example.
When
you
connect
to
your
smartphone
and
try
to
get
your
bank
account
information,
we
get
all
the
the
API
gateway
to
securely
connect
to
your
information
or
you.
If
you
do
a
wire
transfer
from
one
account
to
another,
I
will
get
this
kind
of
new
application
in
the
backend
that
does
this
transaction
and
make
it
secure.
A
So
our
transformation
started
in
2015
and
we
onboarding
your
new
leadership
and
the
matters,
an
assessment
of
where
we
standard.
So
what
we
realize
we
are
working
in
silo.
We
had
a
development
organization,
a
QA
organization,
a
product
management
organization
and
tech
rider,
or
you
name
it.
We
had
separate
new
organization
and
the
I
think
that
you
know
creates
a
lot
of
new
lack
of
collaboration,
a
lot
of
frustration
and
each
organization
has
new
or
different
objectives,
different
priorities
and
going
different
direction.
A
So
this
related
to
a
lack
of
trust,
a
lot
of
collaboration
and
and
the
status
quo
in
everything
we
are
doing
and
you
obviously
we
are
not
doing
any
kind
of
continuous
improvements
and
we
are
going
nowhere.
So,
in
addition
to
that,
you
know,
we've
been
going
through
a
lot
of
acquisition
or
along
the
euro,
and
we
had
a
lot
of
product
and
we
were
investing
the
same
amount
of
money
on
every
single
product
regardless
if
it
was
out
of
life
product
or
if
it
was
a
new,
innovative,
new
strategic
product
for
us.
A
So
we
had
to
change
that
and
again
it
was
due
to
a
lot
of
acquisition
over
time
and
the
fact
that
we
had
this
mission
equation
and
lack
of
collaboration
is
organization.
So
the
first
thing
that
you
really
knew
kicked
everything
up
was
your
support
and
sponsorship
from
executive
team.
You
know
if
you
don't
have
that
it's
kind
of
difficult
to
make
a
change
in
any
organization.
I
think
it
was
critical
for
us
to
kick
that
off.
A
So
the
first
automation
we
did
was
around
tooling.
So
tuning
is
not
a
driver
to
transformation,
but
it's
really
an
an
answer
of
what
you
want
to
do
and
it's
really
to
your
success
and
you
really
have
to
define
what
you
want
to
do
with
your
tooling.
What
we
realized
before
is
everybody
has
different
tools.
There
was
no
collaboration,
it
was
difficult
to
maintain
and
so
on.
A
A
Another
reason
why
we
selected
it
lab
was,
as
it
provided
the
on-premise
solution.
We
were
working
with
a
government
and
at
that
time
we
couldn't
have
our
source
code
on
the
cloud,
so
we
install
your
grid
lab
on
premise
and
you.
Finally,
in
order
to
have
a
good
adoptions,
you,
the
selection
process
and
requirement,
came
from
our
developers.
A
So
you
know,
organization,
structure,
alec
square
was
very
article
and
you,
your
organization,
charts,
represent
the
culture
of
your
entreprise
and
we
have
to
change
that.
So
the
expectation
for
the
major
was
no
longer
to
review,
validate
and
decide
for
everything,
but
we
about
empowering
the
team
and,
as
I'm,
to
understand
what
they
are
doing,
questioning
what
we
are
doing
and
so
on.
A
So
your
first
observation
about
in
your
job
was
around
product
management
and
the
team
we
used
to
have
to
product
manager
for
one
product
owner
and
went
pro
tuner
for
forty
two
engineers
and
that
didn't
work
too
well,
because
we
didn't
have
any
enough
product
owner.
You
know
resources
to
really
drive
the
team,
so
we
change
that
and
we
put
in
one
pro
manager
appeal
for
fifteen
engineers
to
improve
the
ami
and
reactivity
of
the
team.
A
Another
interesting
move
we've
done
is
we
remove
the
product
manager
and
the
product
owner
for
the
product
out
of
life,
because
what
we
realize
is,
if
you
set
up
a
product
manager
on
a
product
you
gonna
have
is
gonna
drive.
You
know
the
backlog
is:
gonna
drive,
the
need
of
resources
and
the
cost
of
this
product,
so
taking
away
a
product
manager
from
out
of
life
product
ever
start
to
refocus
on
the
strategic
product
and
just
set
up
a
sustaining
team
was
out
of
life
product.
A
It
was
owned
by
the
development
team,
but
more
about
providing
guidance,
providing
expertise,
providing
security
gates
to
make
sure
that
every
product
coming
out
of
R&D
was
secure
and
validated,
and
so
on.
So
we
did,
you
know
we
changed
completely
the
way
it
was
set
up
and
it
worked
very
well
and
finally,
we
did
new
technology
transformation.
We
had
some
pre
old
product
monolithic,
we
get
some
probably
family
online
of
code
and
we
quickly
realized
that
we
could
not.
You
rewrite
everything,
but
we
said
you
know
new
guidelines.
A
Everything
had
to
be
DevOps,
everything
has
to
be
micro-services
and
every
singer
to
be
cloud
ready
and
clad.
First
on
all
the
new
development,
meaning
that
devops,
we
introduce
your
gitlab
jenkins
test
unit
test
your
functional
tests.
Everything
was
automated
micro,
these
services
for
new
development.
So
we
have
more
flexibility
and
cloud
first,
so
everything
had
to
be
on.
The
cloud
was
supposed
to
be
easy
to
upgrade
easy
to
deploy
and
so
on.
So
we
change
the
mindset
of
what
we
are
developing.
A
And
but
at
the
end
of
the
day,
you
can
change
your
everything
in
organization,
the
process,
architecture,
the
structure,
but
what's
most
difficult
to
change,
and
what
what
takes
over
is
a
cultural
and
a
cultural
change
is
the
most
challenging
to
do
and
I
took
couple
of
years
to
get
where
we
are,
and
in
2015
we
were
on
your
on-premise
software.
Like
I
shown
you
initially,
you
know
in
each
one
of
2019,
we
have
a
17%
growth
on
the
cloud
and
more
than
half
of
our
revenue
is
now
on
the
cloud.
A
So
it
took
some
time
it
took
me
five
years
to
get
where
we
are
and
we
still
in
you're
working
on
it.
But
culture
is
key
part
of
this
transformation,
and
winds
are
going
to
talk
in
a
bit
more
in
details
about
how
we
made
this
change
from
the
culture
change
standpoint.
Sorry,
and
from
a
DevOps
transform
awesome.
B
Thanks
so
much
Eric
and
thanks
gate
lab
I,
really
appreciate
the
cool
swag.
This
really
saved
me
today,
because
I
brought
a
t-shirt
to
talk
into,
and
this
is
fantastic
I've
been
nice
and
toasty.
So
one
button
here,
we
came
up
with
this
question.
How
do
you
change
culture
when
we
looked
at
how
we
delivered
software
and
when
you're
coming
from
an
ISV,
that's
used
to
traditional
software
delivery
from
on-premise
product?
That's
quarterly
deliveries,
sometimes
semiannual
deliveries.
You
want
to
go
to
cloud
native
and
SAS,
where
you're
delivering
every
day.
B
That
requires
a
complete
mind,
shift
change
in
a
culture
change
at
your
company,
and
this
was
the
question
that
we
came
up
with.
How
do
you
change
culture
show
hands?
Has
anybody
read
the
Lean
Enterprise
by
humble
molesky
or
O'reilly?
Okay,
couple?
Okay,
so
you
guys
are
in
on
you
guys
are
in
on
the
secret.
B
So
in
the
next
few,
slides
I'm
going
to
show
you
how
we
automate
for
continuous
delivery
and
really
have
an
eye
on
continuous
deployment.
We're
lean
and
in
being
lean,
we
continue
to
drive
a
culture
of
learning
which
helps
us
become
more
lean.
How
we
measure
DevOps
at
a
sway
and,
most
importantly,
how
we
share.
B
B
Over
the
last
five
years,
they've
gathered
a
lot
of
data
and
they've
put
together
great
metrics
around
software
delivery
and
operational
performance,
and
so
the
things
that
we
looked
started
looking
at
at
the
beginning
of
2019
were
lead
time
to
change
deployment,
frequency
change,
failure
rate
mean
time
to
restore
and
availability,
and
these
cross
all
three
quadrants
of
really
your
value
chain.
When
you
go
to
build
a
SAS
product
software
development,
software
deployment
and
operations.
B
We
had
the
opportunity
to
build
our
first
SAS
product
in-house,
not
through
acquisition,
so
we
really
had
a
retool,
our
thinking
and
our
behaviors
in
order
to
change
our
culture
where
we
started
in
2018
was
probably
around
a
medium
performer
between
once
per
week
and
once
per
month
we
did
start
developing
cloud
native
services.
They
allowed
us
to
develop
a
little
bit
faster,
but
we
were
still
really
limited
by
the
end
of
the
Sprint.
B
We
were
probably
higher
than
15%.
We
just
didn't
have
a
good
grasp
of
how
things
worked
in
a
distributed
world.
Our
first
foray
into
distributed
system
and
SAS
was
on
docker
swarm,
so
a
lot
of
intervention
and
a
lot
of
heavy
lifting
by
our
teams
focusing
on
infrastructure
and
how
that
worked
and
not
really
focused
on
the
product.
B
But
we
set
the
goal
of
being
an
elite
organization
for
2019
by
the
end
of
2019.
We
made
it
too
high
and
we
we
touched
in
some
of
the
elite
categories,
but
we
only
assessed
as
high
because
that's
where
we
could
perform
consistently,
and
so
we
were
consistently
deploying
between
once
at
once
per
hour
and
once
per
day,
most
of
time,
two
to
three
times
a
day
between
one
day
and
one
week
was
a
lead
time
for
change.
B
That's
what
it
still
is
today,
our
time
to
restore
service
within
two
hours,
so
that
that
was
fantastic
in
our
change.
Fury
rate
is
definitely
it's
less
than
15%.
So
by
the
end
of
2019
we
did
a
fantastic
job.
It's
it's
really
really
hard
to
make
that
type
of
a
movement
in
one
year
going
to
elite
yeah.
We
want
to
set
those
wild
goals
and
that's
great,
because
the
team
can
look
back
and
reflect
and
see
what
we
did
and
how
we
can
get
better.
B
So
where
do
we
want
to
be
for
2020
we're
still
aiming
there
and
I'm
gonna
go
over
some
of
the
behaviors
and
our
lessons
learned
about
how
we're
gonna
get
there.
Just
to
recap,
if
you
want
to
be
an
elite
part
of
the
elite
performing
team
you're
deploying
on
demand
in
the
background
multiple
times
per
day,
your
lead
time
for
changes
is
probably
a
hardest.
B
B
Like
this
slide,
it
kind
of
shows
the
stages
of
evolution
as
to
what
are
some
of
the
outcomes
and
then
what
are
some
of
the
behaviors.
So
if
you
look
at
stage
two,
that's
probably
where
we
were
in
2018,
we
were
just
getting
started.
Lifting
and
shifting
in
the
cloud
we
had
complicated
roll
backs,
not
a
lot
of
service
ownership
amongst
the
teams,
somehow
just
lots
of
manual
steps,
2019,
much
less
outages,
fewer
manual
steps
and
hours
to
deploy
we're
on
track
about
10
to
20
deployments
per
month
to
become
an
elite
performer.
B
What
we
wanted
to
do
was
automate
and
empower
our
development
teams
and
trust
them
with
making
the
changes
that
would
affect
production
all
in
one
shot
by
providing
tools
that
automate
for
scale
right.
So
these
tools
that
we
build,
they
need
to
be
self
service.
They
need
to
have
the
capability
and
the
resources
so
that
development
teams
can
take
these
tools
and
do
their
work
without
somebody
setting
them
up
and
helping
them
out,
and
you
know
basically
a
lot
of
care
and
feed
along
the
way.
B
If
you
want
your
development
teams
to
run,
you
know
the
sonar
scans,
the
internal
quality
checks,
external
quality
tests,
all
the
automated
test
frameworks,
static
and
dynamic
security
scans.
It
needs
to
work
like
any
good
product
and
service
period
and
one
of
the
game-changing
things
that
we
did
from
a
DevOps
team
perspective
was
we
started,
treating
our
tools
like
products
for
our
development
team
and
we
hired
a
product
owner
and
that
product
owner
was
a
game
changer.
B
Why
we
really
started
treating
our
tools
like
products?
We
started
eating
our
own
dog
food.
Don't
get
me
wrong.
We
leverage
a
lot
of
third-party
tools.
I'll
show
you
this
on
the
next
slide,
but
really
it's
a
synthesis
of
these
tools
and
in
your
value
stream,
and
that
is
the
product
itself
that
synthesis
that's
responsible
for
reliably
delivering
your
product
in
a
SAS
environment.
B
The
other
real
great
benefit
of
having
a
product
owner
on
a
DevOps
team
is
the
ability
to
bridge
across
other
teams
with
their
product
owners
or
tpms,
and
understand
what
changes
need
to
be
made.
Getting
the
feedback
from
the
Elmen
teams,
operations,
team
and
security
really
heading
that
up
and
rolling
that
into
the
tools
allowing
us
to
communicate
better.
B
This
is
an
eye
chart,
but
it's
kind
of
like
a
10,000
foot
view
of
our
CI
and
CD
workflow,
and
it's
there
to
show
you
all.
The
different
tools
that
we
go
through
on
the
left
is
CI
on.
The
right
is
CD,
just
some
high-level
points
here.
You
know
we
want
our
goals
with
CI,
where
common
local
development,
environments
and
pipelines
they
could
use
common
CI,
pass
a
common
image
registry
and
a
dashboard
with
basically
build
and
vulnerability
reports.
So
the
teams
can
get
feedback
on
whether
the
code
had
security
violations
or
quality
issues.
B
On
the
CD
side,
some
of
our
objectives
were
basically
immutable
infrastructure
and
automated
deployment
tools
for
those
common
CD
paths.
So
if
a
development
team
member
wants
to
build
and
deploy
micro
service
and
use
the
CD
path
to
go
from
QA
into
prod,
they
get
a
common
pipeline
that
allows
them
to
do
that.
We
use
Jenkins
to
do
a
lot
of
these
things.
Like
I
said,
if
you
notice
here
a
lot
of
tool
sprawl.
One
of
the
things
that
we
learned
here
in
2019
is
that
traceability
was
difficult.
B
It's
difficult
when
you
have
to
go
across
all
these
different
tools,
especially
when
you're
going
from
Jenkins
back
in
to
get
lab.
There's
a
lot
of
link,
diving
and
so
the
feedback
we
got
from
the
development
teams.
Was
you
know,
the
visibility
with
CD
is
good
because
you
could
see
the
end
n
type
line
flow
and
see
where
things
break
in
CD.
But
if
you
want
the
entire
visibility
of
your
value
chain
from
CI
through
CD,
it's
difficult.
B
It's
hard
to
track
changes
back
in
from
Jenkinson
to
in
to
get
lab
lots
of
link
diving
in
as
I
had
mentioned,
and
so
they
weren't
getting
the
feedback
fast
enough
right.
They
were
getting
some
visibility,
but
they
had
to
work
for
that
feedback,
and
that
was
great
feedback
that
we
learned.
We
learned
at
about
15
micro-services.
The
complexity
became
a
little
bit
much
for
Jenkins
to
handle
we
kept
having
to
add
inputs
and
to
the
jobs,
and
when
teams
would
go
in
and
try
to
use
it,
it
got
hard
to
use.
B
This
is
one
of
my
favorite
slides
about
keeping
calms
and
lean.
This
is
in
Rio
2016,
so
we're
coming
up
in
Tokyo
2020.
Does
anybody
know
what
happened
here?
They
dropped
it
exactly.
This
is
a
dropped
hand
off
how
many
people
here
have
had
a
drop
hand
off
from
dev
to
ops
or
death
to
security
or
security
to
ops,
I
mean
that's
pretty
much.
Why
DevOps
exists
right?
B
B
B
Same
type
of
thing
that
we
have
to
do
is
as
part
of
our
journey
to
the
cloud
as
Eric
mentioned
earlier.
We
have
all
a
lot
of
the
cross
functional
aspects
of
the
team,
so
we
are
more
aware,
as
a
team
and
more
empowered
as
a
team
to
own
services
all
the
way
into
production,
it's
just
not
one
whole
team
of
developers.
We
have
quality
points
of
contact,
DevOps
of
contact
security,
point
to
contact.
B
Shirring,
probably
one
of
the
most
important
behaviors
if
you
want
to
go
to
a
pure
sass
organization,
and
you
want
to
operate
as
one
team
sharing
is
critical
and
the
only
way
that
we
found
that
sharing,
really
works
at
a
high
operating
level
is
by
providing
visibility
and
providing
transparency
through
dashboards
and
visibility
in
your
tools,
so
I
talked
about
the
door
report
earlier.
This
is
how
we
implemented
that
this
is
a
service
level
view.
We've
also
implemented
organizational
level
view
we'd
like
to
open
source
it,
because
we
think
it's
really
useful.
B
We
have
the
api's
build
for
get
lab.
If
we're
interested,
you
know
we
can
talk
afterwards,
but
basically
measures
our
deployment
frequency
and
you
can
adjust
the
time
scale.
This
is
on
a
per
month
basis.
So
for
this
micro
service
we
have
about
25
micro
services
and
our
one
product,
19
deployments,
lead
time
to
change,
is
about
a
day
and
a
half
our
mean
time
to
recovery
is
12
minutes
change.
Failure
rate
is,
is
5%
and
our
availability
is
within
our
SLO.
B
So
this
allows
our
teams
to
have
the
transparency
as
to
how
other
teams
are
doing
with
regard
to
some
of
these
metrics
and
help
each
other
out
right.
If
I
expect
a
feature
to
come
from
a
team
that
has
an
SLO,
that's
breached
their
SLO
for
the
service.
They're,
probably
gonna
have
to
work
on
their
stability
for
a
while
before
that
feature
is
gonna
come
out,
so
it
also
gives
you
the
visibility
as
to
what
they're
gonna
be
working
on
I
have
in
there
blame
no
blame,
we
implement
a
blameless
culture.
This
is
critical.
B
This
is
basically
one
of
the
most
impactful
things
when
things
go
wrong,
that
you
operate
as
one
team
and
no
finger-pointing
really
seeking
to
learn
what
happened
and
I
know.
We
talked
about
root,
cause
analysis,
a
lot
of
times
there
just
isn't
a
root
cause,
there's
so
many
different
things
that
happen
in
that
context
of
that
change,
that
there's
lots
of
causes
and
there's
no
finger-pointing.
The
goal
is
really
to
learn
and
understand
how
we
can
improve
our
technical
systems,
our
processes
or
even
our
organization,
and
on
how
to
repair
those
those
those
items.
B
Basically,
you
don't
want
to
have
broken
handoffs,
that's
where
outages
occur
so
for
2020,
based
on
what
we
learned
in
2019
here
are
some
of
the
technical
and
behavioral
changes
that
we're
gonna
be
making
in
our
CIN
CD,
and
this
is
from
the
10,000
foot
view.
First
thing:
we're
gonna
do
based
on
developer
feedback
is
move
all
of
our
CI
pipelines
from
Jenkins
into
gate
lab,
and
the
reason
why
we're
doing
this
is
we
touched
upon
it
earlier.
Is
we
want
better
visibility
and
faster
feedback
loops
for
developers
and
application
code?
B
We
don't
want
Jenkins
link,
diving
developers
are
super
happy
about
that.
We're
gonna
be
moving
from
a
CI
ops
model
to
a
git
ops
model
and
the
reason
why
we're
doing
that
is.
We
want
to
have
both
infrastructure
and
application
changes
to
occur
in
a
consistent
manner
and
allow
us
to
tell
a
complete
picture
of
what's
changing
in
the
system,
for
everybody
to
see
that
provides
radical
transparency
as
to
how
your
SAS
is
changing
and
allows
every
member
of
the
team
to
actually
take
a
look
and
investigate
and
see
what
happened.
B
B
Last
thing
from
a
behavioral
perspective
is
really
improving
ownership
about
our
availability
and
that's
implementing
error
budgets
for
each
service.
As
I
have
mentioned,
it
really
galvanizes
the
behavior
that
the
development
teams
are
accountable
for
operational
stability.
If
we
fall
below
our
error
budget
for
the
month,
we
automatically
put
features
on
the
back
burner
and
focus
on
stability
for
that
service.
It
really
takes
the
guesswork
out
of
how
to
prioritize
feature.
Work
versus
technical
debt.
B
It's
like
skateboarding.
If
you
practice
one
time,
you're,
probably
not
gonna,
be
that
good
at
it
right.
You
need
to
keep
practicing
these
behaviors
to
reinforce
it
and
drive
that
change,
which
ultimately
impacts
your
culture.
We
continue
to
practice
and
learn
every
day.
The
tools
and
processes
that
you
use
on
your
journey
are
gonna
change,
so
just
need
to
accept
it.
This
is
the
world
that
we
live
in.
It's
part
of
learning
and
getting
lean
like
I
said
we
use
Jenkins,
so
we
have
about
15
micro-services
and
realize
we
can't
manage
the
complexity
anymore.
B
We
couldn't
really
foresee
that.
That's
something
that
you
learn
as
you
go
along
and
if
we
would
have
been
able
to
forecast
that
we
wouldn't
have
invested
it
all
in
Jenkins,
we
improved
our
focus
on
the
cloud
and
rationalize
our
product
portfolio,
more
systems-level,
thinking
to
understand
what
features
across
all
of
our
products
maybe
make
it
fit
as
a
service
in
our
in
our
platform
and
then,
lastly,
changing
culture
by
changing
behaviors,
empowering
and
trusting
teams
to
make
changes,
providing
them
the
tools
and
support
and
visibility
to
make
them
accountable
for
their
service
in
production.
B
I
want
to
highlight
quality,
availability,
security
and
scalability.
That's
everybody's
job.
It's
one
team
providing
the
service.
It's
xwy
team
learning
to
be
lean,
continuous
learning
and
practicing
to
get
better
every
day,
sharing
through
transparency,
visibility
and
measurement
and
being
blameless.