How I Reduced Deployment Pain With Trunk Based Development Pipeline On Gitlab
We develop a lot of features and deploy them to the production environment everyday. We do not want to lose much time for the deployment and do not want to have any deployment pain. These are the important points. In this post, I will try to explain my experience with the actions I took to reduce the deployment pain in my team. For the confidentiality concerns, I am not sharing the whole pipeline structure that I created but I am explaining and simulating it with the examples.
Special thanks to book Accelerate. It gave me a different perspective on this way. Also so many thanks to Yavuz Hatip who is my team leader.
We use Gitlab for CI-CD. There were one branch for every single environment before my work. In other words, we have more than one environment so we had more than one branch. If we wanted to deploy a code to an environment, we had to merge our feature branch to the branch of that environment and trigger new Gitlab pipeline automatically for the branch of environment.
Every pipelines have a lot of stages so a lot of jobs to run before deploying process. For example; build, code analysis, coverage calculation, security analysis, UAT, automation tests etc.
How did I start?
I determined the problems that we had when we deploy code to the environments. First and main problem was that, we had to run a lot of jobs as I said above when we want to deploy our code to every single environment. So, for every merge processes, we had to wait all these jobs to finish successfully on the pipeline before the deployment job. Wasting time.
I had to prepare a new pipeline on Gitlab. My goal was to work on one branch instead of multiple branches. In this way, I would merge my code to only one main branch and all the jobs would run once in a row. While doing this, I aimed to switch to the Trunk-Based Development model instead of Git Flow. Because we work in small batches and we deploy them frequently. Trunk-Based Development was more suitable for us.
Firstly, I created a base yml file as a new pipeline structure. I added all the jobs from old pipeline files and I did every job runnable only on main branch. You can do this “rules” or “only” keyword in your yml file. For more information about Gitlab rules and only keyword you may check here.
The second problem was some repository pipelines need some specific jobs and some do not need. I do not want to push them to extend these jobs. So, I did every job hidden. So, if a repo does not need a job, it does not extend it. If a repo needs a job, it simply extends the hidden job in own .gitlab-ci.yml that includes my base yml. For example, first two lines of one of my jobs:
If I need this hidden job in my repo I just extend this job on .gitlab-ci.yml of the repo that include my base yml:
The third problem was with the current pipeline structure. If I wanted to add a brand new job and I want to use it all of repository pipeline, I had to extend it in each repo one by one. So, I decided to do this job visible (not hidden) on my base yml file. So every repository pipelines could use this job without doing anything. For example security stage is like that in base pipeline yml file and usable for every pipeline that includes this base pipeline yml:
Now we have a new base pipeline file and if we include it in a .gitlab-ci.yml in a repo, we just need to extend hidden jobs that we want to use. Common jobs that are not hidden will already be in your pipeline.
Structure of the base pipeline:
Our projects that include this base yml have a trunk based development pipeline.
Before my work, a pipeline was running 5–6 minutes for just one deployment to one environment:
Can you imagine that we were waiting this pipeline for every deploy to the every branches/environments.
Now the whole duration to deploy prod environment with the new trunk-based pipeline:
In conclusion, our new pipeline provides us efficiency and reduces the deployment pain, does not waste our time and useful for our short-lived branches. It affected our lead time downwards.
Sources that I used mostly:
Thank you for reading and feedbacks are always welcome.
Elif
