Deployment flow at Docplanner
By: Łukasz Barulski
Tags: Deployment, Continous Deployment, Github, Staging, Production

In this story, I’m going to tell you a bit about how we deploy stuff at Docplanner. To have a full view of this process, you should know a few things about us.

Photo by Simon Abrams on Unsplash

What is Docplanner?

We want to make the healthcare experience more human. Each month, over 2 million users make appointments with the best specialists in their neighborhoods using our services.

Near to our users

To keep latency between our services and users at a reasonable level, we maintain Kubernetes clusters in 3 AWS regions: Frankfurt, Sao Paulo, and N. Virginia.

Applications

We have two main applications:

Marketplace — a platform where our users can find a specialist and make an appointment.

— a platform where our users can find a specialist and make an appointment. SaaS — a place of daily work for thousands of doctors and clinics.

Behind the scenes, over 60 applications support these two main players.

The majority of applications are deployed in each region where we operate but it depends on feature set of these country localized versions.

Deployment

Branching

We have two or three main branches in each repository:

develop — a place where developers merge their code

staging — a branch with the code to be deployed on a staging environment (optional)

master — a branch with the code to be deployed on production

Not all our applications need a staging environment; thus, a staging branch is optional.

Staging

For us, it’s an environment with separated instances of applications that use a newer version of code but still utilize the same instances of DB and other services (like ElasticSearch) as production —there are two versions of code using a common database.

Considering the above, all of our changes need to be backward compatible (DB migrations and so on…)

All of our offices use a staging version of the application for daily work.

Flow

To manage our flow on GitHub, we created a tool called GFM that moves commits from one branch to the other if given evaluation checks are passed.

Most of our applications have a similar deployment flow. Let’s take a look at one of them.

Sample deployment flow

We start at the moment when changes on a feature branch are finished, tests are passed, developers accepted a Pull Request, and someone merged those changes into a develop branch.

The very first thing to do is to run a broad set of tests. As soon as tests are passed, GFM pushes a given commit straight to a staging branch.

When a new commit faces a staging branch, it triggers deploy on a staging environment. Right after the changes are shipped, we run the next set of tests (end to end), but this time they check only the most important parts of our platform — just to be 100% sure that everything works in the environment that is most similar to production.

30 minutes after deploy to staging, if the staging tests are passed, GFM pushes commit to the master branch.

The push to the master branch triggers the deployment to production in all the regions that we operate in parallel.

Statistics

On average, we are performing 85 production deployments per day. Let’s take a look at stats for specific applications.

That’s execution time statistics for the production deployment pipeline of one of the biggest app that we have. As you can see, it takes 18 minutes on average — the following are included in this time:

uploading static files on S3

DBs migrations

rollout of over 200 containers (counted at the moment of writing)

For smaller apps, it takes usually 2–10 minutes — depending on application specifics.