►
Description
Elisa and Eficode co present the OpenShift on Elisa Case Study at OpenShift Commons Gathering at Red Hat Summit 2018
A
A
First
shortly
about
ourselves,
my
name
is
Sarah
hvala,
the
guy
on
the
left,
and
the
fine
gentleman
next
to
me
are
Nicolas
Tom's,
cannon
hi
and
yes,
Holcomb
and
all
of
us
tree.
We
work
at
the
dev
ops
team
in
ELISA
what
we
do
among
other
duties.
Our
task
is
to
keep
OpenShift
up
and
running,
but
also
support
the
development
teams
so
that
they
have
a
kind
of
a
pleasant
journey
with
putting
their
applications
running
in
containers
and
open
shifts.
I
guess
there
might
be
some
people
among
you
who
are
not
from
Finland.
B
B
C
Right
and
then
just
a
few
words
about
depakote
and,
more
importantly,
about
the
collaboration
between
le
scientific
code,
so
severe
and
I
work
at
the
FE
code.
F
record
is
a
leading
develops
house
in
the
Nordics.
We
have
almost
200
professionals
in
the
Nordics
Nordic
countries,
and
what
we
do
is
that
we
enable
organizations
to
reach
the
fullest
potential
in
today's
digital
world,
and
we
tell
is
already
building
leading
telco
and
foreigner
in
digital
services.
C
It
was
held
last
year
in
Helsinki
or
the
design
system
conference,
which
was
right,
organized
just
lately
also
in
Helsinki,
and
what
we
aim
to
do
as
organization
is
to
learn
from
each
other
and
do
and
build
great
stuff
together,
but
enough
about
that.
Let's
move
on
to
the
topic
of
the
day,
which
it's
going
to
start
by
introducing
the
software
engineering
model
Atalissa,
which
is
a
model
that
describes
how
software
direction
and
software
development
should
be
done
at
Elysa,
and
it
comes
to
around
three
points.
First
of
all,
I
mean
in
a
platform.
C
C
And
finally,
we
want
to
shift
the
end-user
experience
to
the
teams
themselves,
meaning
that
product
in
production
should
produce
meaningful
metrics
to
the
development
team,
so
they
can
take
action
and
develop
the
product
in
the
way
that
the
business
sees
it
and
all.
The
other
thing
is
that
development
team
should
have
easy
access
to
production,
meaning
that
pipeline
from
the
get
commit
to
the
production
is
fully
automated
and
every
developer
has
access
to
it.
And
next
essay
is
going
to
tell
you
more
about
the
software
driven
cloud.
History.
B
So
we
have,
we
had
a
separate
kubernetes
clusters
for
every
team,
but
we
saw
that
it
didn't
work
quite
well,
because
we
didn't
have
enough
Kubasaki
that
people
in-house,
so
we
started
working
something
else
and
we
decided
to
use
opens
it
for
everybody,
2007
17.
We
had
a
one
opposite
cluster
for
everybody,
but
soon
soon
we
saw
again
again
that
it
is
not
maybe
the
perfect
solution.
We
have.
We
had
a
poppin
speed
stability
of
that
cluster,
and
then
we
had
only
one
cluster.
It
was
quite.
B
It
was
not
cool
situation
at
all,
so
2018
we
had
nowadays
two
products
and
clusters
and
two
development
clusters
for
everybody
and
because
we
have
two
opens
it
products
and
clusters.
We
need
some
kind
of
way
to
out
Palmas
traffic
between
this
I
have
seen
that
someone
uses
here
DNS
based
solution,
but
we
think
that
it
is
not
maybe
the
perfect
solution,
because
we
want
that
we
have
application
of
a
very
favorable
capabilities
and
we
can
archive
that
with
the
world
balancer.
A
All
right,
so
how
do
we
get
those
projects
in
the
production?
Well,
as
we
see
it,
we
have
to
get
the
developers
engaged
well.
How
do
we
get
that
done?
So
it's
actually
really
simple.
We
just
use
the
force
we,
we
burn
all
the
silly
VMs
to
the
ground
and
just
force
them
to
use
the
containers
and
put
them
running
on
open
shift.
Let's,
let's
have
a
quick
life
that
is
it.
Let's
have
a
quick
live
demo
of
this,
so
everybody
in
the
audience.
Please
stand
up
yeah!
That's
what
I
thought
you
can
sit
down.
A
If
you,
if
you
did
it
so
forcing
people
to
do
uncomfortable
things,
it
doesn't
really
work
out
that
well,
so
that
wasn't
the
way
to
go.
What
we
actually
did
is
that
we
took
a
pilot
project
so
enter
elisa
vida.
So,
as
you've
heard
it's
an
entertainment
service,
you
can
watch,
live,
TV,
rent
movies
and
stuff
like
that,
and
so
back
in
spring
2017
elizabe.
That
was
starting
a
new
project.
A
So
what
we
did
is
that
we
sat
down
with
the
development
teams
just
to
see
how
they
were
producing
software
at
that
point,
and
we
saw
the
table
using
Jenkins
as
their
primary
CI
CD
solution
and
how
they
were
deploying
in
the
production
they
had
these
VMs
that
they
were
and
they
were
deploying
the
software
using
ansible
and
they
weren't
really
familiar
with
containers
or
container
orchestration
platforms
and
such
and
in
in
general,
I
guess
they.
They
were
interested
about
about
openshift,
but
also
quite
a
few
people
were
a
bit
skeptical
as
well.
A
So,
as
all
of
you
know,
developing
with
with
containers
and
putting
the
production
running
on
top
of
them,
it's
it's
a
whole
different
game.
And
for
that
reason
we
wanted
to
start
out
with
something
that's
familiar
to
the
development
team.
So
we
took
Jenkins
and
we've
put
Jenkins
running
on
open
shift
and
we
integrated
the
CI
CD
pipelines
with
openshift,
using
the
openshift
jenkins
plugin
and
bit
by
bit
the
development
teams.
A
They
got
a
bit
more
interested
about
the
platform
and
kind
of
saw
what
it's
capable
of,
but
also
when
we
were
doing
it,
complexity,
crew
quite
fast.
We
want
to
do
a
different
kind
of
functionalities,
to
the
pipelines
and
and
and
such
so
in,
in
order
to
keep
everything,
maintainable
and
and
also
keeping
the
pipeline's
readable.
We
decided
to
create
our
own
shared
Jenkins
library
on
top
of
the
already
existing
OpenShift
Jenkins
plugin.
Next
Nicholas
is
going
to
talk
a
bit
more
about
the
shared
library.
C
So
why
we
created
this
library?
Well,
the
OpenShift
did
not
provide
support
for
things
that
we
wanted
to
do
out
of
the
box
and
neither
that
OpenShift
jenkins
have
plugin.
So
we
built
out
a
library
on
top
of
the
top
of
the
Jenkins
plugin,
and
we
introduced
multiple
features
like
multiple
production
cluster
deployments,
meaning
that
the
Jenkins
pipeline
will
deploy
application,
the
both
of
the
production
cluster
that
we
have.
C
C
So
here
I
am
in
one
of
the
deaf
clusters,
I'm
locked
in
using
single
sign-on
with
Elysa
credentials.
Everyone
has
these
credentials
already
every
kind
everyone
can
login
into
the
cluster
and
create
a
new
project,
I've
selected
Jenkins
from
the
catalog.
This
is
unread
hard
provided
Jenkins
with
some
modifications
and
I'm
deploying
it
here
and
before
the
Jenkins
container
starts.
C
It's
going
to
boot
up
an
init
container
in
front
of
the
Jenkins,
and
this
init
container
is
going
to
ask
the
developer
a
few
questions
about
the
plug-in
configurations
in
Jenkins,
so
that
I
don't
have
to
write
any
guides
on
how
to
do
the
configurations.
The
developer
just
simply
really
ignore
them
and
not
not
use
this
platform
at
all,
but
with
using
this
wizard
here
that
this
cool
wizard
that
tell
us
what
to
do
actually
I
can
engage
the
developer
easily
into
the
development
in
top
top
top
of
OpenShift.
C
C
C
Here
we
go,
get
commit
and
then
push,
and
now
it's
in
github
or
gate
and
going
to
the
Jenkins.
It
should
have
received
the
webhook.
Yes
there
it
is
it
received
back
from
the
github.
Please
start
building
this
branch,
and
what
now
happens
is
that
the
pipeline
is
going
to
build
the
infrastructure
that
it's
requiring
do
the
open
shift.
So
here
I
am
it's
already
being
deployed
and
you
notice
that
it
has
a
hello
world
red
so
that
it
has
the
app
name
branch
in
it.
C
And
if
we
go
to
the
shared
library
here,
this
is
one
of
the
template
files
of
the
library.
This
is
a
root,
object,
template
file
and
what
the
pipeline
does
is
that
we
substitute
these
variables
on
the
template
file
with
variables
in
the
path
from
the
pipeline
and
if
I
now
get
the
root
from
the
OPA
shift,
and
this
route
here
was
created
by
the
pipeline
using
the
distant
plate
as
a
basis.
C
So
this
way
the
developer
really
doesn't
even
have
to
know
about
openshift
objects
and,
if
I
now
fast
forward
to
build
so
and
change
the
URL
from
the
master
branch
to
the
red
branch,
I'll
red
background
and
I
think
that
if
you
were
fast
enough,
you
saw
that
I
only
use
the
gate
here.
Everything
else
was
fully
automated.
The
openshift
was
automated.
C
The
Jenkins
build
was
automated
only
the
only
thing
that
I
did
was
a
simple
gig
check
out
and
get
comment
and
get
push,
and
this
really
enables
the
developer
to
have
a
very
fast
start
with
open
shift
and
start
hacking
about
stuff.
And
if
you
think
about
new
EX
designer
he
or
she
can
now
change
the
layout
and
just
do
a
simple
git
push
and
it
will
end
up
in
openshift
and
they
can
share
the
route
with
product
owner
or
business
owner
immediately.
A
Alright,
so
of
course,
all
of
this,
it
wasn't
just
a
walk
in
the
park.
We
had
some
challenges
as
well.
Maybe
the
first
one
is
that
keeping
the
development
teams
engaged
with
the
CI
CD
practices
and
with
ownership.
It's
it's
actually
quite
challenging.
Our
initial
plan
was
to
provide
really
good
support
in
the
beginning
and
then
kind
of
slowly
allow
the
development
teams
to
take
full
ownership
of
all
their
pipelines
and
kind
of
fade
into
the
background
and
let
them
handle
their
stuff.
A
Well,
didn't
really
work
out
that
well,
quite
soon,
we
realized
that
we
were
providing
to
quit
of
a
support,
as
the
developers
actually
fully
relied
on
us
on
all
their
CI
CD
OpenShift
related
needs.
So
lessons
learned,
you
really
have
to
try
to
find
the
balance
on
between
supporting
the
teams,
but
still
like
kind
of
allowing
them
to
make
their
own
mistakes
and
so
that
they
actually
take
tool
ownership
of
their
stuff.
But
then
again,
it's
also
really
important
to
have
like
kind
of
a
smooth
learning
curve
with
the
platform.
A
Of
course,
this
depends
on
the
people.
Some
people
are
more
more
interested
about
new
things,
but
some
people
are
don't
really
like
change
the
ways
they
are
working.
So
if
you
are
already
a
bit
skeptical
about
the
platform-
and
you
have
a
bad
first
impression,
you
start
blaming
the
problems
on
the
platform
itself,
so
that
what
happened
a
few
times
OpenShift
was
playing
for
many
of
the
many
of
the
bugs
that
were
actually
correlated.
A
C
During
our
time,
it
open
shipped
so
far
has
proven
that
it
can
handle
the
workloads
just
that
we
throw
at
it
and
maybe
a
little
too
good
one
day.
The
Ale
is
away
the
project.
Lee,
it
came
to
came
to
a
stand.
Is
it
really
so
that
when
the
pipeline
finishes
the
stuff
is
in
production?
Yes,
it
is,
and
they
deployed
accidentally
to
the
production
already
yeah
and
we
are
eager
to
see
how
the
platform
evolves
even
further.