Docker at bamboo

Docker is a way of life here at bamboo. Docker is used for development, testing and for staging and production deployment. This post will discuss on how Docker has had an impact on the SDLC at bamboo.

Design Freedom

When designing microservices, one of the constraints that has bothered me in the past was the cost. Even when a functionality was to be ideally partitioned into a separate microservice, just the cost of running a HA cluster for that service would make me think twice. Docker solved this elegantly. It helped us deploy microservices in existing clusters with available capacity, without compromising on HA. A detailed post on this will be covered in future.

Coding Freedom

One of the things I have struggled in the past when joining new teams has been setting up the coding environment. Questions that I typically have:

1. What version of programming language do I use?
2. What are the dependent services that I need to install to make this work?
3. What is the version of DB / redis / memcache this code is compatible with?

At bamboo, we follow the practice of committing Dockerfile and docker-compose.yml in our microservices code repository. This defines the environment in which the code operates on, and helps programmers setting up the environment independently.

Testing Freedom

We use Go extensively for developing microservices. Integration tests at bamboo are placed as a Go sub-package “it” (it — stands for Integration Tests) inside the microservice code repository. Integration tests require the complete microservice environment up and running, with a clean DB and cache. Our CI builds bring up the environment using docker-compose up and then run the tests inside the it package to report failures. Once the tests are done, we bring down the environment using the docker-compose down -v.

Deployment Freedom

One of the common recurring problems that I used to face in the first decade of my career was the works for me problem. Developer writes the code, deploys in a new environment, and the code fails. Building consistent code that works across multiple environments as the code gets promoted, was a challenge. When using Docker, with the code runtime environment getting packed along with the code, this problem never occurs. The only consistency we have to ensure between environments is the version of the Docker engine.