12. EARLY DAYS
• Pure Java
• Moving fast, lots of C&P
• Lots of snowflakes and competing approaches
• Ant-based build installed via git submodule
• Capistrano for deployment
16. WHAT’S COOL ABOUT SBT
• Fast incremental builds of Scala & Java
• ~compile, ~test
• Interactive shell & console
• Configuration is “just” Scala code
17. BUT...
• Very sophisticated use of Scala
• Subtle mental model
• Can be hard to debug
• Lots of historical baggage in our build & deployment processes
18. GILT-SBT-BUILD
• One big SBT plugin pulling in all other plugins and
configuration
• Plugin is versioned just like any other software
• (Actually builds itself!)
• Super simple config for individual services
22. object
Build
extends
ClientServerCoreProject
{
val
name
=
"svc-‐persistent-‐session"
val
coreDeps
=
...
val
serverDeps
=
...
val
clientDeps
=
...
override
val
ioncannonTrack
=
IonCannon.FastTrack
}
24. CONTINUOUS DELIVERY
• At the granularity of released versions
• Too many commits and too many services to deploy every
commit
25. DEVELOPMENT
• Teams have a shared dev / test environment
• Develop locally w/ tunnels to services
• Submit to Gerrit for peer review
• Deploy & test on team environment
• ‘sbt release’ when ready
26. FAST-TRACK
• Fully automated testing & deployment
• ‘sbt release’ triggers deployment to a staging environment
mirroring production
• Automated tests run
• Promote to production or rollback
32. SLOW-TRACK IN PRACTICE
• Dramatically less adoption than fast-track
• Systems without good automated tests tend to be older
systems which also haven’t upgraded to the current build &
deploy toolchain
• Teams do manual testing on test environments already
• Better tools for UI testing tend to eliminate the need for this
33. SELENIUM:TEST
• ‘sbt selenium:test’
• Built on ScalaTest 2.0 Selenium DSL
• Automated browser testing with reusable components
• All tests written in Scala
• Tests can be run in any environment
• Selenium grid available
34. @Selenium
class
Example
extends
FlatSpecTestBase
with
Matchers
with
ConfigurableBrowser
with
LoggedTestUser
with
OnProductDetailPage
with
AvailableToPurchaseItem
with
InMens
with
CloseBrowserAfterAllTests
{
"A
size
chart"
should
"be
available"
in
{
//
test
goes
here
}
}
37. CURRENT DEPLOYMENT
• Bare metal machines
• Multiple services per machine
• Highly manual process to balance resource requirements
38. THE FUTURE
• Deploy to immutable LXC containers, one service per
container
• New versions deploy to fresh containers, old containers are
retired
• Services specify resource requirements, system finds available
capacity
39. CLOUDSTACK
• Private cloud management
• Also evaluated OpenStack & Ganeti
• CloudStack’s APIs seemed best suited to our design
• Added LXC support to CloudStack 4.2
41. DEPLOYMENT SEQUENCE
• svc-software-provisioning - create new container(s)
• install new version onto containers
• svc-loadbalancer - move traffic to new version
• svc-software-provisioning - delete old containers
42. SUMMARY
• Support rapid development of micro-services and micro-
applications via:
• Powerful & highly abstracted build system
• Continuous delivery & great tools for automated testing
• (Upcoming) Simple & consistent hardware provisioning
