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 Implementation 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.

Tools To Download and Install

1. Review our Architecture Diagram before getting started.

2. Flyway Desktop 
   1. Download the installer. 
   2. Install it on the developers' machines that will be developing against the 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.) 
3. SQL Compare or 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.

CI/CD Systems for pipelines

1. The Flyway CLI will need to be installed on the agent (unless you're using Docker). 
   1. Make sure to add the the directory for where Flyway is installed to the agent's path environment variable, so it's accessible. Example video
   2. Minimum specs can be found here.
2. The user account of the agent will need read/write access to the target databases provisioned for the POC. It is strongly recommended to use a self-hosted agent with DDL admin permissions.
3. Very often in a POC, we will need a networking engineer to ensure the agent can communicate successfully with the target databases.
4. Using Flyway on your CI/CD Agents - Flyway - Product Documentation (red-gate.com). 

Version Control setup

1. Every developer should have Git installed on their local computer.  Learn more about the Git requirements.
2. Have you created a repository in your version control system (e.g., Azure DevOps, GitHub, GitLab, BitBucket, etc.) or do you have access to an existing repository that you will be working in for this POC?  
3. Have you validated that the developer “driving” the POC can Commit, Push, and Pull from their machine that has Flyway installed to the repository?

Databases Needed

1. See the system requirements.
2. 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:
3. Choose an isolated database without any linked servers or x-database dependencies.  If your real projects have this, please let us know.  
   1. Database - start with a simple database.  Then we can try a bigger or more complex database (x-database dependencies, filegroups).
   2. Pipeline - start with CI → Test → Production.  Then we can look at more complicated pipeline needs (e.g., deploy to offsite production environments, deploy to different client databases that have different schema/data changes, deploy to many production environments).  We can handle these, but we'd like to keep the initial POC simple to understand the workflow at a higher level before diving in deeper.
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. 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 (devoid of schema and objects) for the “shadow” database? This is a sandbox managed by the tool in order to generate migration scripts.
6. Target databases - This is your downstream environments (eg., Test, UAT, Staging, Production) that changes will be deployed to. 
   1. (Enterprise Only) A baseline is needed that captures all the objects that have already been deployed to Production.  Does your Production database have any invalid objects? Guidance here.
   2. If you are connecting to an Azure hosted database, register Flyway Desktop.  
   3. 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).  You can use the free Oracle Express Edition for this purpose.
7. Pipeline databases (Enterprise Only) For a fully automated pipeline with CI, drift detection, and/or change reports, we will use these additional databases. The following will be required and should be completely empty of objects (filegroups and x-database dependencies should be setup): 
   1. Build database - You need one per pipeline that your Continuous Integration builds will execute against to validate scripts in the repo and package them for a repeatable release process. 
   2. Check database - This is used to generate change and drift reports, if desired.

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. If the above is not possible, we can create multiple migration scripts to capture the differences between the downstream environment and set their version differently.

Sample Pipelines and Next Steps

1. Watch our training videos on Flyway concepts and how to set up a project.
   1. Flyway Enterprise
   2. Flyway Teams
2. See our sample pipelines.  Please let us know if there is not an example for your CI/CD system.
3. If you will use MFA authentication in ADO, read here on how to do so.