Skip to content

Environments


Environments are functionality that allows managing different deployment configurations at various stages of the software lifecycle. This feature enables:

  1. Maintaining deployment process consistency and repeatability
  2. Tracking which code is deployed where
  3. Rolling back to previous deployment versions if issues arise
  4. Protecting sensitive environments from changes or unauthorized launches by users without deployment rights
  5. Controlling deployment variables for each environment to maintain security boundaries

Environments

Each environment maintains a history of deployments. To redeploy, click the repeat button.

Deployments

Environment Types

Environments can be static or dynamic.

Static Environment

  • Typically reused for sequential deployments
  • Have static names like staging or production
  • Created manually or as part of CI/CD pipelines

Creating Static Environments

Static environments can be created using the UI or gitflic-ci.yaml file.

Creating Environment

In the gitflic-ci.yaml file:

  1. Define a job with stage: deploy
  2. Specify the environment name and URL in the job. If the environment doesn't exist when the pipeline runs, it will be created.

Example for creating a staging environment with URL https://staging.example.com:

deploy_staging:
  stage: deploy
  script:
    - echo "Deploying to staging environment"
  environment:
    name: staging
    url: https://staging.example.com

Dynamic Environment

  • Typically created in CI/CD pipelines and used for single deployments before being stopped or removed
  • Have dynamic names, usually based on CI/CD variable values

Creating Dynamic Environments

To create dynamic environments, use unique CI/CD variables.

In the gitflic-ci.yaml file:

  1. Define a job with stage: deploy
  2. Specify these environment attributes:
  3. name (required): Recommended to use related CI/CD variables like $CI_COMMIT_REF_NAME. You can add static prefixes for UI grouping.
  4. url (optional): Add CI/CD variable prefixes to hostnames like $CI_ENVIRONMENT_SLUG.

Example where deploy_review job creates unique environment names and URLs:

deploy_review:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com

Environment States

Environments can be in one of three states depending on stop job execution:

  • available: Environment exists, may have deployments
  • stopping: Stop job (on_stop) is running (only if stop job is defined)
  • stopped: Either stop job completed or user manually stopped environment

Environment Deployment Tier

If environment names don't reflect their purpose, use deployment_tier to specify the appropriate level:

Possible values: - production - staging - testing - development - other (default)

Stopping Environments

Stopping an environment makes its deployments unavailable on target servers.

Environments must be stopped before deletion.

Stop via UI button or define stop jobs in CI/CD:

  1. In deployment job, specify stop job name in on_stop
  2. In stop job, set action: stop and make it manual with when: manual

Example:

build:
  stage: build
  script:
    - echo "Building the app"
  environment:
    name: staging
    on_stop: stop-job

stop-job:
  stage: build
  when: manual
  script:
    - echo "Stop the app"
  environment:
    name: staging
    action: stop    

Stopping Merge Request Environments

Environments created by merge request jobs (like in merge result pipelines) automatically stop when the merge request completes, closes, or cancels.

Deleting Environments

Deleting an environment removes all associated deployments.

Delete via UI button on the stopped environments tab.

Environment Access for Preparation/Verification

Define jobs that access environments for purposes like verification or preparation without creating deployments.

Set these environment actions: - action: prepare - action: verify - action: access

Example:

build:
  stage: build
  script:
    - echo "Building the app"
  environment:
    name: staging
    action: prepare
    url: https://staging.example.com
    deployment_tier: staging

CI/CD Variables for Environments

By default, CI/CD variables are available to all pipeline jobs.

You can: - Restrict variable visibility to specific environments - Set different variable values for different environments

Configuration steps: 1. Go to project/team/company 2. Navigate to Settings -> CI/CD Settings 3. For new variables: - Enter variable key - Enter variable value - Specify target environment name 4. Save changes

Predefined CI/CD Environment Variables

When using environment in CI/CD, these predefined variables become available:

Variable Name Description
CI_ENVIRONMENT_NAME Current job's environment name (requires environment:name)
CI_ENVIRONMENT_SLUG Simplified name for DNS/URLs/Kubernetes (24 char max + random suffix)
CI_ENVIRONMENT_URL Environment URL (requires environment:url)
CI_ENVIRONMENT_ACTION Current job's environment:action value
CI_ENVIRONMENT_TIER Deployment tier from environment:deployment_tier

Protected Environments

Enterprise feature, also available on gitflic.ru

Protect sensitive environments by restricting deployment permissions.

Configuration: 1. Go to project 2. Navigate to Settings 3. Select Environment Protection 4. Enter environment name or wildcard pattern 5. Set deployment permissions: - Nobody - Admins + Developers - Admins Only 6. Click Enable Protection

Protected environments are visible on this page.

Protected Environments

Automatic Translation!

This page was automatically translated. The text may contain inaccuracies