►
Description
Presented by Kashyap Parikh, Amit Mishra, and Daniel Martinez, of Credit Karma.
We will discuss how GitHub and self service continuous integration (CI) helps Credit Karma rapidly deliver new features to over 60 million members. We will review how Credit Karma streamlined and scaled growing CI needs stemming from an army of engineers decomposing monolith into services.
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
Hi
everyone
thanks
for
joining
I'm
Kashyap
and
we
are
from
Credit
Karma.
We
are
very
excited
to
take
you
through
our
journey
of
building
a
self-service,
micro-services
CI,
why
we
are
using
github
and
how
it
has
helped
us
scale
and
rapidly
deliver
products
for
our
members,
but
before
I
start
with
the
journey.
Let
me
take
a
brief
moment
to
give
a
plug
for
my
employer.
A
Credit
Karma
kurama's
mission
is
to
make
financial
progress
possible
for
everyone,
and
we
know
that
thinking
about
financing
can
be
frustrating
at
times
and
that's
why
we
are
working
hard
to
make
the
process
simpler
and
easier
for
more
than
75
million
members.
I
lead
engineering
efficiency
team
at
Credit
Karma
and
my
team's
primary
focus
is
to
improve
developer
experience
through
test
production
and
development
lifecycle,
hi.
B
C
B
So
in
the
next
40
minutes,
we
will
take
you
to
the
journey
a
journey
into
our
universe,
on
how
we
evolve
our
CI
ecosystem.
This
slide
pretty
much
gives
the
agenda.
I
will
briefly
touch
over
our
history
on
how
we
started
and
what
we
are
today
and
then
we'll
go
over
the
services
part
like
how
self-service
has
improved
and
empowered
our
CI
systems
at
Credit
Karma
and
then
we'll
touch
base
over
what
is
github.
Why
did
we
choose
github
route
and
how
is
it
making
a
big
impact
on
the
way
we
develop
our
CI
ecosystem?
B
Then
Kashyap
is
going
to
go
over
the
docker
pipeline
about
it's
going
to
showcase
how
our
Security's
been
embedded
into
our
daughter
pipeline
and
how
we
are
actually
pushing
services
from
co-op
into
production
are
using
the
stoker
pipeline
and
after
that,
we'll
touch
base
on
the
future
part
on.
What's
our
future,
look
like
so
pretty
much,
this
is
our
agenda,
and
are
you
guys
ready
to
see
how
our
universe?
C
So
before
we
start,
let
me
tell
you
a
little
bit
of
our
history,
but
for
that
we
need
to
go
back
to
the
beginning
back
to
when
Credit
Karma
was
just
a
cloud
of
gas
back,
then
it
wasn't
known
if
we
will
take
form
into
anything
or
if
we
will
you
or
if
we
will
just
float
into
space
locally.
Credit
Karma
became
a
beautiful
galaxy
and
also
a
very
successful
company.
But
of
course,
as
we
grew,
our
mono
became
a
black
hole.
No
one
really
knew
what
happened
in
its
center.
C
We
just
knew
that
it
was
there.
So
as
time
passed,
we
knew
that
it
was
time
to
start
decomposing,
mono
and
the
first
micro-services
appear
back.
Then
we
had
a
single
CI
instance
that
had
a
lot
of
limitations
and
that
was
getting
out
of
control
partially
because
I
made
will
break
it
all
the
time,
but
mainly
because
we
kept
adding
many
many
jobs
and
eventually
we
needed
to
give
access
to
everyone
because
they
needed
to
be
able
to
manage
their
dependencies,
and
you
guys
know
what
happens
when
everyone
has
access
to
critical
systems.
C
Things
will
break,
as
you
guys
know,
CI
everything
revolves
around
CI,
so
we
took
a
look
at
the
newly
created
micro
services,
the
PHP
services
Scala
type
scripts,
and
we
noticed
that
there
was
a
pattern.
The
release
pipeline
was
almost
the
same,
so
we
knew
that
we
could
make
CI
a
configuration
and
setup
easier
and
faster
and
we
could
help
those
teams
be
more
sold
service
and
we
could
empower
them
through
CI,
so
that
was
a
little
for
history.
Now,
let's
talk
about
soul
service,
as
you
guys
know,
we
humans
don't
like
to
wait.
C
We
want
a
everything
to
be
done
right
away.
So
for
that
reason,
I
created
what
we
call
the
CI
builder
and
they
see
what
it.
What
the
sale
builder
is.
It's
a
Jenkins
instance
integrated
with
some
tools
like
tariffs
on
docker,
AWS,
artifactory
and
the
CI
builder
enables
teams
to
easily
create
they've
already
configuring
this
and
set
up
CI
instance
for
their
service,
so
like
I
mentioned
so
now,
let's
take
a
look
at
the
SE
builder
and
like
I
mentioned,
the
CI
builder
is
a
Jenkins
instance
that
creates
other
Jenkins
instances.
C
So
when
a
service
is
ready
to
start
testing
the
code
and
building
artifacts
that
they
will
eventually
push
to
production,
they
come
here
to
the
CI
builder
and
they
provide
some
information
to
us.
The
first
thing
that
we
need
to
know
is
the
team
name,
because
we
have
a
critic
ARMA.
We
have
some
nets
for
every
team,
so
we
need
to
know.
C
Where
are
we
going
to
be
deploying
the
infrastructure
to
the
next
very
important
Adam
is
the
docker
image
like
I
mentioned
before
we
already
know
how
our
Scalla
services
and
PHP
and
typescript
services
look
like
and
what
they
need.
So
we
created
some
templates
for
them
that
are
ready
to
be
used,
but
also
we
have
some
other
teams
at
Credit
Karma
that
like
to
highly
customized
their
jenkins,
and
for
that
reason
we
allow
them
to
provide
their
jenkins
image
to
us
and
we
deploy
that
for
them.
The
next
item
is
the
service
repo.
C
We
need
to
know
where
the
code
is
so
that
we
can
inject
that
into
the
template
that
we
are
providing
to
them
and
so
that
when
we
spin
this
instance
for
them,
we
can
start
cloning
and
pulling
and
pushing
their
code
to
github.
We
tell
the
developer
worrying
about
it,
and
the
last
item,
which
is
really
important,
is
the
instance
type.
The
user
has
access
to
modify
the
instance
type
like
I
mentioned.
C
On
the
first
stage
we
generate,
we
do
have
some
Ruby
scripts
that
we
use
to
generate
the
necessary
telephone
files
and
the
necessary
it
setup
scripts
to
deploy
during
structure.
On
the
second
stage,
we
use
styrofoam
to
deploy
it
infrastructure
with
the
scripts
that
we
created,
and
we
run
the
setup
scripts
to
provision
that
instance-
and
we
start
a
few
containers.
Of
course,
one
of
them
is
Jenkins
container
and
we
also
start
a
plum
container
for
login
and
some
other
containers.
C
So
now,
let's
look
at
the
benefits
before.
If
you
remember,
we
had
a
single
instance
that
was
getting
out
of
control
and
that
everyone
kept
asking
us
for
help
and
that
wasn't
available.
Now
this
process
is
more
scalable
as
we
grow.
We
can
create
more
inconsistencies
for
the
teams
rolling
out
and
roll
it
back
string
me
is
really
simple:
they
just
have
to
click
a
button
implementing
it
again.
C
The
user
juice
has
to
click
a
button.
They
don't
need
to
know
anything
about
AWS
or
the
factory
terraform,
not
even
Jenkins,
because
we
fully
configure
the
pipeline
and
Kashyap
will
talk
more
about
that
later
and
what
is
very
important.
They
have
full
access
to
their
Jenkins
instance.
They
don't
have
to
ask
them
it
for
help
anymore.
They
fully
own
it.
They
can
do
whatever
they
want.
So.
B
Clearly,
CI
builder
has
been
a
game
changer
for
us
when
it
comes
to
any
new
engineering
team
which
joins
great
karma
and
needs
a
new
CI
with
one
click
of
a
button.
They
have
their
CI,
which
is
up
and
running,
and
it's
fully
configurable
with
the
our
docker
pipeline.
So
now,
since
you
know
what
our
history
was,
how
we
started
what
is
self-service
CI,
it
means
to
us
let's
move
on
to
the
next
phase,
which
is
why
github?
Why
did
we
go
the
github
route?
So
to
answer
this
question,
it's
very
important
to
know.
B
First,
what
was
before
github
before
github
we
had
an
in-house
version
control
system
that
was
not
scalable.
It
was
running
on
a
lot
of
custom
plugins
and
you
know
what
happens
when
you
have
a
lot
of
custom.
Third
party
plugins
upgrades
can
be
nightmares.
We
ran
into
like
days
and
days
of
upgrade
issues
or
down
times,
and
it
was
not
very
intuitive
and
not
very
collaborative
so
github,
of
course,
came
as
a
the
obvious
solution
for
us
github.
B
It
comes
in
both
SAS
and
enterprise
flavors,
depending
on
what
your
needs
are,
how
you
want
to
host
it.
You
wanna
host
it
behind
your
firewall
enterprise,
the
way
to
go.
If
you
don't
worry,
if
you
don't
want
to
worry
about
the
underlying
infrastructure,
SAS
is
the
best
friend
it's
an
industry
standard
or
used,
or
millions
and
millions
of
users
all
over
the
world.
Github
has
now
become
the
standard
way
to
collaborate.
B
The
code
marketplace
comes
with
amazing
integrations
of
tooling
around
those
integration
can
basically
help
to
empower
your
workflow,
where
you
can
add
these
integrations
and
it
can
actually
make
your
CI
or
other
workflows
much
much
more
empowered
and
REST.
Api
is,
of
course,
of
the
biggest
advantages
where
you
can
have
rest
calls
done
and
make
tooling
around
rest
calls
again
to
help
your
CI
workflow
to
be
more
effective.
So
this
basically
goes
over.
Why
github?
B
Now?
How
have
you
used
github
to
do
some
of
the
status
checks
that
we
do
on
our
code
base?
So
let
us
list
some
of
the
status
checks
that
we
run
when
you
as
a
developer,
open
a
pull
request
at
Credit
Karma.
So
number
one
thing
is
the
approvers
and
I'm
sure.
Most
of
you
guys
are
very
familiar
with
this.
There
are
minimum
number
of
approvers
that
we
have
in
order
for
pull
request
to
be
approved.
You
can
set
this
count
to
whatever
you
want.
Whatever
your
needs
are
it's
highly
customizable.
B
There
are
some
underlying
tests
that
we
run
in
the
background
whenever
a
pull
request
is
created,
these
tests
are
integration,
test
unit
tests
and
I'm
gonna
show
that
in
next
slide,
where
a
screenshot
of
these
tests
how
they
are
executed
and
how
there
is
also
returned
back
to
the
pull
request
and
which
makes
sure
that
every
pull
request,
any
pull
request
does
not
break
the
test.
Suites
that
we
have
in
place
commit
messages.
This
is
this
another
check.
B
B
Oh
well,
we
don't
promote
those
commit
messages,
because
we
want
to
make
sure
that
when
we
do
a
production
release,
we
take
these
commit
messages
and
we
create
release
notes
out
of
it
and
those
release,
notes
are
should
be
very
meaningful
to
state
a
fact
that
what
went
out
in
release
what
about
the
works,
whatever
enhancements
so
do
our
commit
messages,
have
to
have
a
mandatory
active
JIRA
ticket
in
that
and
we
could
customize
that
commit
message
to
whatever
regular
expression
we
wanted
to
be
and
the
next
one
is.
The
owners
check.
B
B
So
that's
pretty
much
stating
making
sure
that
if
there
is
any,
if
you're,
not
an
SME
on
particular
domain-
and
you
would
have
to
work
on
a
story
where
you
are
touching
that
particular
file,
we
will
automatically
add
those
SMEs
as
part
of
the
approvers
in
your
pull
request.
So
these
were
some
of
the
status
checks
that
we
have
in
place.
The
next
slide
is
how
do
we
implement
those
statistics
like?
How
does
it
all
happen?
So
it
basically
happens
to
our
CI
ecosystems,
CI
ecosystem,
which
is
part
of
Web
books
on
every
repo.
B
So
whenever
you
create
a
pull
request,
the
web
hooks
on
that
particular
repo
gets
triggered
and
in
the
underlying
it
actually
triggers
a
Jenkins
jobs
in
the
background
which
run
all
these
checks.
So
let
us
look
at
a
screenshot
of
a
sample
pull
request
at
Credit
Karma,
and
it
actually
shows
you
all
the
checks
that
I've
talked
previously.
B
It
is
going
over
approval
count
and
then
some
of
the
unit
tests
that
we
run
there
a
couple
of
them
which
are
running
in
parallel,
making
sure
that
you
have
not
broken
the
test
suite
and
we
are
very
particular
about
that
stuff.
The
Golden
Gate
is
our
homegrown
utility,
where
we
don't
allow
end
users
to
merge
code
into
the
main
code
line.
B
Actually,
there
is
another
build
that
runs,
making
sure
that
it
merges
the
master
into
feature
branch,
making,
sure
there's
no
race
condition
and
we
run
the
test
again
and
that's
that
system
user
actually
merges
your
code
into
the
master
code
line
and
then
owners
check
is
something
that
I
talked
in
the
previous
file.
So
probably
this
PR
had
some
of
the
files
where
the
author
wanted
some
of
the
files
to
be
peer,
reviewed
by
an
SME.
B
So
next
thing
that
we
developed
using
the
rest
calls
and
hooks
part,
was
the
BOTS.
So
what
was
happening
before
BOTS
V?
Our
team
was
getting
flooded
with
requests
from
our
engineering
team.
Saying
hey
guys,
can
you
make
us
a
repo,
or
can
you
rename
a
saw
repo
or
how
do
I
list
some
repose,
which
are
owned
by
a
particular
engineering
team?
So
these
were
all
very
manual
and
day-to-day
repetitive
tasks
and
we
wanted
to
focus
more
on
developing
tools
rather
than
fulfilling
these
day-to-day
manual
activities,
which
are
pretty
repetitive.
B
So
we
started
developing
our
chat
BOTS,
which
are
actually
helping
us
to
achieve
a
lot
of
these
features.
So
here
is
a
human
interaction
with
one
of
our
chat
BOTS
and
each
actually
tells
you
what
a
chat
bot
is
capable
of
doing
it
can
create
your
repo.
It
can
give
you
like
it
can
initialize
some
of
the
hooks
to
your
repos
if
you
can
search
repos
using
just
this
chat
board
and
bunch
of
other
stuff.
So,
as
you
can
see,
our
chat.
B
Bots
are
very
handy
when
it
comes
to
doing
repetitive
tasks
for
our
engineering
needs
on
day
to
day
basis.
So
let's
go
over
some
of
the
benefits
that
we
achieved
when
we
have
configured
the
hooks
and
the
bots.
So
let's
look
at
some
of
the
benefits
of
hooks.
First
hooks.
As
you
see,
we
have
bunch
of
tests
that
we
run
and
we
are
making
sure
at
every
point
of
time.
We
are
delivering
clean
code
into
our
main
code
line,
which
is
making
sure
clean
code
is
going
out
in
production
and
we
have
minimal
bugs.
B
The
next
thing
is
approvals.
We
are
making
sure
that
you
have
adequate
number
of
approvals
before
your
core
is
being
merged
into
the
main
code
line.
Specific
approval
is
a
direct
reflection
of
the
owners
check
that
I
discussed
previously,
making
sure
that,
if
you're
not
an
SME
on
something,
we
are
adding
those
people
as
your
approvers-
and
you
are
confident
enough
saying
all
right,
I'm
sure
this
stuff
is
not
gonna,
break
production
and
automated
merging
is
the
golden
gate
part
that
I
discussed
earlier.
No
humans
are
allowed
to
merge
code
directly
into
master
code
line.
B
We
have
automated
processes
which
actually
merge
this
code
into
the
main
core
line.
Now,
let's
talk
about
some
of
the
benefits
of
the
bots
security,
whatever
we
do
at
Credit,
Karma
security
is
our
number
one
priority
so
to
create
repos
or
to
other
tasks
with
stuff
bots.
Make
sure
that
it
comes
in
built,
so
it's
it's
a
way.
We
then
abort
creates
our
repo.
We
are
pretty
much
sure
that
it's
creating
it
with
all
the
security
protocols
that
we
have
programmed
it
to
do
it.
B
Information
retrieving
information
from
a
bot
is
just
chatting
in
a
slack
basically
chatting
with
the,
but
you
don't
have
to
go
to
github
UI
or
somebody's
new
to
UI.
He
or
she
can
actually
list
those
repos
by
just
chatting
on
to
you,
no
slack
messages
and
getting
the
information,
and
it
pretty
much
allows
us
to
standardize
the
way
we
create
our
repos,
the
wavy
name
repos,
so
that
it's
very
easy
to
search
for
repos
in
your
under
your
old
name.
B
If
the
repos
are
named
in
a
very
funny
name,
it's
it
kind
of
becomes
tough
to
go
over
what
repos,
where
which
Depot
makes
what
sense
so
bots
typically
helps
us
to
achieve
all
this
stuff
and
last,
but
not
the
least
bots
are
always
available.
They
don't
take
PTO
s,
they
don't
fall
sick.
We
three
are
presenting
here
and
our
bots
are
doing
stuff
at
great
karma.
A
A
A
Migrating
from
monolith
to
a
micro
service
is
not
easy
and
we
have
embarked
on
this
journey
about
a
year
and
a
half
ago.
It's
not
easy,
because
there
are
a
lot
of
advantages
using
mono
and
we
have
benefited
from
it
quite
a
bit
things
like
a
dummy
city
with
releases
deployments,
rollbacks
code,
refactor
and
reuse.
All
of
this
is
done
within
a
single
branch.
A
So,
in
order
to
break
away
from
monolith
into
microservices,
we
started
looking
into
building
microservices
and
started
looking
into
running
docker
in
production,
and
we
knew
that
we
had
to
build
these
docker
containers
securely
and
reliably
without
impacting
developer
productivity
and
agility
and
making
sure
that
a
docker
container
that's
running
in
production
can
be
traceable
back
to
become
it
in
github.
So,
in
order
to
meet
some
of
these
requirements,
we
decided
to
build
a
two-stage
docker
pipeline
docker
pipeline
that
will
securely
build
images
and
publish
them
in
production.
A
Let's
look
at
how
the
docker
pipeline
works,
so
the
pipeline
works
in
a
locked,
centralized,
Jenkins
environment.
This
locked
environment
is
triggered
by
a
remote
CI
instance.
This
is
a
team
CI
instance
that
Daniel
just
reviewed
this
instance
has
a
pre-configured
jobs
to
remotely
trigger
both
stages
of
this
pipeline,
and
the
first
stage
of
the
pipeline
is
building
a
bronze
image
and
it
typically
starts
with
cloning,
github
repo
for
a
service
or
or
a
tag
for
a
service.
A
Once
the
repo
is
clone
on
the
central
environment,
we
do
a
static,
scan
and
code
analysis
on
this.
If
the
static
scan
is
successful,
we
trigger
a
darker
build
and
the
docker
image
is
produced
using
this
bill
and
then
that
image
gets
statically
scanned
on
the
central
environment.
And
if
the
scanning
is
successful,
we
publish
this
dock
or
artifact
into
a
private
registry
inside
of
a
corporate
environment,
and
we
call
is
bronze
registry.
A
So
at
this
point
we
have
an
image
that
went
through
some
of
the
security
validations,
but
we
haven't
done
any
additional
validations
on
this.
So
we
pass
this
image
back
to
the
team
CI
to
run
additional
integration
tests
and
when
the
tests
are
successful,
we
are
ready
to
kick
off
the
second
stage
of
the
docker
pipeline
and
the
second
stage
also
runs
on
a
central
Jenkins
environment
and
we
call
it
gold
stage.
A
So
so
far
we
have
been
talking
about
CI
github,
how
to
build
docker
images,
mostly
CI
centric
world,
but
it
takes
a
lot
to
build
a
micro
service.
Typically,
a
developer
will
think
first
think
about
what
kind
of
frameworks
or
libraries
he
or
she
is
going
to
use.
How
is
the
application
they
are?
Building
is
going
to
be
monitored
in
production
and
how
is
going
to
be
deployed
in
production,
whether
they
need
a
single
instance.
A
So
we
started
here
with
the
darker
pipeline
and
we
started
when
we
started
stitching
together
the
service
provisioning
pipeline.
We
ended
up
here
and
let's
took
a
take,
a
look
at
briefly
how
these
pipeline
works.
It
starts
with
creating
a
service
repo
for
a
service
that
a
developer
is
building,
and
then
we
inject
the
working
skeleton
a
working
code,
whether
it's
framework
related
is
Scala
or
Java
or
PHP.
A
So
at
this
point
a
developer
or
a
team
can
actually
create
a
service
and
get
it
ready
to
run
through
the
docker
pipeline
and
then
finally
publish
this
into
production
environment.
This
entire
cycle
used
to
take
weeks
because
it
was
all
manual,
but
with
this
service
provisioning
pipeline
that
is
fully
automated.
It
takes
hours
so
developer
could
be
working
on
a
concept
in
the
morning
run
through
this
pipeline
in
the
afternoon
and
actually
prototype
and
deploy
the
application
in
production
for
our
members
to
use
same
day
in
the
evening.
A
This
is
an
example
workflow.
We
use
a
airflow
to
wire
up
all
the
service
provisioning
pipeline
and
some
of
the
tools
that
we
use
terraform.
Of
course
the
infrastructure
is
deployed
in
AWS
and
because
we
are
building
docker,
we
have
docker
eyes
the
entire
pipeline
as
well.
So
we
are
eating
our
own
dog
food
and
Jenkins
is
the
backend
engine
that
we
use
to
actually
execute
the
workflow.
A
So
let's
look
at
some
of
the
benefits
of
using
an
automated
service,
provisioning
and
docker
pipeline,
because
this
is
fully
self-service.
Developers
can
build
and
deploy
their
services
without
any
bottlenecks
with
the
central
Jenkins
environment
that
is
running
security
scans,
it's
very
flexible.
We
can
add
new
scans
when
they
are
available
without
impacting
developer
productivity
and
then
because
all
the
services
are
built
from
a
same
tool.
We
get
standardization
for
free
and
then
because
we
tagged
docker
images
using
getcha
and
Samer
version
of
the
services
and
s
re.
C
C
C
All
these
Jenkins
instances
are
producing
over
5,000
bills
every
day,
but
some
of
these
bills
are
running
actually
test
unit
areas.
Integration
tests
performing
tests,
many
other
tests,
and
they
are
also
creating
some
artifacts
and
Amit
will
tell
you
more
about
that,
and
thanks
to
the
integrations
that
I
made
mentioned,
we
are
producing
over
15,000
calls
to
and
from
github
on
a
regular
day.
And
lastly,
we
are
producing
over
200
docker
images,
but
like
Kashyap
mentioned,
nor
all
those
images
make
it
to
production.
B
B
So
when
it
comes
to
our
defector
instances,
we
have
multiple
artifactory
instances
which
we
have
implemented
in
our
Corp
and
production
networks
and
again
I'm
going
to
stress
out
on
the
security
factor
here
because
Security's
on
the
prime
of
what
we
do
at
Credit
Karma.
We
make
sure
there
are
certain
security
rules
which
actually,
which
actually
dictate
the
terms
on
how
artifacts
are
being
propagated
from
co-op
into
production
so
that
they
can
be
deployed.
Not
all
the
artifacts
have
to
be
in
production
because
they
did
not
pass
a
test
or
the
routine
application
scheme.
B
B
B
A
A
Kernel
panics
were
real
thing:
escalation
privileges
were
real
thing.
Fortunately,
docker
is
much
stable.
Now
and
as
you
as
you
add,
self-service
tools,
you
have
to
make
sure
that
you
are
able
to
scale
it
when
we
started
building
our
tools.
There
were
very
few
teams
were
using
these
tools,
but,
as
Daniel
mentioned,
we
have
over
150
Jenkins
instances
that
are
constantly
running
builds.
5K
builds
per
day.
We
have
to
make
sure
these
instances
are
always
backed
up.
A
A
So
we
are
looking
into
config
base,
CI
CI,
where
developers
produce
the
code
or
the
framework
on
which
they
want
to
run.
The
CI
and
the
actual
jobs
are
running
in
a
central
environment
tools
like
circle.
Ci
tools
like
jenkins
file
come
to
mind
and
we
are
prototyping
some
of
these,
and
we
are
hoping
that
we
can
come
next
year
and
present
how
these
are
config
by
CI
is
working
for
us.
I
feel
like
this
is
where
github
shines.
A
New
integrations
are
always
coming
along
things
like
branch
protections,
owners
files
and
we
are
constantly
looking
at
new
features
and
integrating
them
into
our
development
workflows.
Originally
github
is
a
really
nice
marketplace
where
third-party
tools
provide
an
easy
integration,
whether
it's
through
graph,
QL
or
restful
api's.
A
We
want
to
extend
the
reach
of
bots.
Bots
are
currently
providing
lot
of
cell
service
someday.
We
want
to
create
an
entire
service
and
deployed
in
production
using
bots,
of
course,
the
feature
of
code
development,
and
then
you
want
to
make
sure
our
tools
are
portable,
any
clouds.
Right
now
we
are
using
AWS,
but
because
the
underlying
tools
that
we
use
a
terraform
docker,
they
are
not
they're
cloud
agnostic.
So
hopefully
that
provides
this
opportunity
to
migrate
to
multiple
other
clouds
in
future.
B
So
before
we
wrap
up,
we
want
to
cover
a
one
last
point,
which
is
our
takeaways
and
that's
going
to
complete
our
constellation
here
as
well.
So
what
were
our
big
takeaways
when
we
were
developing
this
whole
ecosystem
and
we
wanted
to
share
some
of
our
learnings
with
you
guys,
so
it's
very
important
for
when
you
developing
a
system
like
this
smart
or
complicated
system
like
this.
The
first
question
you
need
to
answer
is:
what's
your
problem
like
what
problem
are
you
trying
to
solve?
B
Do
not
create
solutions
just
because
XYZ
company
implemented
some
cool
tools
or
we
can
implement
that
same
solution,
no
identify
the
problems
which
are
critical
to
your
business
and
then
find
a
solution
which
will
make
more
sense
in
your
domain
or
your
business.
So
that's
one
thing
that
was
one
of
our
biggest
takeaways
self
service
should
be
the
key
to
develop
any
service,
especially
in
an
environment.
B
When
you
know
it's
going
to
scale
up
very
high,
if
you
are
working
on
any
solution
which
is
not
going
to
scale
up-
and
it
is
it's-
it
has
to
scale
up-
and
it's
not
self
service
oriented,
it
will
be
a
problem.
It
will
become
a
big
problem
in
future.
So
all
our
all
our
services,
all
our
tools
that
we
have
developed
ourselves
service,
centric
based
continuous
integration,
should
be
at
the
heart
of
everything
you
guys
do
because
it
is.
B
It
helps
you
to
identify
and
I
trade
over
issues
at
the
very
early
stages
of
the
software
development
lifecycle
and
the
sooner
you
catch
them,
the
cheaper.
It
is
to
fix
them.
The
later
you
catch
them.
It
becomes
a
bigger
issue,
ins,
much
more
expensive,
with
engineering
hours
involved
in
fixing
those
issues
and
evolves.
Step-By-Step.
Do
not
plan
to
implement
the
whole
solution.
Intend,
of
course
it's
not
gonna
work
out.