For close to a year, a large portion of our repositories on GitHub have been using a fast-forward-only master branch that is guaranteed to be green (all CI tests have passed) and that is guaranteed to have only Pull Request (reviewed) code in it. Developers fire-and-forget a Slack slash command that squashes their commits, runs all tests, merges their Pull Requests, and cleans up their Git branch. This is the story of how we got there.
The Strava mobile clients and website render millions of map images every day to provide geographic context to activities, routes, segments, and more. [We use and love Mapbox](http://labs.strava.com/blog/tailoring-maps-strava-athletes/) for our interactive maps on the web, but because of our high volume of requests, we came to a point where it was more economical to build our own static map service.
Over the past few years at Strava, server side development has rapidly transitioned from our monolithic Ruby on Rails app (The Monorail) to a service oriented architecture with services written in Scala, Ruby, and golang. This post describes how we use Mesos, Marathon, and Docker to deploy nearly 100 different services in an efficient and reliable way.
These days a common bottleneck in execution time is the network. It simply takes a long time to make the round trip (several milliseconds, versus a 100th of that to process the result). So, if you're doing multiple network requests, it makes sense to do them in parallel to reduce the overall latency. Futures/promises are a technique to accomplish this.
What we all know and love about Strava is running on a mostly Rails code base. However, as we've grown we've slowly been moving to a more service-oriented architecture. Almost all new features are being implemented as their own service and a few existing features, like the feed, have also been migrated. Most of these services are written in Scala and use Finagle/Thrift for their RPC communication layer. A growing number of services are starting to use Go and it's becoming necessary to cross communicate. A big hurdle in this process has been service discovery, i.e. how clients determine the IP and port for a service that can exist on multiple hosts.