Skip to main content

Deployment

The 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.

Using deployments​

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 a specific Pull Requests or branches​

To skip a specific Pull Request or branch using the $VORTEX_DEPLOY_SKIP variable, you would define additional environment variables with a specific naming convention in your continuous integration pipeline configuration.

Here's an example of how this can be done:

Skipping a specific Pull Request​

Suppose you want to skip the deployment for Pull Request number 42. You would set the following environment variable:

VORTEX_DEPLOY_SKIP_PR_42=1

Skipping a specific branch​

Suppose you want to skip the deployment for a branch named feature-x. You would first create a "safe" version of the branch name by replacing any special characters with underscores.

Set the following environment variable:

VORTEX_DEPLOY_SKIP_BRANCH_FEATURE_X=1