• Build and deployment variables
• Database variables
• Job-skipping variables
• Configure application secret variables
  • Kubernetes secrets
• Update application secrets
• Configure replica variables
  • Custom replica variables
• Deploy policy for staging and production environments
• Deploy policy for canary environments
• Incremental rollout to production
  • Example incremental rollout configurations
• Timed incremental rollout to production

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

{{< alert type=”warning” >}}

From GitLab 16.0, POSTGRES_ENABLED is no longer set by default.

{{< /alert >}}

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

Job-skipping variables

Use these variables to skip specific types of CI/CD jobs. When skipped, the CI/CD jobs don’t get created or run.

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.

Prerequisites:

• The variable value must be a single line.

To configure secret variables:

1. On the left sidebar, select Search or go to and find your project.
2. 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.

   {{< alert type=”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.

   {{< /alert >}}

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

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

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

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

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

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

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.