Environments
Environments are functionality that allows managing different deployment configurations at various stages of the software lifecycle. This feature enables:
- Maintaining deployment process consistency and repeatability
- Tracking which code is deployed where
- Rolling back to previous deployment versions if issues arise
- Protecting sensitive environments from changes or unauthorized launches by users without deployment rights
- Controlling deployment variables for each environment to maintain security boundaries
Each environment maintains a history of deployments. To redeploy, click the repeat button.
Environment Types
Environments can be static or dynamic.
Static Environment
- Typically reused for sequential deployments
- Have static names like
staging
orproduction
- 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.
In the gitflic-ci.yaml
file:
- Define a job with
stage: deploy
- 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:
- Define a job with
stage: deploy
- Specify these environment attributes:
- name (required): Recommended to use related CI/CD variables like
$CI_COMMIT_REF_NAME
. You can add static prefixes for UI grouping. - 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:
- In deployment job, specify stop job name in
on_stop
- In stop job, set
action: stop
and make it manual withwhen: 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.
Automatic Translation!
This page was automatically translated. The text may contain inaccuracies