Serverless Build Server

As a veteran build release engineer, I’ve rethought a lot of assumptions about Continuous Delivery over the years. Probably the most profound paradigm shift I’ve had recently is the notion of a build server. I’ve always maintained that Jenkins is the ultimate Swiss Army knife for Continuous Delivery, and I think that still holds true. I find myself asking however, when do I actually need a Swiss army knife? I’ve watched several build services vie for exposure, but what really struck home for me was when Travis adopted docker and dependency caching into it’s service. That was the day everything changed. Dedicated build services don’t go down, need maintenance, or allow for overly ambitious developers to shell into a server and wreck things. Jenkins itself isn’t the culprit, organizations are. I’ve come to realize a few truths

  • If you are running a series of dedicated build servers in house, you are doing it wrong
  • If you allow developers shell access into said servers, you are doing it wrong
  • If you don’t have regularly scheduled maintenance windows for said servers, you are doing it wrong
  • If you don’t have an automated disaster recovery plan to rebuild these servers, find new work

The last 3 are just mitigation tactics to partially solve the first bullet item. Realistically, we are beyond the need to run Continuously Delivery servers. What? How? Why?

The why should be obvious if you’ve got any experience dealing with microservice teams in a development shop, I won’t explain that one. How? Docker. Every Jenkins service can be run locally and work the same as a centralized server. The only difference is that maintenance is on the person that breaks the service. Any developer that needs the flexibility of Jenkins should be self hosting it on their laptop with a docker build workspace. Anything can cross compile to Linux, anywhere, thanks to build containers. The build server is obsolete. What we are after is build as a service. Jenkins as a build service works best when everyone has their own. Centralized CD has it’s place too, but it should be serverless. I mean serverless in the sense of an abstracted service, but hey, [why not] (https://github.com/lambci/lambci) go “serverless” as well.