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

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 functionality 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 access to it.  (Be sure to use an Enterprise license key that is provided by Redgate.) 

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 (Enterprise Only) - 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 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.
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. 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.  

   2. For POCs in Oracle 12c+, we've found it's simpler to use Oracle's multitenant architecture, using multiple pluggable databases (PDBs) to represent the different environments( < dbname > DEV, < dbname > SHDW, < dbname > TST, < dbname > PROD).  You can use the Oracle XE or the Oracle 23ai free version download to accomplish this.

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 script, generated by the tool, 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.

Test Flyway Out

1. Everything that is done in a CI/CD deployment pipeline (Azure Devops, Github Actions, Gitlab, Harness, etc) can and should be tested via CLI. This is the fastest path to testing out the functionality. 
   1. Run the flyway commands! The "Migrations" tab in Flyway desktop will work for you. If you want to script them out, here are some sample commands you can leverage
      1. Powershell scripts for Windows systems can be found here
      2. Bash scripts for Unix systems can be found here