The Database CI Process provides a build release within the Azure DevOps environment.

The Database CI Process leverages on the following assets, i.e.

  • Staging Environment
    • Azure GIT - branch staging
    • Azure DevOps Pipeline - <subscription-name>.DB-STG.CI
  • Production Environment
    • Azure GIT - branch production
    • Azure DevOps Pipeline - <subscription-name>.DB-PRD.CI

Database CI Pipeline

When the User pushes commit into the Staging/Production branch, the build pipeline automatically creates artefacts to be deployed into their respective database.

The Pipeline CI Database will trigger automatically when the SQL file is committed in their respective branch. To commit, you shall do two (2) activities as follows:

  1. Verify the SQL files corresponding to database naming rules.
  2. Publish the folder with the latest committed SQL file to the CD DB-Deploy pipeline.
There are no automated backup processes during the deployment of the Staging Pipeline. Make sure to backup your database to prevent loss of data or corruption should the deployment fail. Click database backup for more details.

Reviewing the State of Your Build Process

You can track the status of the Database CI Process from the build's pipeline. Here is how:

  1. From the Cloudvanti Sitefinity Management Portal menu, select Pipelines. Then select Pipelines.
    To check the CI Process for Staging<subscription-name>.DB-STG.CI.
    To check the CI Process for Production<subscription-name>.DB-PRD.CI.

  2. If there is an unexpected complication when initiating the process, clicking the Run Pipeline button in the upper right area will manually trigger the Pipeline.

  3. A list of the published SQL script (artefact version) will be displayed. Click on the Build to view the detailed history.

  4. Select Publish Database for the log Build process.

  5. The log will detail any errors in the build of the Database CI process.


Once the build process is completed successfully, it will automatically deploy to its designated database using the publish database script.

If the build process fails, no database script will be published and the process will stop. No database changes will be deployed to its respective environment.