Redgate's solution integrates with existing version control, Continuous Integration (CI) and Continuous Delivery (CD) systems.  This checklist explains what needs to be installed and ready for the Proof of Concept (POC) to be successful.  

If you have any questions about getting started, reach out to our Database DevOps Team.

Flyway POC Checklist

Prior to our first Proof of Concept (POC) meeting, please complete the follow steps so we can get started quickly and make the most of our time together.  If you have any questions about these steps, please reach out to your Sales representative or email Sales prior to our first meeting. 

POC Guidelines

The goal of the POC is to walk through flyway's functionality to ensure its capabilities are as advertised. The POC is structured to evaluate deployments, rollbacks, drift reports, and code analysis. 

Every CI/CD platform is intended to execute CLI, and all flyway CLI functionality can be tested locally.  

Tools To Download and Install

Review our Architecture Diagram before getting started.

1. Flyway Desktop 
   1. Download the installer. 
   2. Install it on the developers' machines that will be working against the development database or any other machines (like a DBA, team lead, or release engineer) that may be generating migration scripts for database deployments. 
   3. After installing, launch Flyway Desktop and login to make sure you have the right access.  Be sure the Redgate ID you login with is assigned to an Enterprise license key that is provided by Redgate.  You should see Enterprise in the top left of Flyway Desktop after logging in. 
      

Databases Needed

Have you identified which database you want to use for the POC?  Do you have access to copies of this database that can be freely used for POC purposes?  Ideally, we'll start simple to understand the process, but please let us know about any complexities in your databases/processes:

1. Development Database - This is where you will make changes and capture them using Flyway Desktop. Ensure that you have full access to the Development database for the POC (SQL Server = db_owner; Oracle = schema owner). Start with a simple database. Choose an isolated database without any linked servers or x-database dependencies.  If your real projects have this, please let us know.  Then we can try a bigger or more complex database (e.g., x-database dependencies, filegroups).
   
   
2. Disposable Blank Database - Each developer generating migration scripts should have a shadow database.  This enables script generation without connecting to a production environment. Learn more about the Shadow database in this video and documentation. The shadow databases should be empty and perform best when it is local to your development machine.
   1. Have you provisioned an empty database (no schema or objects) for the “shadow” database? This is a sandbox managed by the tool in order to generate and validate migration scripts.
      
      
   2. Flyway will deploy scripts to this database, functionally acting as a build. 

1. Schema Only Backup - If SQL Server or Oracle, and of substantial database size or x-database dependencies, consider using a DDL only metadata backup file to capture the current state of production.  Here's a video of the backup as baseline concept. 
   1. SQL Server docs
   2. Oracle docs
      
      
2. Target databases - This is your downstream environments (eg., Test, UAT, Staging, Production) that changes will be deployed to. 
   1. If you are connecting to an Azure hosted database, register Flyway Desktop.
        

Preparing Your Target Databases

1. The best and simplest way to prepare for an implementation is to have your downstream databases (e.g., Test and Prod) in sync in terms of objects. This is so that when we capture the state of production in a baseline, we have a way to mark all downstream environments at this same known state. Then, all ensuing migration scripts will be applicable to the entire pipeline.. 
   1. It's possible to use Redgate's comparison technology (included in Flyway Enterprise) to ensure your databases are in sync (download installers).
   2. In a real world scenario, we can generate different baseline scripts if your environments are not in synch, but let's keep the POC simple.

Set Up Flyway POC

Review our Architecture Diagram before getting started.

1. 1. Flyway Desktop 
      1. Download the installer. 
      2. Install it on the developers' machines that will be working against the development database or any other machines (like a DBA, team lead, or release engineer) that may be generating migration scripts for database deployments. 
      3. After installing, launch Flyway Desktop and login to make sure you have access to it.  (Be sure to use an Enterprise license key that is provided by Redgate.) 
   2. If Oracle databases, Schema Compare for Oracle 
      1. We will use this GUI to filter out schema objects, if needed.
      2. Download the installer.
      3. Install on all the machines where you installed Flyway Desktop.  You may only need to install this on the developer that is "driving" the POC at a minimum to get started.
   3. Schema Only Backup - If SQL Server or Oracle, and of substantial database size or x-database dependencies, consider using a DDL only metadata backup file to capture the current state of production. Video of backup as baseline concept can be found here. 
      1. SQL Server docs
      2. Oracle docs
   4. Development database - This is where you will make changes and capture them using Flyway Desktop. Ensure that you have full access to the Development database for the POC (SQL Server = db_owner; Oracle = schema owner).
      1. 1. If Oracle, have you identified which schemas are in scope for the POC and is there a service account with the same username/password which can access all schemas?
   5. Shadow database (Enterprise Only) - Each developer generating migration scripts should have a shadow database.  Learn more about the Shadow database in this video and this documentation. The shadow databases should be empty and performs best when it is local to your development machine.
      1. Have you provisioned an empty database (no schema or objects) for the “shadow” database? This is a sandbox managed by the tool in order to generate and validate migration scripts.

Now you are ready to test out the Flyway commands - we have a structured guide to follow here.