Mojo CI/CD Pipeline
A pipeline that deployed branches of code to multiple envs
A GitLab CI/CD pipeline that allowed developers to deploy branches of code to multiple environments using only their mouse.
So...many...deployments
As an infrastructure engineer, I was tasked with deploying TMAC's products to a client's environment. This would be for both creating a new environment using AWS, or updating the code version.
There were many updates to the code that needed to be deployed, especially to the stage environments of the products. Because of this, I decided to work on a CI/CD pipeline which would enable developers the ability to deploy to the stage environment themselves.
Deploy on Commit/Merge
The original pipeline would deploy to the environment whenever a change was made to the stage branch. This enabled the developers to deploy the tickets they were working to the stage env so they were ready to be QA'd.
This was handy at the start to be added to all products, however this way of working wasn't ideal. Each product had multiple client envs as well as a stage and a demo env, which TMAC used for demos. For this way to work, each client would have needed their own branch as whenever there is an update, each env needs a full smoke test before deploying to another. And if there was an issue, there was no way to rollback to the stable version of code.
Because of this I had to come up with a more elegant solution and after some research I found it.
6 Clicks
The pipeline ended up being able to deploy to a client's env in just 6 clicks.
Using the GitLab environments, I was able to create variables that only applied to that env. I then created job templates like build and deploy. Then using the extends
and environment
I was able to create jobs specific to an env like build stage.
As there maybe multiple jobs to deploy to one env which relied on another job to be completed first, I used the needs
and dependencies
on the jobs to ensure they could only be run when necessary.
The pipeline would only run when manually triggered which could only be done by choosing a branch on CI/CD -> PIPELINES page and clicking run pipeline. Then you would click on which envs you wanted to deploy that branch of code to. And done.
Future Improvements
Unfortunately, I was made redundant at TMAC which meant I couldn't finish adding everything I wanted to add to the pipeline. If I were to have remained I would have worked on the following:
Unit/integration testing: This tests the code before deployment which would have saved QA a lot of time as it would catch the bugs before deploying the the environment.
Connected Projects: Projects tend to have a frontend and backend. I would have connected the 2 to ensure the frontend and backend were both on the same version of code.
Pulumi: Pulumi has full support for GitLab meaning I could've created the AWS infrastructure needed for a client deployment all through the CI/CD pipeline.
These would be great to work on when I next meet a SaaS company.