Deployment flow at Docplanner
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.
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.
- 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.
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.
During the writing of this story, I just noticed that the reasons for having staging in the form that we have today are even less valid than before. COVID-19 changed everything! Stay tuned, I will make an update about upcoming changes!
In the meantime, if you want to know more details on how we deploy stuff, check it out!
