Skip to main content

Continuous Integration/Deployment

This guide explains the necessary steps for continuous integration on your viktor application and provides some example files for frequently used CI/CD platforms. See this article for an introduction on the concepts of continuous integration if you're unfamiliar with the topic.

Setting up the environment

First you need to make sure that your CI environment is the same as the environment in which your app will run. This means:

  • Linux machine
  • Matching Python version
  • Environment variables VIKTOR_DEV and VIKTOR_TOKEN should be set. Contact VIKTOR to receive CI-credentials (don't use your personal developer credentials!).
  • Environment variable VIKTOR_ENV should be set with the environment you are publishing to (e.g. {company}

Continuous Integration

  1. Download the CLI, which will be used to perform CI commands:

    curl -Lo viktor-cli '' && chmod +x viktor-cli
  2. Install the app and its dependencies:

    ./viktor-cli ci-install

    Make sure you only use ci-install in the CI job and install during local development:

    • The ci-install command is an alias for a very involved pip install command, which would otherwise pollute your local Python environment.
    • The install command does not work in your CI environment
  3. Perform all tests (found in the 'tests' directory):

    ./viktor-cli ci-test

Continuous Deployment


Currently, publishing is supported for the following CI/CD platforms:

  • Azure Pipelines
  • GitHub Actions
  • GitLab CI/CD

The CLI can be used to automate the publishing of apps in CI pipelines with the ci-publish command. We recommended creating a Git tag to reference specific versions of the app code you are publishing on the platform. It is possible to conditionally trigger pipelines / workflows only when a tag is created.

./viktor-cli ci-publish <NAME>

The CLI determines which CI/CD platform is used based on platform-specific environment variables. Subsequently, all information required to publish your app is collected by the CLI and used to create a publication context. This context is stored together with the app version for later reference. The variables used to determine the publication context are shown in the table below.

Azure PipelinesGitHub ActionsGitLab CI/CD
User emailBuild.RequestedForEmailn.a.GITLAB_USER_EMAIL
Commit hashBuild.SourceVersionGITHUB_SHACI_COMMIT_SHA
Branch or tag refBuild.SourceBranchNameGITHUB_REF_NAMECI_COMMIT_REF_NAME
Pipeline URLSystem.TeamFoundationCollectionUri, System.TeamProject, Build.BuildId*GITHUB_SERVER_URL, GITHUB_REPOSITORY, GITHUB_RUN_ID*CI_PIPELINE_URL

* These variables are combined into a URL to the pipeline / workflow that triggered the ci-publish command.

Example CI/CD files

Below are examples of configuration files for frequently used CI/CD platforms. In the examples below you should replace NAME with the name of the app as it is registered on the platform.


Be sure to set the variables VIKTOR_DEV, VIKTOR_TOKEN and VIKTOR_ENV within a variable group with name (e.g. "VIKTOR").

- group: VIKTOR # variable group within DevOps library containing the variables VIKTOR_DEV VIKTOR_TOKEN & VIKTOR_ENV
- job: test
container: python:3.11-buster
- bash: curl -Lo viktor-cli '' && chmod +x viktor-cli
- bash: ./viktor-cli ci-install
- bash: ./viktor-cli ci-test
- job: publish
container: python:3.11-buster
condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/')) # only run for a tag and when previous job completed successfully
- bash: curl -Lo viktor-cli '' && chmod +x viktor-cli
- bash: ./viktor-cli ci-publish NAME # replace NAME with the actual name of the app