CI/CD variables

Use CI/CD variables to set up the Auto DevOps domain, provide a custom Helm chart, or scale your application.

Build and deployment variables

Use these variables to customize and deploy your build.

Database variables

WARNING: The default value of true for POSTGRES_ENABLED was deprecated in GitLab 15.8. In GitLab 16.0, the default value will change to false.

Use these variables to integrate CI/CD with PostgreSQL databases.

Job-disabling variables

Use these variables to disable CI/CD jobs.

Configure application secret variables

Some deployed applications require access to secret variables. Auto DevOps detects CI/CD variables starting with K8S_SECRET_, and makes them available to the deployed application as environment variables.

Prerequisite:

• The variable value must be a single line.

To configure secret variables:

1. On the top bar, select Main menu > Projects and find your project.
2. On the left sidebar, select Settings > CI/CD.
3. Expand Variables.
4. Create a CI/CD variable with the prefix K8S_SECRET_. For example, you can create a variable called K8S_SECRET_RAILS_MASTER_KEY.
5. Run an Auto DevOps pipeline, either by manually creating a new pipeline or by pushing a code change to GitLab.

Kubernetes secrets

Auto DevOps pipelines use your application secret variables to populate a Kubernetes secret. This secret is unique per environment. When deploying your application, the secret is loaded as environment variables in the container running the application. For example, if you create a secret called K8S_SECRET_RAILS_MASTER_KEY, your Kubernetes secret might look like:

$ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml

apiVersion: v1
data:
  RAILS_MASTER_KEY: MTIzNC10ZXN0
kind: Secret
metadata:
  creationTimestamp: 2018-12-20T01:48:26Z
  name: production-secret
  namespace: minimal-ruby-app-54
  resourceVersion: "429422"
  selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret
  uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4
type: Opaque

Update application secrets

Environment variables are generally immutable in a Kubernetes pod. If you update an application secret and then manually create a new pipeline, running applications do not receive the updated secret.

To update application secrets, either:

• Push a code update to GitLab to force the Kubernetes deployment to recreate pods.
• Manually delete running pods to cause Kubernetes to create new pods with updated secrets.

Variables with multi-line values are not supported due to limitations with the Auto DevOps scripting environment.

Configure replica variables

Add replica variables when you want to scale your deployments:

1. Add a replica variable as a project CI/CD variable.

2. To scale your application, redeploy it.

   WARNING: Do not scale your application using Kubernetes directly. Helm might not detect the change, and subsequent deployments with Auto DevOps can undo your changes.

Custom replica variables

You can create custom replica variables with the format <TRACK>_<ENV>_REPLICAS:

• <TRACK> is the all-caps value of the track Kubernetes label set in the Helm Chart app definition. If track is not set, omit <TRACK> from the custom variable.
• <ENV> is the all-caps environment name of the deploy job set in .gitlab-ci.yml.

For example, if the environment is qa and the track is foo, create an environment variable called FOO_QA_REPLICAS:

QA testing:
  stage: deploy
  environment:
    name: qa
  script:
    - deploy foo

The track foo must be defined in the application's Helm chart. For example:

replicaCount: 1
image:
  repository: gitlab.example.com/group/project
  tag: stable
  pullPolicy: Always
  secrets:
    - name: gitlab-registry
application:
  track: foo
  tier: web
service:
  enabled: true
  name: web
  type: ClusterIP
  url: http://my.host.com/
  externalPort: 5000
  internalPort: 5000

Deploy policy for staging and production environments

Auto DevOps typically uses continuous deployment, and pushes automatically to the production environment whenever a new pipeline runs on the default branch. To deploy to production manually, you can use the STAGING_ENABLED CI/CD variable.

If you set STAGING_ENABLED, GitLab automatically deploys the application to a staging environment. When you're ready to deploy to production, GitLab creates a production_manual job.

You can also enable manual deployment in your project settings.

Deploy policy for canary environments (PREMIUM)

You can use a canary environment before deploying any changes to production.

If you set CANARY_ENABLED, GitLab creates two manual jobs:

• canary - Deploys the application to the canary environment.
• production_manual - Deploys the application to production.

Incremental rollout to production (PREMIUM)

Use an incremental rollout to continuously deploy your application, starting with only a few pods. You can increase the number of pods manually.

You can enable manual deployment in your project settings, or by setting INCREMENTAL_ROLLOUT_MODE to manual.

If you set INCREMENTAL_ROLLOUT_MODE to manual, GitLab creates four manual jobs:

1. rollout 10%
2. rollout 25%
3. rollout 50%
4. rollout 100%

The percentage is based on the REPLICAS CI/CD variable, and defines the number of pods used for deployment. For example, if the value is 10 and you run the 10% rollout job, your application is deployed to only one pod.

You can run the rollout jobs in any order. To scale down, rerun a lower percentage job.

After you run the rollout 100% job, you cannot scale down, and must roll back your deployment.

Example incremental rollout configurations

Without INCREMENTAL_ROLLOUT_MODE and without STAGING_ENABLED:

Without INCREMENTAL_ROLLOUT_MODE and with STAGING_ENABLED:

With INCREMENTAL_ROLLOUT_MODE set to manual and without STAGING_ENABLED:

With INCREMENTAL_ROLLOUT_MODE set to manual and with STAGING_ENABLED:

Timed incremental rollout to production (PREMIUM)

Use a timed incremental rollout to continuously deploy your application, starting with only a few pods.

You can enable timed incremental deployment in your project settings, or by setting the INCREMENTAL_ROLLOUT_MODE CI/CD variable to timed.

If you set INCREMENTAL_ROLLOUT_MODE to timed, GitLab creates four jobs:

1. timed rollout 10%
2. timed rollout 25%
3. timed rollout 50%
4. timed rollout 100%

There is a five-minute delay between jobs.