...

Instructions

Sample Repo

A sample public GitHub repo can be found here:

https://github.com/liquibase/cs_azure_cicd_pipelines

Prerequisites

Before following the steps in this document, setup your databases and create the Liquibase project.

...

This example also uses 2 optional repos:

• A centralized Rules repository.

  • When using a centralized Rules repository be sure to include the following in the .gitignore of the Liquibase Project repository.

    • Code Block
      Rules/

• A centralized CI/CD repository.

...

• Windows: Installing Liquibase Enterprise Clients on Windows Systems

• Linux: Theme: Using the CLI and the Composite Repository to Install Liquibase Enterprise on Linux Systems

Make sure that git is installed on the agent as it will be needed by the Liquibase Enterprise Deploy Packager. SCM Requirements and Features

...

For each Forecast Stage, select the Agent that will be used to run the job. Be sure to select the Agent Pool configured in Step 21.

...

Each Azure Stage is comprised of Tasks. Use a Command line task to run the Liquibase Enterprise hammer commands. (Please note, use of Windows agents may require slightly different task types or script code. Eg. Powershell may be required.)

1. Be sure to unzip the artifact prior to running the hammer commands.

2. You’ll need to specify the Working Directory under the Advanced section.

3. You’ll also want to set DDB_USER, DDB_PASS, DDB_DMCDB_USER, and DDB_DMCDB_PASS under the Environment Variables section. These values will be set to the name of the vault values, eg. $(Liquibase-abc-dev-User), $(Liquibase-abc-dev-UserPass), $(Liquibase-abc-dmc-User), $(Liquibase-abc-dmc-Pass)

...

whoami
hammer show version
unzip -o *.zip

hammer deploy --labels=current --pipeline=current DEV

...

# Depending on how you have zipped the artifact you may need to cd into the DDB repo.

hammer forecast --labels=current --pipeline=current TEST

...

Configure a Deploy Stage

A Deploy Stage will be identical to a Forecast stage with the exception of the Script Code.

...

whoami
hammer show version
unzip -o *.zip
# hammerDepending deploy --labels=current --pipeline=current on how you have zipped the artifact you may need to cd into the DDB repo.

hammer deploy --labels=current --pipeline=current TEST

Step 10: Test your Pipeline

...

After all your pipeline steps have completed successfully, your artifact will be ready to run a Release.

...

1. Go to Releases and select “Create release”

...

1. .

2. Select all the stages to run.

3. Specify the Artifact Version to run. Select the most recent.

4. You’ll need to click on the Stages to trigger them. You’ll need to click “Deploy”. (Please note this “Deploy” terminology is from Azure. Even the Liquibase Enterprise Forecast will be triggered via a “Deploy” button.)

...

Troubleshooting

ERROR: Error getting list of commits; Invalid revision range; unknown revision or path not in the working tree

Problem: One of the following messages appears when executing the pipeline:

ERROR: Error getting list of commits
ERROR: fatal: Invalid revision range

ERROR: fatal: ambiguous argument '158902d..HEAD': unknown revision or path not in the working tree.

Resolution

Azure Devops has a default GitHub fetch depth of 1 commit. This causes a problem of not being able to find the sqlScmLastImportID specified in deployPackager.properties. Updating the sqlScmLastImportID in the latest commit results in a temporary one-off success.

A large fetchDepth can affect performance of the pipeline over time, especially if large commits are made to the SQL repo. For example, a fetchDepth of '0' can be used to get all commits in the branch, but doing this every time could be wasteful of resources as time goes on, or if there are large commits: (https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops&tabs=yaml#shallow-fetch ).

This parameter might require tuning or intervention over time if the error appears again. We recommend starting with a relatively low value, say 100, for maintaining a consistent rolling window of 100 commits. While this setting can be made using the UI for basic pipelines with no YAML definition, it should be made directly in the pipeline YAML where checkout steps are defined.

Below is an example of the usage of fetchDepth:

- checkout: SQL_REPOSITORY
  clean: true
  persistCredentials: true
  fetchDepth: 100