►
Description
If you’re looking to improve your current SDLC processes or if you’re new to DevOps practices, it can be difficult to know which tools are best for your team. Our host, Carmen Palomino Marced, Enterprise Account Manager at GitHub, will facilitate a discussion between Eric Nieuwenhuijsen, Technical Director at Backbase, and Clemens Reijnen, Global CTO Cloud & DevOps Leader at Sogeti, where they’ll share more about the tools that help developer teams collaborate across the DevOps toolchain and lifecycle, from automation in workflows to the security of the software supply chain. Together, they’ll discuss their unique DevOps journeys, their motivations for making the changes, and the tools that help increase software development velocity.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
A
So
this
is
the
agenda
for
today.
What
we're
going
to
be
talking
about?
There
are
three
main
topics.
Topic
number
one
is
organizational
efficiency
and
how
you
can
leverage
how
a
company
can
leverage
a
platform
to
optimize
the
reusability
of
their
previous
work.
Second
topic
is
going
to
be
about
software
delivery.
How
one
can
accelerate
high
quality
software
development
and
make
sure
it
gets
quicker
to
market,
and
then
the
third
topic
is
going
to
be
how
to
scale
your
business
so
how
to
consolidate
and
scale
as
your
teams
and
the
requirements
of
the
company
grow.
A
B
Yeah
thanks
thanks
carmen
and
thanks
thanks
for
having
me
today,
so
I
think
my
hair
does
match
my
head
pictures.
I
think
that
one
still
checks
out
at
least
yeah,
I'm
eric
I'm
a
technical
director
at
back
base
and
specifically
responsible
for
what
we
call
the
back
base
as
a
service
discipline
and
which
is
our
sales
offering
and
responsible
for
our
system.
Engineering
discipline,
which
is
either
referred
to
as
system
engineering
or
as
devops,
basically
taking
care
of
yeah
the
infrastructure
and
also
the
sdlc
within
backbase.
B
But
you
might
be
wondering
hey
what
is
backpace,
because
it
might
not
be
the
best
known
band
because
we're
often
hidden
behind
the
scenes
yeah.
So
backbase
is
a
vendor
of
what
we
call
an
engagement
banking
platform,
really
helping
banks
architect
around
the
customer,
allowing
customers,
our
banks
or
customer
banks
to
really
innovate
like
innovate
like
an
eo
bank,
where
they
don't
renovate
their
entire
core,
but
they
attach
the
back
based
platform
to
it,
giving
their
users
the
best
possible
experience
all
throughout
the
customer
life
cycle.
B
B
I
think
that's
really
the
functional
part
of
what
backbase
does,
but
you
might
be
wondering
hey.
Can
we
get
some
numbers
on
what
what
do
you
do?
Github?
What
kind
of
yeah?
What
do
you
see
so
backbase
as
a
yeah
engineering
organization,
has
about
600
people
or
more
than
600
people
these
days
building
the
product?
We
do
one
and
a
half
million
builds
every
year,
and
I
think
this
is
even
outdated.
Even
more
these
days
three
thousand
releases
a
year,
there's
more
than
100
teams
working
on
it.
B
C
You
carmen
and
eric
that's
really
impressive,
all
those
numbers
at
so
so
I'm
the
cto
for
cloud
and
devops
of
society.
Sojuti
is
part
of
the
larger
group
of
capgemini
and
and
when
you
look
what
we
are
doing
as
sojuti,
we
are
a
traditional
system,
integrator
working
together
with
our
customers
in
in
helping
them
improving
their
delivery.
C
We
are
present
roughly
in
a
hundred
locations
around
in
13
countries.
At
this
moment,
17
000
people
large,
and
what
you
see
on
the
left
side
on
this
slide
is
ss
and
we
are
helping
our
customers
with
devops.
We
are
helping
them
with
the
adoption
of
clouds.
We
are
helping
them
with
leveraging
the
cloud
capabilities
the
most
and
in
gaining
that
business
failure
out
of
it
and
actually
something
where
I'm
quite
proud
of
is
is
we
are
sharing
those
practices,
how
we
are
working
with
those
customers
with
those
enterprises.
A
C
The
globe
we
write
papers
around
this,
we
do
that,
together
with
microsoft
and
github,
you
see
three
papers
in
here.
Two
of
them
are
already
downloadable,
the
last
one
we
will
share
half
of
may,
then
it
will
be
available
and
we
will
put
the
download
link
in
the
chat
there.
I
think
it's
quite
valuable.
A
Awesome
thanks
clements
right.
I
think
we
are
I'm
not
mistaken.
It
is
time
to
get
started
I'll
I'll
start
sharing
again
when
we're
ready
for
the
q
a
from
the
public,
but
for
now
it's
time
for
the
three
of
us
to
get
going
and
what
best
place
to
start,
and
it's
going
back
to
the
back
to
the
past.
I'd
love
to
go
back
a
few
years
ago
when
you
were
starting
your
devops
transformation.
A
B
So
previously
people
were
really
focused
on
yeah,
just
building
their
software,
that
being
it,
and
now
we've
moved
to
the
situation
where
people
can
actually
become
run
responsible
where
they
are
end-to-end
responsible
building
things
collaborating
in
a
much
more
efficient
way,
simply
because
it's
easier
to
share
code,
the
pipelines
are
co-located
and
yeah.
Previously
that
wasn't
really
the
case
where
we
had
disjunct
solutions
using
an
on-premise,
on-premise
kit
solution
with
a
traditional
ci
attached
to
it.
C
Yeah
and
then
what
else
just
mentioned
that
that
they
are
want
to
focus
on
on
that
product,
on
the
devops
teams,
which
are
end-to-end
responsibility
for
one
product
or
a
service,
that's
definitely
the
goal
of
many
organizations
what
we
are
supporting
around
the
globe.
That's
also
what
our
teams
are
are
looking
after
actually
years
ago.
C
I
think
when,
when
microsoft,
with
their
team
foundation,
server
also
moved
online
to
making
at
a
sas
product,
we
were
definitely
the
first
one
who
started
to
adopt
that,
because
we
don't
want
to
lose
resources
in
maintaining
such
an
on-prem
system
and
and
really
having
them
focus
on
on
on
on
devops
tools
on
on
creation
of
value.
There,
that's
how
we
started.
C
We
started
first
with
starting
to
use
dfs
then
moved
to
dfs
online.
I
think
it
was
called
visual
studio
online
at
that
moment
and
then
later
on,
it
went
on
to
azure
devops
and
now
we
are
spreading
actually
to
to
github
and
and
the
sas
version
of
github
there.
First,
definitely
with
only
the
git
repos,
but
now
github
actions
getting
more
mature
and
really
rich
on
the
capabilities,
and
I
must
say,
our
teams
are
loving
it.
Customers
are
really
starting
to
adopt
it
there
and
that's
where
the
devops
transformation
starts.
Actually.
B
C
That's
why
we
want
to
automate
as
much
as
possible,
and
you
really
want
to
have
those
devops
teams
focus
on
that
product
and
service
and
don't
have
to
maintain
everything
around
there.
Don't
have
to
build
stuff
again
and
again
and
again
all
those
shared
services
that
should
be
quite
easily
consumable
for
those
teams
focus
on
business
value.
That's.
B
A
So
you're
kind
of
going
already
into
the
next
question,
which
is
what
made
you
go
towards
the
change
you've
talked
about
laziness
about
automation,
about
making
the
developers
actually
work
on
the
project.
They're
meant
to
be
working
on
rather
than
maintaining.
Was
there
any
other
things
that
prompted
the
changes
from
a
organization
perspective.
B
C
Yeah
and
then
that's
definitely
what
you
see
with
with
many
customers
what
we
are
supporting
there.
One
thing
what
we
are
using
quite
heavily
is
around
github
is
the
idea
around
open
source,
but
then
mainly
putting
it
also
internally
for
soldier
dia,
we
are
16,
17,
000
people
large
all
over
the
globe,
our
team
members.
They
learn
to
use
git
and
get
help
on
their
schools.
They
are
quite
familiar
with
it.
They
are
comfortable
with
it.
C
So
when
we
are
leveraging
and
making
this
platform
available
for
all
our
people,
they
are
just
happy
with
it.
They
want
to
have
the
best
platform
out
there
and
where
they
are
used
to,
and
they
are
comfortable
with
it
and
and
because
all
those
team
members
already
have
experience
with
open
source
on
school,
they
do
trainings
on
that
they
do
programs
with
it.
C
We
are
leveraging
that
idea
that
collaboration
capability
of
github
to
to
promote
our
inner
source,
way
of
working
sharing
knowledge,
sharing
expertise,
sharing,
automation
and
sharing
those
those
reusable
assets
actually-
and
that's
that's
for
us
really
important
around
there
and
that
that's
definitely
where
github
enterprise
brings
that
benefit.
There.
B
Nicely,
I
think,
you're
a
step
further
in
that
that
journey
already
on
the
inner
sourcing.
It's
really
one
of
our
goals
for
this
year
to
get
that
up
one
notch,
because
in
the
end,
you
don't
want
dependencies
on
other
teams
to
develop
something
for
you.
You
want
to
say
hey
if
you're
in
hurry,
there's
my
repo
make
a
pull
request,
we'll
review
it
and
merge
it
in
and
yeah,
I
think,
really
yeah
using
the
open
source
model,
but
that
inside
your
company
to
make
that
make
that
possible.
C
C
I'm
I'm
doing
it
for
inner
source,
I'm
definitely
doing
it.
We
are
also
measuring
how
many
pull
requests,
how
many
repos
we
have
a
full.
We
call
it
our
our
github
program
office,
it's
actually
extracted
from
the
open
source
program
office,
but
we
put
it
because
we're
also
doing
it
for
internal
projects
for
customer
projects.
We
call
it
the
get
a
program
office,
that's
where
we
are
measuring
how
actively
it
is
used
and
also
how
they
are
using
it.
C
You
can
imagine
we
are
hiring
a
lot
of
new
people
on
a
daily
basis.
We
need
to
keep
on
training
them.
We
need
to
make
them
aware.
This
is
how
you
use
git.
This
is
how
you
use
github,
for
example,
don't
put
ip
on
public
repo,
it's
so
obvious,
but
it
still
happens.
Sometimes
they'll
put
credentials
on
public
repos
so
that
that's
where
we
are
bringing
that
training
in
place
and
just
to
to
scale
out
from
there.
That's
that's!
That's
the
whole
idea.
There
yeah.
B
I
think
that's
really
the
inner
sourcing
part
you
know
so
for
us
as
we're
just
starting
that
we
don't
we're,
not
really
focused
on
measuring
that.
Yet
so
what
I
really
see
on
our
side,
we
are
on
the
operational,
excellent
side
of
things
right.
So
how
do
we
make
sure
that
we
don't
spend
operations,
resources
on
maintaining
on-premise
solutions
and
yeah?
What
follows
from
that
is:
what
kind
of
cost
optimizations
can
we
get
from?
Switching
to
a
managed
service.
B
So
cost
is
always
a
big
one
and
yeah
I
mean
I'm
mentioning
it's
the
first
one,
it's
of
course
one
of
the
key
drivers
to
do
when
selecting
a
solution
solution
like
this,
but
also
speed
of
onboarding.
So
how
fast
can
people
get
started
and
how
fast
can
we
add
capacity
in
the
end?
That
was
something
which
often
lacked
when
using
on-premise
solutions.
If
you
have
to
add
capacity
manually
and
that's
a
problem
and
right
now,
we
don't
even
think
about
it
anymore
and,
of
course,
your
availability.
A
B
Yeah
various
sources,
and
so
I
will
be
the
first
to
admit
that
some
things
are
also
gut,
feel
see
where
we
are
with
with
measurements,
and
that's
also
good
right
and
some
things
are
more
based
on
a
hard
number.
So
indeed
yeah
synthetic
testing
making
sure
we
get
the
nice
availability
numbers
at
the
end
of
the
year
or
at
the
end
of
the
month,
to
see
where
we
are.
C
Yeah
yeah
and
then
definitely
what
we
also
do
from
measurement
it
is.
We
want
to
contribute.
Have
our
team
members
contribute
to
open
source
because
that's
where
our
new
partners
are
that's
where
the
community
live,
so
that
that's
what
we
try
to
measure,
but
they
often
do
it
on
just
on
public
recognition.
C
B
C
How
much
are
you
contributing
to
each
other's
project,
to
other
projects,
open
source,
inner
source
and
internal
projects,
and
and
how
much
is
what
you
build
is
used
by
others
yeah,
I
I
really
love
those
metrics
I
discuss
with
management
requires
some
massaging.
There
requires
some
discussion,
but
we
start
to
measure
it
at
least
already.
B
It's
also
a
different
school
thinking
right
that
people
are
traditionally
often
thinking
hey
it's
my
ip.
I
want
to
keep
it
internally,
but
what
I
always
like
to
stress
is:
if
you
want
operational
excellence,
be
lazy,
so
contributed
open
source,
so
there's
more
people
contributing
to
it
and
you're
not
stuck
with
maintaining
a
fork
which
happens
at
a
lot
of
companies
that
they
fork
something
take
it
a
closed
source
and
then
keep
mainly
maintaining
it
there.
So
at
least
to
me,
it
really
makes
sense
to
always
make
the
open
source
contribution
upstream.
C
Yeah
and
for
us,
inner
source
is
at
this
moment
the
most
easiest
to
maintain
yeah
and
and
that's
where
I
really
promote
people
and
I
award
people.
I
get
some
dice
stickers
from
github
when
they
are
making
a
nice
contribution.
I
give
them
a
sticker.
Now
we
can
travel
again,
that's
how
we
are
measuring
it
actually
and
that's
how
we're
awarding
it.
It's
quite
cool.
A
B
C
Yeah
and
from
our
side,
we
have
some
some
nice
stories
there,
knowing
that
that
yet,
let's
say
12
years
back,
git
was
not
that
common.
Yet
there
were
other
version
control
systems.
I
even
still
have
experience
with
people
who
are
using
file
systems
as
version
control
systems,
just
copy
paste
and
change.
The
version
number
behind
it.
A
C
Where
you
see
that
so
so,
I
need
to
start
train
people
on
git
first
and
they
were
not
quite
understanding
about
the
whole
concepts
of
distributed
version
control
systems.
So
that
that's
what
we
started
with
massaging
that
in
and
then
we
started
to
use
github
for
us
github,
mainly
focusing
on
the
repos.
B
B
Hearing
yeah
sure
yeah,
so
what
we
see
when
we
started
out
the
back
base
as
a
service
proposition,
we
started
with
one
team,
which
is
nice
and
yeah
as
we're
scaling.
It
really
seeing
some
more
diversification,
and
so
we
have
teams
focusing
on
the
platform
layer
as
I
like
to
call
it,
which
is
more
doing
infrastructure
as
code.
So
these
are
people
using
terraform
to
spin
up
environments
on
aws
azure
and
maintaining
that
via
github
actions.
B
But
I
also
have
a
team
really
taking
care
of
what
we
call
the
scalable
ci
solution,
unifying
the
ci,
where
we
actually
create
tooling
around
having
self-service
to
use
github.
So
employees
within
our
organization
can
use
that
to
create
their
own
repos
can
use
it
to
apply
certain
standards
that
we
have
within
back
base
to
the
repos
without
having
to
get
admin
access
on
organizations.
B
So
we
have
a
governed
model
there
and
of
course
we
have
a
team
working
on
reusable
workflows,
sample
repos
to
adopt
by
teams,
so
they
can
really
start
from
day
zero
and
they
don't
have
to
copy-paste
everything
from
stack
overflow
or
from
samples
online,
but
they
have
a
nice
back-based
tailored
yeah
back-base
standard
snippet.
To
start
with.
C
And
actually
the
self-serving
part
that
that's
what
we
are
doing
internally
within
society
also,
and
actually
we
are
so
doing
it
for
the
whole
of
capgemini
group.
That's
340,
000
people,
it's
crazy,
big,
and
then
you
can
imagine
that
there
are
so
many
different
stacks
on
it.
We
have
the
microsoft
stack
with
net
java
stack
with
spring,
also
azure
gcp
aws.
C
B
C
It
it
runs
everything,
and
indeed
we
also
built
a
small
self-servicing
portal
in
front
of
it.
So
the
team
can,
without
having
admin,
access,
request,
access
to
to
other
repos
request
access
to
organizations,
because
we
reorganized
our
github
enterprise
instance
in
different
organizational
units
where
we
also
have
one
inner
source
organizations
and
one
open
source
organizations.
Everything
below
there
is
set
and
onto
private,
because
we
say
those
are
the
customer.
C
C
C
We,
we
are
tracking
that
and
we
are
automating
actually
that
they
get
notifications
and
that
they
are
solving
those
those
dependency
errors
on
the
public
one
and
we
are
using
it,
but
from
security,
for
example,
and
all
those
kinds
of
configurations
we
started
to
to
switch
on
for
our
teams,
because
it's
it's
such
a
widespread
organization,
all
around
yeah
and-
and
we
really
need
to
make
it
easy
for
them
to
do
it.
The
right
way.
A
C
For
me,
that's
the
cool
thing
about
git,
because
there
are
apis
around
everywhere.
What
I
meant
to
we
build
our
own
self-servicing
portal.
We
build
that
on
top
of
the
apis
of
github.
We
are
installing
also
a
a
github
application
into
an
organization
which
can
help
and
maintain
and
monitor
all
the
stuff.
So
the
integration
capabilities
of
github
are
are
phenomenal.
Actually
it's
it's.
I
really
like
it
with
with
azure
devops,
it's
quite
obvious
that
works
quite
smooth
with
jira
no
problem
there.
C
We
only
need
to
create
a
a
principal
account
for
them,
and
then
they
can
start
working
on
it
and
with
all
the
the
github
actions
which
can
be
deployed
to
any
cloud
provider.
That's
that's
the
easy
part
that
that's.
I
was
surprised
in
how
fast,
for
example,
google
contributed
to
github
actions
which
provides
a
capability
to
deploy
on
gcp
the
same
way
aws
did
to
deploy
that
on
their
area.
B
You
eric
yeah,
I
think,
a
similar
story
from
our
side
as
well.
So
we
have
a
few
things
that
we
take
from
the
marketplace,
simply
where
we
decided
hey.
Let's
also
stop
using
on-premise
solutions
of,
for
example,
sonar
cloud
or
sonocube,
and
let's
switch
to
the
sonar
cloud
offering
so
using
a
turnkey
integration.
So
we
once
again
don't
have
to
manage
it
ourselves
following,
I
guess
the
laziness
principle,
which
I
mentioned
before
already
yeah,
really
easy
to
do
these
kind
of
things
and
yeah
on
the
part
of
the
apis
yeah.
B
I
fully
concur
there.
It's
what
you
expect
of
a
present
day
solution
but
get
the
password,
and
we
use
it
a
lot.
We
actually
use
terraform
to
configure
our
organizations.
We
use
terraform
to
configure
the
self-service
repos
to
really
leveraging
concepts
of
desired
state
configuration
with
terraform
and
through
pull
requests.
People
can
request
new
organizations
to
be
added
or
new
repos
to
be
added
or
settings
to
be
changed.
A
That's
so
eric,
I
see
we
have
a
question
in
the
public
that
actually
touches
a
little
bit
about
what
you're
discussing
right
now,
which
is
the
enforcing
standards
of
coding
like
the
way
you
use
branches
issues,
release
new
debt
or
onboarding.
I
guess
that's
what
this
person
is
discussing
like
did
you?
How
do
you
use
github
to
enforce
these
standards,
or
did
you
use
something
else.
B
Yeah,
so
we
have
a
few
things
there
right.
I
think
one
of
the
things
we
are
very
keen
about
is
enforcing
branch
protection,
and
so
that's
one
of
the
things
we
always
set
on
repos
that
gets
set
up
and
in
terms
of
pipelines
we
like
to
follow
the
70
30
principle.
So
70
is
predefined
and
it's
untouchable
and
30
is
up
to
the
team
to
change
because
they
need
to
customize
things.
So
you
really
see
certain
requirement
elements
like
maybe
container
scanning
being
there.
B
C
Yeah
same
way
for
us,
we
are
looking
how
they
are
using
github
when
they
are
using
the
self
servicing
portal.
All
that
settings
are
made
in
the
right
way.
Branch
protection
is
set
up,
depend
on
what
is
switched
on
all
those
kinds
of
stuff.
They
have
the
freedom
to
switch
it
off,
but
that
that's
what
our
github
application
does.
C
C
The
notification
has
a
link
to
the
policy
saying
okay.
This
is
why
we
have
this
policy
in
place.
We
give
and
that's
what
I
I
like,
what
we
are
doing
there
and
just
in
time,
training
hey.
This
is
how
you
can
do
it
and
then
helping
them
and
when
it
is
a
important
policy,
for
example,
no
customer
code
in
there
are
no
customer
names
in
your
code
or
no
secrets
in
your
code.
C
B
C
Standards
I'm
looking
into
maybe
start
creating
some
code
quel
queries
to
to
analyze
what
they
are
doing,
but
that
will
be
mainly
for
for
public
contributions
when
they
are
using
society,
name
or
capgemini,
name
or
brands,
and
that
kind
of
stuff
we
need
to
be
careful.
And
then
we
want
to
to
know
that
that
they
are
doing
that.
B
All
right,
it's
interesting
that
we
have
a
slightly
different
approach
here
by
the
way
and
because
for
you,
it's
really
checking
afterwards,
whereas
we
have
a
bit
more
controlled
approach
that
we
really
say:
you're,
not
an
admin,
you
don't
even
have
the
rights
to
change
these,
these
settings
yeah
so
yeah.
I
think
both
models
work,
and
I
think
that
also
touched
a
bit
upon
the
subject
in
the
chat
talking
about
how
to
work
in
strongly
regulated
industries.
B
Yeah,
so
what
we
see
we
have
a
sock
too
at
the
station,
for
example,
where
we
definitely
enforce
controls
around
change
management.
We
do
it
on
the
change
manager
for
our
infra,
which
also
completely
relies
on
in
github
and
github
actions.
We
follow
a
git
ops
approach
to
deploy
software,
so
you
really
see
branch
protection
is
key
for
us
and
that's
perfectly
enforceable
that
way,
and
then
on
the
back
side
we
also
have
a
stopgap
solution.
So
all
the
audit
logs
we
get
from
github
are
exported
into
our
data
lake
and
from
there.
B
C
C
When
I
would
configure
github
for
a
financial
or
regulated
industry,
I
definitely
would
start
recommending
to
switch
on
those
kinds
of
enforcements
and
then
helping
them
creating
it.
Also.
I
don't
know
how
you
are
using
the
identity.
Do
you
have
them
connected
to
the
identity,
store
of
your
organization
or
are
using
their
personal
github
identities.
B
In
about
a
month
or
two
months
from
now,
we
should
be
switching
to
the
enterprise
mesh
users
as
well.
It's
been
a
long
time
coming,
but
we're
now
in
the
process
of
migrating
and
migrating
that
it
was
one
of
the
things
very
high
on
my
wishlist
to
say:
hey
use
your
azure
id
credentials
to
sign
on,
and
then
you
have
your
account
provision
straight
away,
so
that
will
make
it
even
better
for
us
and
then.
C
You
want
to
use
the
github
amu
enterprise
users,
one
yeah
exactly
and
yeah.
We
usually
we
won't
do
that
for
now,
because
we
are
big
different
kind
of
customers,
different
kinds
of
identities.
We
do
have
a
link
what
we
make
between
when
they
sign
up
for
the
self-servicing
portal.
We
make
the
link
between
the
github
identity
and
the
azure
active
directory,
so
that
we
know
who.
C
B
Well,
it
becomes
a
different
account
yeah,
but
in
our
sense
it
yeah.
It
was
a
trade-off
between
hey.
What
is
the
extra
control
you
have
with
onboarding
off-boarding
that
way
versus
what
is
the
ease
of
use
or
the
tracking
of
contributions
where
we
decided
to
say
hey,
we'll
sway
one
way,
instead
of
the
other.
A
C
A
A
C
Doing
it,
yes,
we
and-
and
they
are
free
to
choose,
if
they're
doing
it
for
sure
they
can
create,
or
at
least
can
create
two
different
youtube
identities
where
they
say
one
I'm
using
together
with
society
capgemini
the
other
one
I'm
using
for
my
personal
contributions
where
I'm
working
into
the
wild,
but
when
they
want
to
be
recognized
of
open
source
contributions,
they
need
to
make
that
link.
Otherwise
we
don't
know
that
they
are
doing
it.
A
C
Are
looking
for
society
and
kept
gemini
contributions,
and
we
we
do
find
once
in
a
while
some
contribution
where,
for
example,
an
interim
created
a
public
repo
where
they
created
a
database,
where
you
see
some
credentials
of
the
database
into
the
repo
we
need
to
help
them.
That's
why
we
are
starting
those
that
structure
where
we
say
we
have
open
source,
github
organizations
where
we
have
every
security
feature
configured
and
when
we
are
having
interims,
they
can
work
on
that
location
when
they
want
to
do
it
public.
C
B
B
A
Yeah
so
before
we
move
on
to
the
open
source
topic,
because
I
see
there's
a
lot
of
interest
in
the
chat
about
this,
I
do
want
to
ask
about
the
transition
and
how
it
affected
your
culture
and
values.
So
how
did
you
make
sure
because
transitions
are
always
very
exciting,
but
at
the
same
time
you
both
come
from
strong
companies
that
have
a
certain
mission
and
vision.
So
how
did
you
make
sure
that,
during
the
transition
you
kept
true
to
yourselves.
B
B
This
whole
transition
only
made
that
even
easier,
because
because,
instead
of
being
dependent
on,
let's
say
customer
infrastructure
or
yeah
coming
at
the
customers-
and
you
don't
know
what's
there,
but
actually
we
now
know
what's
there,
because
we
maintain
it
ourselves
and
it's
also
the
level
of
quality
and
the
level
of
configuration
we
expect
expected
to
be
so
that
since
it
only
encouraged
our
values,
we're
also
really
about
doing
things
together,
and
I
think
yeah
that's
been
made
easier
by
this
transition
as
well.
I
think
that's
it
in
a
nutshell
and.
C
And
for
society,
we
really
have
a
a
a
a
doing
culture,
a
way
of
working.
We
really
want
to.
I
always
create
value
from
technology
that
that's
all
months,
are
there.
What
we
are
putting
in
place
to
do
to
have
the
same
way
of
working
across
every
team
is
is,
and
you
triggered
me
eric
with
the
laziness
principle.
C
We
are
having
also
a
set
of
principles,
roughly
12
principles,
where
we
say
this
is
where
you
need
to
apply
to.
This
is
how
we
work.
This
is
who
we
are
and
the
laziness
principle
I
can
put
in
there
automate.
Everything
is
in
principle,
which
is
also
in
there.
For
example,
those
principles
apply
to
all
teams,
no
matter
what
kind
of
tool
or
technology
they
are
using,
because
I've
been
working
in
in
many
customer
scenarios
where
they
have
different
kinds
of
teams.
C
A
team
or
a
group
of
people
start
looking
at
those
principles
and
say:
oh,
this
is
how
we
are
implementing
this
for
our
technology,
because
you
can
imagine
it
is
different
for
sap
solutions
as
when
you
go
full
cloud
native
web
applications.
For
example,
then
those
implementation
of
principles
is
definitely
different
from.
C
Lucky,
yes,
that
makes
it
really
fast
and
and
what
you
were
started
with
and
making
a
devops
team
end-to-end
responsible
for
a
product
or
a
service
that
that's
definitely
one
thing
you
want
to
move
forward
with,
but
comment
to
answer
your
question.
We
stick
to
it
the
transformation
we
stick
to
the
way
of
working
fire
all
principles.
A
C
C
That's
how
you're
doing
it
interesting
there
I
I
tried
to
start
explaining
it
also
to
non-developers
hey.
This
is
how
we
are
doing
version
control.
This
is
how
we
do
distributed
working,
let's
start
doing
more
documentation,
s-code
and
start
putting
in
for
delivery
managers
and
service
catalogs,
also
in
git
and
those
kinds
of
stuff.
C
A
B
That
the
asynchronous
working-
and
I
think
covert,
has
shown
us
only
more
that
it's
possible
companies
before
were
really
traditional,
get
everybody
in
the
office
from
nine
to
five.
You
collaborate
in
the
office
where
people
now
say
hey,
I
wanna
walk
my
dog
or
I
wanna
do
something
during
the
day
and
they'll
just
work
in
the
morning.
B
They
might
start
a
bit
early
or
work
in
the
evening
that
sense,
yeah,
we're
quite
flexible
company
as
well,
and
we
really
see
that
the
asynchronous
model
with
pull
requests,
sending
out
a
review
request
to
somebody
and
that
works
for
us
and
people
will
get
to
it
when
they
get
to
it.
Sometimes
it's
more
urgent.
If
it's
more
urgent
people
will
review
it,
of
course,
but
otherwise
yeah.
It
might
take
a
few
hours
till
somebody
wakes
up
or
sees
says.
Oh,
let
me
go
through
it
and
yeah
that
works
really
well
for
us.
B
Am
actually
yeah,
but
it's
more
more
for
myself,
because
I'm
I'm
still
very
much.
I
love
hands-on.
I
love
doing
doing
contributions
every
now
and
then
I'm
just
clicking
through
a
few
pull
requests
to
see.
What's
going
on
and
that's
that's
what
works
for
me
sitting
on
the
couch
in
the
evening
and
just
clicking
through
through
a
few
things.
C
C
A
Yeah,
I'm
sorry,
I
don't
know
what's
happened,
I
can
you
hear
me,
though
yeah
okay,
it's
great.
Let
me
fix
my
screen,
I'm
really
sorry,
but
in
the
meantime,
we're
gonna
move
on
to
open
source
now
for
a
little
bit.
What
are
you
there
was
a
question
before
about?
How
are
you
guys
controlling
how
open
source
is
handled.
C
That
is
how
we
are
supporting
them.
When
a
organization
or
our
business
units
wants
to
open
source
a
certain
project,
we
have
a
just
a
checklist
for
it.
We
are
validating
them.
Okay,
is
there
no
ip
in
there
from
any
customer
or
any
project
which
don't
want
to
get
out
of
there
is?
Is
the
project
mature
enough
and
and
from
the
maturity
of
project
that
it's
quite
interesting?
C
I'm
eagerly
looking
into
do
a
pilot
with
scorecards
google
scorecards
they
partner
now
with
github,
to
to
show
the
maturity
of
a
project,
because
at
that
associative,
operational
excellence
and
that
kind
of
stuff
is
really
important.
So
when
we
put
something
open
source,
it
should
be
of
high
quality,
and
that's
where
I
am.
C
C
A
C
They
are
all
creating
those
those
projects
on
github
and,
and
they
are
blogging
about
it.
They
are
writing
about
it.
It's
really
nice
what
they
are
doing
and
that's
what
we
are
promoting
there,
but
controlling
the
quality
controlling
the
security
is
quite
important
there.
That's
also
what
I
see
in
the
chat
as
one
questionnaire.
Do
you
have
security
champions
among
your
different
groups
or
bunch
of
different
teams?
C
C
B
B
For
sure,
and
that's
really
where
you
have
to
learn
as
well,
so
you
have
to
have
the
right
guidelines
there.
You
have
to
really
determine
what
is
needed
to
make
a
good
pr,
and
I
think
that's
one
of
the
key
factors
also
to
determine
hey
if
something
mature
enough
for
open
source.
Yes
or
no-
and
I
mean
how
do
you
accept
contributions?
What
are
the
requirements
for
for
making
a
contribution?
C
Yeah
yeah
yeah,
and
that's
that's
also.
I
saw
somewhere
a
question.
How
do
you
maintain
it
and
do
you
have
some
organizations
around
that
for
our
inner
source
projects?
We
have
a
specific
group
of
maintainers
which
are
having
weekly
meetings
where
they
start
approving,
pull
requests
to
to
our
inner
source
library.
They
take
care.
It
is
all
consistent.
They
take
care
of
the
right
quality,
but
also
when
it
is
not
going
to
be
approved,
they
invite
the
contributor
and
they
are
teaching
and
they
are
learning
it.
B
Very
interesting,
that's
an
interesting
point.
You
touch
because
that's
where
I
see
where
a
lot
of
inner
source
models
at
least
are
failing
right
and
that,
if
you
don't
have
the
right
guidelines,
people
make
a
huge
pr.
They
may
have
spent
a
week
on
it
and
then
the
receiving
team
says
no.
We
don't
want
to
implement
it.
This
way.
Yeah.
That's
one
guaranteed
way
for
making
sure
you
will
never
ever
get
a
contribution
again
so
really
promoting
an
open
conversation.
B
A
C
A
B
C
A
C
Practices
of
the
teams,
as
I
mentioned
before,
I'm
cloud
endeavors
cloud
is
evolving
so
fast.
You
can't
have
all
the
knowledge
yourself.
That
is
the
goal.
What
I
want
to
reach
within
a
source,
one
important
item:
what
is
around
there?
What
is
the
product
where
you
are
looking
at
and
the
product
is
for
us
a
lot
of
automation,
around
infrastructure
as
codes
policies
as
well
pipelines
as
code
and
that
kind
of
stuff
what
you
touched
around
the
70
30
principles.
C
C
What
I
always
love
to
say
and
the
the
full
problem
should
be
understood
by
the
team
and
that's
where
I'm
really
pushing
towards
to
that's.
Also
a
a
cultural
thing.
Often
is.
I
have
when,
as
a
senior
you're
explaining
something
some
people
don't
dare
to
ask
hey,
I
don't
understand
it.
Can
you
elaborate
on
that?
C
B
A
C
C
B
It's
an
interesting
one.
I
think
that's
very
different
for
both
you
and
me,
because
yeah,
the
nice
part
is.
We
have
a
very
standardized
tech
stack
right,
we
develop
a
product
and
which
makes
this
quite
easy
for
me
to
standardize
following
the
70
30
principle.
Again,
I
can
really
say:
hey
this
70,
it's
locked
it's
out
of
the
box.
You
don't
need
to
touch
it,
be
lazy,
just
use
it
and
only
mess
around
with
the
final
30
percent
there.
B
C
C
It's
completely
different,
but
I
have
some
nice
horror
stories
from
organizations
who
were
just
said
to
all
their
devops
teams,
and
they
had
hundreds
of
devops
teams
saying
you
are
completely
independent.
Now
choose
whatever
you
want
yeah
you
can
imagine.
It
ended
up
in
a
a
chaos
of
all
kinds
of
different
testing
frameworks
and
different
platforms.
Teams
are
using
not
optimized,
not
reusable,
not
maintainable,
so
bringing
that
consistency
is
is
quite
important.
C
We
are
definitely
pushing
towards
inner
source
there.
We
have
our
our
libraries
with
all
those
cloud
infrastructure
as
code
just
to
standardize
in
when
they
are
creating
a
cloud
infrastructure
and
not
doing
it
from
scratch.
That's
quite
important.
One
on
the
standardization
where
I'm
looking
into
is,
is
also
standardized
around
devops
tools.
There,
the
the
cell
servicing
capabilities,
are
really
nice.
What
we
built
on
top
of
the
apis
of
github,
but
definitely
run.
You
have
different
technology
streams.
You
need
to
have
different
devops
tools.
C
Then
they
get
their
devops
platform
configured,
they
get
their
aws
landing
zone
and-
and
that's
also,
what
you
try
to
accomplishing
actually
is-
is
making
them
as
productive
as
possible
and
and
and
as
I
love
to
say,
making
the
first
pull
request
before
lunch
all
conform,
the
right
policies
or
conform.
The
way
the
right
way
of
working-
and
that's
where
I'm
looking
into
is
the
mantra
of
making
it
easy
to
do
it
the
right
way.
Yeah
and
automation
is
a
mandatory.
There.
B
And
I
think
I
think
it's
also
a
nice
lead
up
to
a
bit
of
a
wrap
up,
because
I
see
we
have
three
minutes
on
the
clock,
because
I
think
this
is
one
point
where
we
share
where
we
share
a
lot
of
thoughts,
so
yeah,
what
what
kind
of
advice
can
we
give
or
what
is
the
future
vision
on
this
right?
I
think
that's
70
30,
I
would
say
that's
one
of
the
most
important
parts
where
you
really
allow
software
development
teams
to
focus
on
software
development
and
not
on
the
boilerplate
around
it.
B
B
A
C
B
Yeah,
so
we've
just
dipped
our
tone
and
water
at
the
reasonable
workflows,
and
I
think
that's
really
one
of
the
things
where
we
will
be
expanding
on
a
lot
and
I'll
having
internal
actions
for
those
things
as
well.
Really
following
the
70
30
principle
and
yeah.
I
still
think
one
of
the
topics
these
days
is
code
spaces
we're
not
using
it
yet.
But
it's
one
of
the
things
we
are
considering
and
also
following,
I
would
say,
having
your
first
vr
out
before
lunch,
people
getting
started
getting
their
own
warning
done
fast.
C
Definitely
also
it's
something
where
we
are
looking
at
the
code.
Spaces
is
really
interesting.
Our
latest
report
is
around
secure
enterprise-
devops
environments.
It's
not
that
sexy
title
I
say
hackers
are
shifting
left
too
it's
much
more
interesting
is
how
do
you
secure
your
developer
environment,
because
devices
are
now
at
home
with
maybe
crappy
networks
or
at
home?
It's
often
better
networks,
but
kids,
who
are
touching
your
machine
is
installing
strange
gaming
stuff.
B
That's
really
interesting
for
byod
as
well
right
what
we
see
as
well
hiring
specialists
across
the
world
and
it
takes
long
to
ship
a
laptop
there.
It's
a
very
cumbersome
process.
So
if
we
can
tackle
something
that
way,
yeah
hi
on
my
wishlist,
but
not
sure
yet
when
it
will
be
there,
be
adopted
on
our
side.
A
A
Athena,
oh
yeah,
a
big
thank
you
to
eric
and
clements
for
being
so
interesting,
so
engaging
talking
to
each
other
and
talking
to
you
being
so
professional
during
my
as
clemons
was
kind
of
saying
these
things
do
happen
and
they
were
both
such
professionals.
So,
thank
you
so
much.
What
we
have
coming
up
next
is
maya.
A
Ambass
maya
is
one
of
my
direct
colleagues
and
buzz
is
a
principal
solutions,
engineer
both
working
in
the
nordics,
and
they
are
going
to
be
talking
about
what
organizational
efficiency
means
and
how
to
get
your
business
there.
So
for
some
of
you
that
were
talking
about
how
clematis
and
eric
and
how
socialty
and
backbased
got
to
where
they
are,
what
processes
they
had
to
what
policies
they
had
to
think
of
this
session
will
be
the
one
that
will
be
kind
of
on
going
deeper
into
those
questions
that
you
had
for
us.