Redgate's solution integrates with existing version control, Continuous Integration (CI) and Continuous Delivery (CD) systems.  This Proof of Concept checklist explains what needs to be in place and what needs to be installed where for a successful proof of concept.  

If you have any questions about getting started with our Database DevOps for Oracle solution, please reach out to Sales.

Click here for the State-based Proof of Concept Checklist

Click here if you're using Source Control for Oracle and automating your deployments with a state-based approach.

Use the following example if you are using Redgate Change Control and Redgate Change Automation in a migrations-based or hybrid approach.

Migrations-based Proof of Concept (POC) Checklist

Version Control – Client Machine

Before installing and setting up Redgate Change Control for database version control, you need to:

1. Install or get access to a version control system (VCS) (e.g., Git, Azure DevOps Repos, Subversion, etc.) or get access to a hosted system like GitHub or Azure DevOps Repos, which both have free versions. Make sure you have admin access and known credentials for a user.
2. Pick a development database that you have full access to for use in the POC.
   1. For POCs on Oracle 12c+, it may be easier to have one Oracle instance with a container database (CDB) containing multiple pluggable databases (PDBs) to represent different environments (DB_NAME_DEV, DB_NAME_SHADOW, DB_NAME_TEST, DB_NAME_PROD).
   2. To simplify the POC, choose a schema that doesn't rely on any database links.
3. Ensure the client’s machine can connect to the given Oracle database (e.g., using SQL Developer).
4. Ensure the client machine can connect to the VCS (e.g., using your VCS client).
5. Arrange admin access for all developer machines involved in the POC for installation purposes.
6. Download and install the Redgate Deploy from redgate.com/oracle on all client machines. For the POC, please install:
   1. Redgate Change Control
   2. Schema Compare for Oracle
   3. Data Compare for Oracle
   4. Code Analysis for Oracle

Continuous Integration (CI) – Build Agent

Before installing and setting up Redgate Change Automation for database Continuous Integration (CI), you need to:

1. Install or get access to a CI system (e.g., Jenkins). Make sure you have admin access for a known user.
2. Identify an Oracle instance that can be used as part of the build process to build and test the database code. (For POCs on Oracle 12c+, we recommend a separate PDB on the same instance used above.)
3. Install your CI agent (or equivalent) and set up a path of communication to the CI tool. This agent should also have access to the Oracle instance identified for build purposes
4. Ensure the CI installation has a clear path of communication to your VCS.
5. Arrange admin access on all machines involved in the POC for installation purposes.
6. Install SQL*Plus on the CI agent.
7. Download and install the Windows or Linux versions of Redgate Change Automation and Code Analysis for Oracle from https://documentation.red-gate.com/dso on your CI agents. This allows you to:
   1. Quickly validate the scripts in your repository
   2. Execute any utPLSQL tests
   3. Run code analysis to ensure best practices and naming conventions are being followed

Automated Deployments – Release Agent

Note: If you are using one system for CI and automated releases (e.g., Jenkins), then you can skip these steps.

Before installing and setting up Redgate Change Automation for automated database deployments, you need to:

1. Install or get access to a release management (RM) system (e.g., Jenkins). Make sure you have admin access for a known user.
2. Install your RM agent (or equivalent), and ensure it has a path of communication to the RM server. This agent should also have access to the target Oracle instance for deployment (e.g., maybe a Test or QA DB).
3. Arrange admin access on all machines involved in the POC for installation purposes.
4. Install SQL*Plus on the RM agent.
5. Download and install the Windows or Linux versions of Redgate Change Automation from https://documentation.red-gate.com/dso on your RM agent. This allows you to: 
   1. Generate reports to easily review schema changes
   2. Create Schema Compare for Oracle snapshots for an easy starting point for rollbacks
   3. Check for drift to ensure repeatable deployments
   4. Review and execute the necessary migration scripts against your target database(s)