Skip to main content

Deployment

Deployment to a remote location is performed by the scripts/vortex/deploy.sh router script.

The script runs in continuous integration pipeline only after all tests pass.

The script deploys the code to a remote location by calling the relevant scripts based on the type of deployment defined in $VORTEX_DEPLOY_TYPES variable as a comma-separated list of one or multiple supported deployment types:

  • webhook - a webhook URL is called via CURL.
  • artifact - a code artifact is created and sent to a remote repository.
  • lagoon - a Lagoon's webhook URL is called via CURL to trigger a deployment in Lagoon.
  • docker - a container image is built and pushed to a remote registry.
Expand to see deployment in the complete code lifecycle

Deployment targets​

Deployment targets can be branches and pull requests. These targets are defined in the CI configuration files and the hosting platform.

By default, deployments are triggered when commits are pushed into the following branches:

  • production
  • main
  • master
  • develop
  • release/**
  • hotfix/**
  • project/**

This will run the deployment script to forward the code to the remote hosting platform and tell it to use the current branch's code for the deployment.

When a pull request is raised against one of the branches above, a deployment will run for the pull request's branch. Depending on the hosting platform, this may create a temporary environment for the pull request with the name of the pull request.

Note that feature/* or bugfix/* (or any other branches) branches are not included in the default list of deployment targets. This is to prevent deployments from branches that are typically short-lived and have a pull request raised, which will trigger a deployment. Adding these branches to the list of deployment targets will lead to duplicated CI runs and deployments.

project/* branches are long-lived branches that are typically used for larger features or projects that may span multiple pull requests. Such branches would be manually synced with the develop branch and deployed to a remote environment for testing. An example of this would be a migration branch that has migration code and configuration that is not yet ready to be merged into develop but needs to be deployed to a remote environment for testing.

Deployment action​

By default, an existing database will be retained during a deployment.

To change this behavior and overwrite the database with a fresh copy from production environment, set the $VORTEX_DEPLOY_ACTION variable to deploy_override_db.

Skipping all deployments​

You can skip all deployments by setting the VORTEX_DEPLOY_SKIP environment variable to 1.

This is especially useful in continuous integration pipelines where you may want to build and test without triggering a deployment.

Skipping deployments for specific pull requests or branches​

To skip specific Pull Requests or branches, set $VORTEX_DEPLOY_ALLOW_SKIP to 1 and provide lists in the following variables:

Skipping specific pull requests​

Set $VORTEX_DEPLOY_SKIP_PRS to a single PR number or comma-separated list:

# Skip a single PR
VORTEX_DEPLOY_ALLOW_SKIP=1
VORTEX_DEPLOY_SKIP_PRS=42

# Skip multiple PRs
VORTEX_DEPLOY_ALLOW_SKIP=1
VORTEX_DEPLOY_SKIP_PRS=42,123,456

Skipping specific branches​

Set $VORTEX_DEPLOY_SKIP_BRANCHES to a single branch name or comma-separated list:

# Skip a single branch
VORTEX_DEPLOY_ALLOW_SKIP=1
VORTEX_DEPLOY_SKIP_BRANCHES=feature/test

# Skip multiple branches
VORTEX_DEPLOY_ALLOW_SKIP=1
VORTEX_DEPLOY_SKIP_BRANCHES=feature/test,hotfix/urgent,project/experimental

Combined usage​

You can use both variables together:

VORTEX_DEPLOY_ALLOW_SKIP=1
VORTEX_DEPLOY_SKIP_PRS=42,123
VORTEX_DEPLOY_SKIP_BRANCHES=feature/test,hotfix/urgent