GitOps-enabled version control

From Digital.ai Release 10.2, you can use GitOps-enabled version control to store and track changes to folder entities in the form of YAML files (Releasefile.yaml) within a Git repository.

Preparing your folder for GitOps-enabled version control

You need to follow the steps to use the GitOps-enabled version control on a folder:

  1. Enable folder version control
  2. Configure a Git repository connection
  3. Configure folder version control
  4. Migrate the passwords on Configurations and Templates

Enable folder version control

You can enable or disable the folder version control feature on the Settings > Features pages. See Configure Feature settings for more details.

Configure a Git repository connection

There are two locations where you can define a Git repository Connection :

  • On a global level in Settings > Shared configuration
  • On a folder level in Design > Folders, under the Configuration tab of the desired folder

To setup a git repository connection:

  1. In Digital.ai Release, go to one of the two specified locations
  2. Click the + icon next to Git: Repository
  3. Enter the following details:

    • In the Title field, enter a name for the configuration
    • In the URL field, enter the address of the repository server as follows: http(s)://address:port/repository
    • In the Authentication Method field, select the authentication method used for authenticating to the remote repository
    • In the Username and Password fields, enter the user ID and password/personal token

      Note: To use the personal access token for Github and Bitbucket, select Basic from the drop-down list in the Authentication Method field.

  4. To test the connection, click Test

    Note: This will not test if the user has push permissions on the remote repository (required for Saving versions).

  5. To save the configuration, click Save

Create new repository

Configure folder version control

To setup folder versioning for a given folder:

  1. Select a folder and click Version control
  2. Click on the Configure button
  3. Select a Git repository from the dropdown, or click on New repository if you don’t have one
  4. Select a branch that you want to synchronize with. The branch must already exist on the remote repository
  5. Select a path in the repository where you want the Releasefile.yaml to be stored. By default the path is the name of the folder
  6. Select a tag prefix that you want your commit tags to be prefixed with. By default it’s the folder name
  7. Select which entities you want exported to the local repository in the generated Releasefile.yaml file
  8. Click Save

Configure folder version control

Note: To configure folder version control, you need the Edit versions permission. See Version control permissions for details.

After the folder versioning is configured, Release will start cloning the repository locally, which might take a couple of minutes if the repository is very large.

Migrate passwords to password variables

The passwords in versioned entities will not be exported, instead the generated Releasefile.yaml will have !value somePassword placeholder tags. This is to avoid leaking passwords to a plaintext file on an external server. The variables should be one of the following:

  • Global password variables
  • Folder password variables of a parent folder (not versioned)
  • Folder password variables of the versioned folder, if you disable versioning for variables in folder version control configuration
  • Folder password variables of the versioned folder, if they are External Password Variables with the Secrets Server configured outside the versioned folder

Using GitOps-enabled folder version control

Listing the version history

When you visit the Version control tab, there will be a list of commits under Version history. Only the commits that are tagged in Git, where the tags begin with the same tag prefix as the configured tag prefix in folder versioning configuration, are listed. The commits are ordered by the creation date. The first element in the list (Current) is the current state of your folder before it is saved. The elements under Previous versions are the commits that exist in the Git repository.

List versions

In order to view the Releasefile.yaml content of the commit, you must select it and press Preview code.

View yaml

Note: To list versions and preview YAML, you need the View versions permission. See Version control permissions for details.

Fetching latest changes

The commits listed in Version history are from the local repository on Release server. In order to synchronize with the latest changes on remote repository, you must click Fetch changes. When you hover over Fetch changes you will see the date the last time a fetch was done.

Note: To fetch changes, you need the View versions permission. See Version control permissions for details.

Saving a new version

In order to export the current state of the folder into the remote repository:

  1. Go to Version control
  2. Under Version history click Current (pre-selected)
  3. Click Save as a new version
  4. Type in the Name field. This field will be used in the tag of the commit and appended to the configured tag prefix
  5. Type in the Description field. This field will be used in the commit message. If left empty, the Name field will be used in the commit message

Save new version

Note: To save a new version, you need the Edit versions permission. See Version control permissions for details.

Applying an existing version

In order set the state of the folder to the one described in the Releasefile.yaml of one of the previous versions:

  1. Go to Version control
  2. Under Version history click on a version you wish to apply
  3. Click Apply this version
  4. Click Apply in the modal

After the apply was successful, the version that was applied will have an Applied badge on it, until a new version gets saved.

Note: To apply a version, you need the Edit versions permission. See Version control permissions for details.

Note: The apply feature is experimental and the folder might not be set to exactly the same state as described in the Releasefile.yaml of that commit.

Note: Releasefile.yaml files that contain secret placeholders (!value somePassword) will not be successfuly applied. You will get an error. You must use folder or global password variables on passwords for apply to work properly.