Deployment Suite for Oracle 6

Deployment Suite for Oracle has been replaced by Redgate Deploy - Oracle. This page is therefore no longer being updated. For the latest documentation, please click here.

GitLab uses a YAML style configuration for defining a CI/CD pipeline, and so using RCA is relatively straight forward. Simply create a `.gitlab-ci.yml` file in the root of your GitLab repository. You can base your own off the example described below.

As described in the documentation, RCA relies on three stages in order to validate, create, and perform a release of a new project version to a target database. These stages are described above as Build, Prepare, and Release:*. Test is an optional stage depending on your database technology choice and the availability of unit tests in your project or database.

In our example, we are performing a release to two downstream environments, QA, and Production. Our team can vet any changes made during the release via manual testing of the QA database, before then manually approving a deployment to the Production database, finishing the release.

The sample configuration that defines the pipeline above can be found below. This example uses custom variables to mask database passwords, which you can learn more about in the GitLab documentation.

.gitlab-ci.yml

image: docker:latest

# Passwords are supplied via protected variables. See https://gitlab.com/help/ci/variables/README#mask-a-custom-variable
# You will need to supply them as the following extra variables in this way, to ensure they're masked in the logs:
#	* CI_DB_PASS
#	* QA_DB_PASS
#	* PROD_DB_PASS

variables:
    CI_DB_JDBC_URL: "[YOUR JDBC URL HERE]"
    QA_DB_JDBC_URL: "[YOUR JDBC URL HERE]"
    PROD_DB_JDBC_URL: "[YOUR JDBC URL HERE]"

	# You may want to set the RCA docker version if you don't want to constantly pull the latest changes.
	RCA_VERSION: latest 

# We rely on the GitLab CI/CD service docker:dind in order to run the RCA docker container inside the GitLab runner.
services:
  - docker:dind

# Release is split into two stages, since we want to progress to release:prod only once we've manually verified release:qa.
stages:
    - build
    - test
    - prepare
    - release:qa
    - release:prod

# The build step builds the project against a clean CI database, and create the build artifacts necessary to prepare a release.
build:
    stage: build
    script: docker run --rm -v $CI_PROJECT_DIR:/project/ redgate/change-automation:$RCA_VERSION build -v -P /project/demo-project/demo-project.conf -t $CI_DB_JDBC_URL -o /project/build-$CI_COMMIT_SHORT_SHA.zip -u system -p $CI_DB_PASS --IAgreeToTheEula --clean
    artifacts:
        paths:
            - ./build-$CI_COMMIT_SHORT_SHA.zip
        expire_in: 1 day

# This test is left empty, however can be used for running utPLSQL tests for Oracle databases.
# Learn more here https://documentation.red-gate.com/dso/redgate-change-automation/command-line-verbs#CommandLineVerbs-test
test:
    stage: test
    script: echo This demo does not define a utPLSQL test schema.

# The prepare stage prepares a release for both QA and Production.
# We can't reuse a prepared release for both, since they may be at different project versions.
# (e.g., if you've applied several releases to QA, but haven't yet released any of them to Production.)
prepare:qa:
    stage: prepare
    script: docker run --rm -v $CI_PROJECT_DIR:/project/ redgate/change-automation:$RCA_VERSION release prepare -v -b /project/build-$CI_COMMIT_SHORT_SHA.zip -t $QA_DB_JDBC_URL -o /project/release-qa-$CI_COMMIT_SHORT_SHA.zip -u system -p $QA_DB_PASS --IAgreeToTheEula
    dependencies:
        - build
    artifacts:
        paths:
            - ./release-qa-$CI_COMMIT_SHORT_SHA.zip
        expire_in: 1 week

prepare:prod:
    stage: prepare
    script: docker run --rm -v $CI_PROJECT_DIR:/project/ redgate/change-automation:$RCA_VERSION release prepare -v -b /project/build-$CI_COMMIT_SHORT_SHA.zip -t $PROD_DB_JDBC_URL -o /project/release-prod-$CI_COMMIT_SHORT_SHA.zip -u system -p $PROD_DB_PASS --IAgreeToTheEula
    dependencies:
        - build
    artifacts:
        paths:
            - ./release-prod-$CI_COMMIT_SHORT_SHA.zip
        expire_in: 1 week

# The release stage consumes the release artifacts generated in the prepare stage,
# and performs the actual release against the downstream databases.
release:qa:
    stage: release:qa
    script: docker run --rm -v $CI_PROJECT_DIR:/project/ redgate/change-automation:$RCA_VERSION release perform -v -r /project/release-qa-$CI_COMMIT_SHORT_SHA.zip -t $QA_DB_JDBC_URL  -u system -p $QA_DB_PASS --IAgreeToTheEula
    dependencies:
        - prepare:qa

# The release to production has an additional manual step so we can block the pipeline
# until the user is ready to deploy.
release:prod:
    stage: release:prod
    script: docker run --rm -v $CI_PROJECT_DIR:/project/ redgate/change-automation:$RCA_VERSION release perform -v -r /project/release-prod-$CI_COMMIT_SHORT_SHA.zip -t $PROD_DB_JDBC_URL -u system -p $PROD_DB_PASS --IAgreeToTheEula
    when: manual
    dependencies:
        - prepare:prod