Auxiliary Deployments
Overview
Product team project pipelines can only deploy one particular branch to staging/production by designating that branch of choice as their default branch. All other branches are cut short and do not execute deploy-staging, E2E/pen tests, and release.
This can pose issues for stability in production as a product team becomes more mature. After a team deploys to production, it is sometimes desired to create a development version (i.e., version 2) of their application while also maintaining their app in production (i.e., version 1).
With auxiliary deployments, teams can request to have another branch deploy to staging and production. This is accomplished by having a mirror push changes to another GitLab project. That GitLab project would then have a different default branch set, allowing the full pipeline to execute. This would be repeated on all the application's container pipelines to replicate another version of the app.
Read this document to understand setting up auxiliary deployments, their implications, and how to request an auxiliary deployment.
Setup
Example
We have a simple application with front-end and back-end containers. Let's call this app simple-app. A new GitLab group would be created that would have both the front-end and back-end as GitLab projects. This new GitLab group would be called something like simple-app-develop, and let's say the branch we want to trigger the deployment piece of the pipeline is called develop. These new GitLab projects would be pushed via push mirrors in the original projects, using a keyword wildcard like develop, so that only branches containing that keyword would be pushed.
We would then set the default branch on the develop branch in the mirrored project so that the full pipeline would trigger on that branch.
Implications
It's best to think of the auxiliary deployment as an entirely separate application, as they have the potential to diverge.
Since a new GitLab group and its associated projects would have to be set up again with new pipelines and associated scanning tools, the team would incur new costs as we are basically setting up infrastructure for an entirely new application.
INFO
The configuration will be put into place so that the original projects no longer run pipelines designated for the mirrored projects. This is to avoid intermingling SAST findings, which would have the potential to cause confusion.
Requesting an Auxiliary Deployment
Initial Request for Staging
Reach out to your BAM to pay for this. Once paid, submit an Auxiliary Staging Deployment request .
When submitting the request, you must include:
- A name for your auxiliary deployment that follows this naming convention
<original app name>-<aux deployment name>. E.g.,helloworld-develop. - A list of which projects you want mirrored for the new auxiliary deployment.
Request a Production Deploy
When you are ready to deploy your auxiliary deployment to production, submit a production deploy request .