Auxiliary Deployments

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.

Setup

Let's say we have a simple application with frontend and backend containers. Let's call this app, simple-app. A new gitlab group would be created that would have both the frontend and backend as gitlab projects. This new gitlab group would be called something like simple-app-develop and let's say the branch we want triggering the deployment piece of the pipeline is called develop. These new gitlab projects would be pushed with push mirrors in the original projects using a keyword wildcard like develop* so that only certain 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 auxialiary 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 setup again with SAST tools (e.g. sonarqube, fortify, twistlock), and new pipelines, the team would incur new costs as we are basically setting up infrastructure for an entirely new application.

When the new sonarqube, fortify, and twistlock projects are set up, whatever is whitelisted at the time will carry over from the original projects. After that initial setup, teams will need to submit whitelisting for the mirrored deployment as if it's a separate application.

Note that, 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

You will have to reach out to BAMs (Business Account Manager) in order to pay for this. Once paid, you may submit a ticket .

When submitting the ticket you will need to come up with a name for your auxiliary deployment. It will follow this naming convention <original app name>-<aux deployment name>. E.g. helloworld-develop.

From there, you will need to list out which projects you will want mirrored over for the new auxiliary deployment.

Request for production deploy

Once you feel that you are ready to deploy your auxiliary deployment to production, put in a production deploy request .