There are many different ways that Redgate Change Automation can be used in a CI/CD pipeline. One possible setup looks like this:

• Run build against an empty CI database environment to validate the migration scripts and see if there are any code analysis issues.
• Run test against the CI database (post-build assuming the CI database now contains utPLSQL unit tests)
• Once the build and test steps have succeeded or been approved:
  • Provision an Acceptance (if this is a copy of Prod, consider masking the data)
  • Run release prepare against the Acceptance database to generate the release artifact
  • Review the artifact (change report, drift report, deployment script)
  • If necessary, make changes to the project (e.g. drift correction) and re-start the pipeline
• Once the release artifact has been approved:
  • Run release perform against the Acceptance database using the release artifact.  This will automatically check that the Acceptance schema hasn't changed since the release was prepared.
  • Do any necessary user/performance/other testing as needed
• Once approved:
  • Run release perform against the Production database.  This will automatically check to make sure that the Production schema hasn't changed since the release was prepared to ensure you had a good dry run before going to Production.

If at any point changes need to be made to the deployment (e.g. after drift correction), the artifacts should be regenerated by re-starting the pipeline.

The Redgate Change Automation command lines work with any CI/CD system (eg, Jenkins, Team City, Octopus Deploy, Azure DevOps, Xebia Labs, UrbanCode, and more).  It's available to run on Windows or Linux agents or via Docker.  See the following worked examples:

• Jenkins
• Azure DevOps
• Team City and Octopus Deploy
• GitLab