►
From YouTube: GitHub Enterprise at scale: Behind the scenes at Salesforce.com - GitHub Universe 2018
Description
Presented by Vamshidhar Gandham, Lead Engineer (Salesforce), Vikas Sangwan, Director of Engineering (Salesforce), and Michael Johnson, Services Engineer (GitHub).
Wondering how to get started with GitHub Enterprise? This session is for you—especially if you're looking to migrate or onboard hundreds of developers. This talk will take you through Salesforce's migration journey, the tools they created to simplify migration, and how Github Enterprise has helped them change the face of DevOps.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Thanks
for
joining
this
session,
so
my
name
is
Vikas
sangwon
and
I'll
eat
services,
team
in
Salesforce
and
Engineering
Services
team
in
Salesforce.
Actually
we
help
our
scrum
team
to
be
more
agile
to
increase
their
velocity
and
we
build
lot
of
tools
and
automation
around
see,
ICD
automation,
die-offs,
automation
and
with
me,
I
have
Vamshi
and
Michael
from
my
team's.
B
C
A
A
So
this
is
more
about
how
to
bring
this
change
in
the
organization
and
change
of
tool
is
very,
very
hard,
especially
when
it
is
a
developer
tool
which
they
are
used
to
use
from
last
couple
of
here,
and
it's
even
much
more
harder
when
you
bring
the
large
number
of
user
into
the
whole
picture
and
the
another
thing
which
add
another
dimension
in
the
complicity
is
how
many
enterprise
functions
you
have
to
collaborate
with,
for
example,
Sox
will
have
their
own
compliance
requirement.
Security
will
have
their
own
compliance
requirement.
A
So
how
do
you
do
make
all
this
changes
with
all
these
things?
So,
in
this
presentation
we
are
going
to
talk
about
some
of
the
strategy.
We
used
some
of
the
best
practices
which
we
learned
across
the
migration,
and
we
will
also
show
you
how
our
roll
a
rollout
plan
looked
like
one
of
the
principle
which
we
used
to
make
it
easy
for
anybody
to
do
the
changes
to
reduce
the
friction.
A
So
what
we
did
in
our
migration
is
to
create
the
automation,
create
the
tools
to
make
it
so
easy
for
customers
so
that
they
cannot
afford
to
not
use
it
so
we'll
share
some
of
those
practices.
Also.
Finally,
Michael
will
share
how
github
and
github
professional
services
how
they
can
help
you
to
go
in
this
journey.
For
us,
it
was
very,
very
useful
and
I'm
sure
you
will
also
find
useful
for
your
journey
also.
A
So,
even
today,
in
this
year,
2018
the
target
is
to
have
around
one
point:
nine
trillion
transaction
going
through
the
Salesforce
customer
platform.
For
us,
this
is
not
a
platform
for
us.
This
is
the
change
which
we
provide
to
our
customer
to
help
their
customer
meet
their
business
need.
So,
if
you
look
at
the
left
side
b2c,
we
are
sending
around
1.4
billion
emails
every
day
and
if
you
look
on
the
right
side
on
the
b2b,
we
are
sending
around
5
million
cases
every
day
logged
into
our
service
platform.
A
Now,
within
Salesforce,
we
have
the
basic
team
which
actually
help
our
businesses
teams
like
sales,
our
marketing
team,
our
CSG
team,
to
give
them
the
strength
to
deal
with
this
kind
of
business
and
my
team,
the
services
engineering
team.
We
provide
them
the
muscles
to
build
the
automation
around
those
tools
to
build
the
automation
around
CI
CD,
to
build
the
automation
around
the
developer
productivity
tools
to
help
them
deliver
all
this
value
to
our
customers.
B
B
We
kind
of
wanted
to
do
it
in
a
scalable
fashion,
and
the
model
we
chose
was
to
have
a
self-service
self
serviceable
approach
to
you
know,
facilitate
this
migration
by
the
end
users
itself
and
I
will
speak
to
those
details
in
a
minute,
but
part
of
this
any
such
change
management
that
is
involved
in
an
organization,
especially
when
there
are
you
know,
aspects
and
processes
related
to
it.
We
need
to
ensure
that
there
is
there
aren't
any
gaps
or
any
probability
to
do.
B
You
know
have
any
sort
of
friction
that
might
manifest,
so
that
leads
us
to
a
path
where
we
want
to
prefer
automation
over
to
manual
configuration
and
manual
steps.
So,
overall,
the
objective
was
to
keep
things
simple
and
automate
as
much
as
possible
and
keep
it
an
open
door
thing
so
that
you
know
your
end
users
really
loved
to
do
what
they
would
like
to
do.
So,
let's
hear
from
because
a
little
bit
more
about
how
that
rollout
was
looking
for
us
back
then
so.
A
Let's
go
into
some
little
bit
of
details
now
so,
as
it
was
a
huge
change
for
us,
we
need
some
big
decision
around.
How
do
we
want
to
organize
our
team?
How
do
we
want
to
bring
the
change
into
this
big
organization?
So
engineering
services
team
is
a
very
small
team.
It's
not
a
huge
team
and
we
didn't
had
a
big
budget
for
like
multi-year
project
to
do
this
migration.
A
So
we
came
with
the
concept
called
core
teams
where
we
took
the
people
from
all
the
partnership
team
so
that
we
can
create
a
kind
of
a
virtual
team
to
do
this
rollout.
So
what
you
see
in
the
middle
is
that
is
the
engineering
services
team,
which
is
the
kind
of
the
DevOps
team,
but
you
see
on
the
right
around
it.
We
had
the
representation
from
the
scrum
team.
We
had
the
representation
from
the
compliance
team,
security,
team
and
tech,
enablement
team
and
the
release
management.
A
The
release
management
might
be
not
familiar
for
all
of
you,
but
for
people
who
are
familiar
with
the
force.com
technology
release
management
is
a
very
integral
part
of
force.com
technology
and
we
as
a
Salesforce.
We
do
in
drinking
our
own
champagne,
so
within
our
company
itself
we
use
our
force.com
platform
to
develop
our
application.
A
Also,
so
that's
where
you
see
the
release
management
and
what
you
see
on
the
right
side,
we
had
the
scrum
teams,
we
had
around
70
scrum
teams,
so
we
had
presentation
from
the
edge
of
the
scrum
teams
so
what
it
created,
we
create
the
concept
of
ghe
champions.
So
all
the
people
who
were
part
of
the
core
team,
they
were
becoming
ghe
champion
and
they
were
helping
us
to
scale
this
whole
rollout
in
a
much
more
larger
way.
A
So
the
ghe
champions
they
were
responsible
for
talking
to
their
team
to
ensure
that
they're
aligning
to
the
common
goal,
and
then
we
were
bringing
everybody
together
in
the
core
team
meeting
once
in
two
week
to
decide
what
do
we
want
to
do
as
at
core
team?
What
design
decision
we
want
to
make
and
how
do
we
want
to
roll
out
the
whole
thing?
This
was
the
team
structure
then,
based
upon
that
team
structure,
we
came
up
with
the
rollout
plan.
What
do
you
see
here
in
the
blue
lines?
A
Those
are
the
actual
migration,
so
we
divide
the
whole
migration
into
multiple
releases,
so
there
was
around
five
or
six
releases.
What
you
see
on
the
screen
right
now
is
only
six
month
plan.
The
project
went
I,
think
for
nine
or
ten
months.
What
you
see
in
the
gray
color
is
the
implementation
work
before
we
actually
do
the
migration.
So
what
we
saw
in
the
previous
screen,
the
center
team,
the
team
was
doing
the
implementation
around
automation,
defining
the
best
practices.
A
The
yellow
color
shows
when
the
actual
migration
is
happening.
We
started
engaging
with
those
teams
which
are
actually
migrating
to
help
them
coming
up
to
speed,
and
the
green
is
actually
the
hyper
care
where,
after
the
migration
is
complete,
we
work
with
the
team
very
very
closely
to
make
sure
they're
after
the
release
processes
working
smoothly
after
this
migration.
A
So
we
started
with
the
pilot
implementation.
So
what
we
did
in
the
pilot
implementation?
We
choose
couple
of
teams
as
a
sample
and
that
sample
was
a
very
good
distribution
of
all
kind
of
the
work
bistec
team
is
doing
so
we
had
teams
which
were
building
on
force
comm,
which
has
team
which
were
building
on
node.js
and
on
Java.
Similarly,
we
had
teams
which
were
migrating
from
perforce
to
github,
and
we
also
had
the
team
which
were
migrating
from
github.com
to
get
her
banter
prize.
A
This
was
a
very
good
distribution
and
given
that
it
was
the
pilot
implementation,
our
team
engineering
service
team
was
very
closely
involved
with
the
doing
the
migration
itself.
So
we
implemented
some
of
the
automation
in
the
pilot,
like
repo
creation,
again
to
ease
the
movement,
but
it
was
not
like
fully
automated,
so
every
release,
we
were
adding
the
more
automation
and
we
were
moving
towards
the
self-service.
The
idea
here
was
there
should
be
no
need
for
this
DevOps
team
to
actually
do
the
migration
all
the
apps
team.
A
A
Now
we
had
the
team
structure
in
place.
We
had
the
planning's
place,
but
we
also
need
some
kind
of
rollout
strategy
so
that
we
can
ensure
that
this
change
is
happening
very
very
smoothly.
Now,
one
of
the
strategy
we
implemented
in
the
beginning
itself
is
we
wanted
to
have
the
early
partnership
with
all
the
required
enterprise
functions.
Sales.
A
Food
is
a
huge
organization,
and
our
business
technology
is
also
very
big,
and
we
need
to
ensure
that
whatever
change
we
are
bringing,
it
is
not
impacting
the
security
processes,
compliance
processes
or
release
management
processes
in
any
negative
way.
All
these
three
functions,
they
can
be
your
best
friend
or
they
can
be
your
biggest
hurdle.
A
So
if
you
want
them
to
be
your
best
friend,
it's
very
important
to
engage
them
as
early
in
the
process
bring
them
on
the
page,
so
they
can
be
actually
advocate
of
your
change
for
the
rest
of
the
team's
second
thing:
we
implemented
as
a
strategy
to
create
this
self-service
migration.
Playbook,
as
I
mentioned,
we
were
very
small
team.
Even
though
we
had
the
core
team
member
philosophy.
We
wanted
to
make
sure
that
Apps
team
they
can
do
the
migration
by
themselves
without
involving
us.
So
we
did
a
lot
of
automation.
A
We
created
a
very
clear
and
simple
playbook,
which
had
the
examples,
and
everything
mentioned
in
that
that
was
a
guide
for
anybody
who
want
to
do
the
migration.
So
this
helped
us
tremendously
third
thing
which
goes
hand-in-hand
in
with
the
PlayBook.
The
idea
was
when
we
create
the
PlayBook,
there
should
be
only
minimal
manual
steps.
So
basically,
we
had
only
three
steps:
pre-migration
step
migration,
scripts
and
post
migration
steps.
So
basically
the
team
has
to
do
the
three
migration
scripts
to
do
the
migration.
A
One
thing
which
I
think
was
very
helpful
for
us
was
to
have
lot
of
communication
with
all
the
scrum
teams.
We
had
the
core
team
meeting
every
two
week
where
the
core
team
members
were
talking
to
the
everybody
else
in
the
core
team,
and
then
they
were
going
back
to
their
team
to
discuss
the
decision
and
all
the
discussion
points
around
that.
A
But
another
thing
we
added
was
having
the
office
our
every
month,
so
in
this
office,
our
think
of
it
as
a
open
house
for
this
migration,
where
we
invited
all
the
scrum
teams
who
used
to
come
in
this
office
hours,
so
any
question
they
had
any
concern.
They
had
any
suggestion
they
had
around
their
design.
We
used
to
discuss
those
in
this
office
hours.
A
Finally,
to
make
it
much
more
easy
for
them.
We
had
a
concept
of
train-the-trainer,
so
we
first
trained
our
c
d,
c---eight
ghe
champions
and
they
then
themself
actually
trained
their
team.
Member
and
github
enter
services.
Actually
they
created
a
apps
for
us
called
pro
teacher
and
that
hep
was
very,
very
useful.
A
This
app
actually
run
on
the
browser
it
create
a
sandbox
for
the
github,
a
instance,
so
anybody
using
that
app
can
go
in,
they
can
create
a
new
arc,
they
can
create
a
new
repo
and
they
can
play
delete
and
everything
so
you're,
not
touching
any
actual
repos.
You
can
play
with
your
own
sandbox.
That
was
also
very
useful
for
us.
B
The
first
thing
is,
we
chose
the
approach
of
you
know
not.
You
know,
traveling
on
two
different
Sdn
systems
like
on
the
legacy
system,
as
well
as
the
new
github
enterprise
platform,
and
the
reason
for
that
is,
you
would
be
again
ending
up
with
a
lot
of
complexity
to
screen
the
changes
back
and
forth.
B
So
historical
audits
require
really
high
fidelity
history,
and
this
particularly
relates
to
you
know,
Gibbs
data
structure,
how
this
metadata
is
retained
within
github
versus
your
legacy,
SCM
system,
and
if
you
choose
to
bring
in
such
history
or
metadata,
you
would
be
adding
a
lot
of
complexity
to
your
migration.
So
that
brings
in
this
aspect
of
ok.
B
So
in
the
new
target
system,
we
started
off
with
this
migration
as
it
as
an
approach
where
which
of
the
branch
that
is
representing
your
production
instance
and
tagged
it
or
sticked
it
to
the
master
branch
in
github
and
any
of
your
branches
that
are
in
flight
or
your
release
releases
that
are
in
your
fly
in
flight.
They
represent
to
be
a
you
know:
low
lower-level
branch
within
your
github
system.
B
So
the
next
part
is
I,
think
a
little
bit
more
interesting
and
near
and
dear
to
me.
This
is
more
about
the
tooling.
We
have
created
to
facilitate
this
migration
and
some
of
the
customizations
that
may
be
relevant
to
you.
The
first
one
I
would
like
to
talk
about
is
the
automated
merge
to
lower
branches,
and
this
is
something
that
you
may
see
on
a
day
to
day
basis
that
you
have
at
your
at
your
work.
B
So
when
you
have
a
bunch
of
end
users,
a
bunch
of
developers
may
be
in
the
same
location
or
across
different
locations
and
you're
working
on
concurrent
release,
swimlanes
and
say
a
release
was
shipped
out
like
Sara.
Lee
is
one
right.
You
do
want
to
stream
those
change
into
your
rest
of
your
open
branches,
and
it
would
be
nice
to
actually
facilitate
this
in
an
automated
way
and
we
have
chosen
to
leverage
github
API
is
web
hooks
and
some
custom
tooling
to
facilitate
this
as
a
service
within
our
CI
system.
B
So
this
is
a
fundamental
use
case
that
you
may
run
into
on
your
github
Enterprise
instance,
and
this
is
again
totally
a
subjective
thing
based
on
the
work
flow
you
choose.
The
kind
of
you
know,
release
artifacts
the
mechanism
you
apply
to
it
and
specifically,
if
you're
a
force.com
developer,
you
will
certainly
find
a
lot
of
value
routes.
B
The
next
one
I
would
like
to
talk
about
is
some
of
the
control
mechanisms
we
have
chosen
to
implement
and
they
may
relate
more,
more
or
less
related
to
some
approval
mechanism
in
your
organization,
wherein
you
are
kind
of
like
seeking
some
approvals,
maybe
in
the
form
of
a
pull
request,
review
or
some
form
of
an
approval
from
a
change
management
so
on
and
so
forth.
So
that's
one
use
case
and
the
other
use
cases.
B
C
Thank
you,
Vamsi,
and
just
as
a
brief
reintroduction
of
myself,
I'm
Michael
Johnson
I'm,
a
services
engineer
with
github
working
on
the
professional
services
team,
there's
a
little
bit
of
background
for
what
we
provide
generally
and
I
project
provide
specifically
as
a
services
engineer
is
github.
Professional
services
goal
is
to
try
and
help
people
launch
into
their
initial
use
of
github
Enterprise,
as
well
as
github
comm
kind
of
early
in
the
implementation,
or
even
if
you
need
to
help
kind
of
in
the
middle
of
your
implementation,
phase
of
adopting
get
calm
and
what
I.
C
Personally
the
services
engineer
do,
is
I
kind
of
handle,
some
technical
assistance
with
github
customers
and
the
first
and
kind
of
most
obvious
for
us
on
this
stage
is
micro
migrations
to
github.
That
includes
migrations
from
legacy
tools,
as
well
as
across
different
get
platforms
and
even
going
from
github
calm
to
github
Enterprise,
and
vice
versa.
In
addition
to
that,
we
also
provide
administrator
mentoring
for
administration,
administers
his
administration
teams
on
github
enterprise
and
then
as
well.
In
addition
to
that,
we
also
provide
integration
tooling
to
other
tools
within
the
software
development
lifecycle.
C
So
very
particularly,
we've
focused
very
heavily
on
continuous
integration
and
continuous
deployment,
and
then,
if
there
are
any
extensions
that
need
to
be
performed
that
aren't
immediately
provided
as
a
first-class
feature
on
github.
We
also
provide
some
development
on
the
github
platform
to
help
extend
that
to
create
additional
validation
and
automation
and.
C
We
also
provide
some
more
cultural
transformation
offerings
to
help
customers
adopt
an
inner
source
culture
which
basically
takes
the
advantages
that
we've
learned
as
a
major
open
source
source
control
provider
and
help
companies
implement
that
behind
their
firewall.
And
then
we
work
on
workflow
consultations,
which
is
essentially
helping
development
teams
to
take
the
most
advantage
of
github
enterprise
and
github
to
help
streamline
their
development
workflow.
So
they
can
focus
on
coding
and
kind
of
push
the
the
details
of
CI,
CD
and
automated
testing
to
their
tools.
C
The
four
that
we
primarily
worked
on
at
Salesforce
together
were
migrations,
a
little
bit
of
github
enterprise,
admin,
mentoring,
some
API
consultations
and
a
lot
of
workflow
consultation
with
the
developers,
the
five
primary
personas
that
I
had
the
privilege
of
working
with
that
Salesforce
compliance
and
security.
This
was
kind
of
an
effort
to
take
what
was
already
a
very
strong
compliance
culture
at
Salesforce
and
the
great
system
of
implementation
that
they
had
within
their
legacy
system
and
ensuring
that
they
were
able
to
continue
to
be
compliant
as
they
moved
to
get.
C
So
we
kind
of
talked
through
a
lot
of
the
best
practices
and
uses
that
a
lot
of
other
companies
use
with
github
to
remain
Sox
compliant
was
a
main
one
for
us
and
in
addition,
we
talked
a
lot
about
some
token
scanning
and
things
like
that,
and
we
just
recently
today,
with
our
keynote
you've,
heard
some
new
advances
that
we've
had
with
that
kind
of
with
the
as
a
first-class
feature
as
well.
So
the
next
persona
that
we've
talked
a
lot
to
was
developers
and
other
they're
the
operations
team.
C
That
wants
to
ensure
that,
with
that
increased
autonomy,
that
they
were
still
ensuring
that
quality
code
was
being
shipped
and
that
you
know,
especially
on
that
force.com
stack,
that
they
were
able
to
ensure
that
the
deployments
were
happening.
You
know
correctly
and
with
a
high
level
of
quality.
So
that
resulted
in
a
lot
of
the
automation
tools
that
we
were
able
to
develop.
The
vom
she
mentioned
with
pre
receive
hooks
and
the
status
checks
and
with
some
of
those
it
actually
required.
C
The
the
involvement
of
the
github
Enterprise
admins
github
Enterprise
at
Salesforce
is
very
large
and
serves
a
large
large
number
of
developers
outside
of
just
the
teams
that
we
migrated
over
and
one
of
their
very
valid
requirements.
Is
that
any
of
the
implementation
that
requires
the
actual
configuration
of
the
github
Enterprise
instance
as
a
whole
needs
to
be
standardized
such
that,
if
we're
going
to
be
implementing
that
it
needs
to
be
applicable
to
developers
across
the
organization.
C
So
we
worked
with
them
to
ensure
that
these
tools
were
able
to
be
a
little
bit
more
generic
and
configurable,
not
just
to
the
teams
that
we
were
onboarding
but
to
get
to
the
github
enterprise
users
at
Salesforce
as
a
whole.
This
brings
me
to
the
final
group
that
I
had
the
privilege
of
working
with
the
most,
that
is,
the
migration
delivery
team.
This
services
team
that
vamsi
and
veikkaus
led
up,
and
it
was
a
wonderful
experience.
C
You
know
we
were
able
to
work
hand
in
hand
with
me
being
able
to
provide
some
github
expertise
as
well
as
some
lessons
learned
from
other
companies
across
the
globe
and
their
great
knowledge
and
expertise
with
regard
to
you
know
the
requirements
for
working
with
Salesforce
comm
as
well.
As
you
know,
internal
cultural
needs,
and
you
know
all
of
the
requirements
from
the
many
stakeholders
that
they
had,
and
you
know,
there's
these
very
large-scale
implementations.
C
B
Thank
you
Michael,
and
here
is
a
snapshot
of
some
metrics.
What
we
achieved
out
of
this
migration,
the
numbers
that
you
see
up
on
the
screen
are
probably
like
about
six
to
eight
months
old,
but
today
we
are
now
around
like
80
scrum
teams,
sitting
in
410
plus
repositories
and
the
members
around
across
all
this
repositories.
B
B
So
one
of
the
one
of
the
tooling
that
was
developed
by
one
of
the
team
at
in
our
department
was
that
they
were
able
to
actually
reduce
the
time
required
to
update
these
metadata
version
numbers
for
the
across
the
entire
code
base
from
a
span
of
about
40
days
to
three
days,
and
the
reason
for
that
is
in
the
legacy
system.
We
had
a
lot
of
complexity
around
the
aspect
of
creating
branch
and
shipping.
B
You
know
the
deployments
into
the
production
and
other
controlled
environments
and
that
that
has
helped
us
to
reduce
the
you
know,
time
required
to
perform
a
deployment
from
4x
to
15
X
and
that's
a
significant
one
win
for
all
of
us,
and
that
also
led
us
to
some
sort
of
you
know
aspects
where
you
know
we
were
able
to
read
use
the
boundaries
between
different.
You
know
parts
of
the
organization
specifically
between
the
development,
development
and
operations,
and
that's
that's
a
huge
win
for
us
all.
B
This
boiled
down
to
a
theme
that
we
kind
of,
like
you,
know,
put
into
a
bubble
called
you
know
autonomy
and
that's
the
biggest
one
big
biggest
win
for
all
of
us
is
to
you
know,
reduce
their
dependency
on
the
cross-functional
teams,
as
Michael
mentioned
earlier.
One
of
the
key
features
that
is
offered
by
professional
services
team
is
cultural
transformation,
and
we
did
see
we
do
see
that
thing
happening
in
terms
of
you
know
embracing
aspects
around.
B
C
A
A
So
I
think
Vamshi
just
touch
base
some
of
the
examples
here.
So
the
reason
we
migrate,
we
were
not
able
to
get
the
agility
which
we
were
looking
for
from
the
perforce.
It
didn't
had
the
API
based
infrastructure,
where
we
can
write
tools
on
top
of
perforce
to
have
the
tools
like
he
was
giving
you
the
example
of,
like
partial
delivery,
enforce
comm.
So
before
we
had
this,
it
was
taking
couple
of
hours
like
40
hours
to
do
that
delivery.
A
A
A
A
Sure
so
fools
calm
today
is
actually
a
big
monolithic
piece
of
software
and
we
are
in
the
process
of
migrating
the
whole
core
into
micro
services.
That's
happening
right
now,
but
today,
if
you
have
a
force.com
deployment,
it's
actually
the
whole
org
get
deployed
as
a
single
girl.
Having
said
that,
we
had
the
teams
which
were
using
Java,
no
Joe
s
and
they
did
have
their
own
micro
services.
A
Also,
so
one
principle
which
we
touch
base
a
little
bit
in
the
presentation,
was
to
have
it's
simple:
have
it
open
so
we
decide
to
have
a
single
org
for
the
whole
base
tech
technology.
So
anybody
who
want
to
look
at
each
of
the
repo
they
want
to
contribute.
They
can
easily
do
that.
So
to
answer
question:
yes,
we
had
a
combination
of
micro
services
as
well
as
the
the
big
pieces.
B
So
I
think
the
question
was:
what
were
the
challenges
took
heed
these
three
hundred
different
plus
repositories
in
sync,
and
the
answer
to
that
is
multifold
a
at
any
given
point
of
time
I
as
an
end-user
as
a
developer,
I
am
NOT
working
on
all
these
three
hundred
plus
different
repositories.
I
am
probably
focused
on
you
know,
primarily
on
my
prime
services
that
I
contribute
to
and
tertiary
services
that
I
have
dependencies
to.
B
So
the
question
was
more
about
once
this
sink
happens.
How
would
we
validate
it?
This
is
more
to
do
with
the
aspect
of
how
the
rapport
naming
conventions
are
framed.
Reading
it
well
into
a
lot
of
those
details
here,
but
imagine
you
had
some.
You
know
pre
pre
text,
notion
of
having
some
naming
conventions
to
your
repos
branches,
so
on
and
so
forth,
and
the
tool
that
we
have
created
to
do.
B
The
sync
is
going
to
focus
on
those
things
that
you're
interested
in,
like
let's
say,
I'm
interested
in
regular
expression,
XYZ
right,
it's
only
going
to
focus
on
those
things
and
stream
those
changes
and
with
regards
with
validation,
we
haven't
run
into
any
such
challenges
so
far,
yeah.
Thank
you.
You.
C
I
can't
speak
too
much
for
Salesforce
in
terms
of
their
open
sourcing
policies.
We
actually
provide
a
lot
of
you
know,
services
associated
with
that
as
well.
There
are
some
like
platform
samples
for
posit
or
E's
that
do
have
some,
you
know
are
kind
of
already
open
source
pieces
for
those
kinds
of
things
it
I
can
definitely
talk
with
you
offline.
As
far
as
some
details
on
that
for.
A
Salesforce
we
do
have
concept
of
supporting
the
open
source
community
as
part
of
our
team.
We
have
already
open
source
something
called
epics
unit,
which
is
the
unit
testing
tool
for
testing
the
force.com
classes,
and
if
these
tools,
also,
if
we
see
a
big
I,
think
need
definitely
we'll
be
more
than
happy
to
discuss
that
also.
B
B
A
Yeah,
so
we
did
share
a
little
bit
of
our
rollout
strategy.
The
biggest
thing
which
helped
us
I
think
is
to
have
to
do
as
much
planning
as
you
can
do
and
then
make
it
very
clear
to
the
partners.
Things
like
how
the
rollout
will
look
like
third
principle,
which
we
shared
was
to
make
it
easy
to
make
it
like
to
reduce
the
friction.
For
example,
we
started
with
very
small
and
less
critical
pieces
in
the
pilot.
Then
we
moved
to
r1
r2
r3
releases.
A
Again,
the
complexity
was
increasing
slowly,
so
we
try
to
do
the
easy
piece
first,
which
I
do
the
less
critical,
less
complex
pieces.
First
and
whatever
lesson
we
were
learning
there
and
we
were
applying
those
into
the
validating
that
everything
is
working
fine
into
the
later
releases.
So
that's
how
I
think
that's
very
helpful
for
us
yeah.
B
And
to
add
to
that,
within
each
release
we
had
multiple
waves
restraints
and
end-users
had
the
autonomy
to
choose
which
train
they
wanted
to
pop
on,
and
specifically
the
dry
runs
were
really
super
useful
for
them
to.
You
know,
go
test
the
waters,
and
specifically,
if
say,
you
have
some
CI
CD
scripts
that
are
pointing
to
your
oldest
instance
that
you
didn't
envision
to
have
that
abstraction
built-in
right.