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.
      
      
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.  Here's a video of the backup as baseline concept. 
   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.
        

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.

Test Flyway

1. Example Flyway commands are provided on the Automated Deployment page in Flyway Desktop.   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.   For additional samples, see:
   1. PowerShell scripts for Windows
   2. Bash scripts for Unix systems