Architecture Diagram

One system
for Continuous Integration (CI)
and Release Management (RM)

Different systems
for Continuous Integration (CI) and Release Management (RM)

Legend:

Flyway Desktop (FWD) - Version control your database objects, generate migration scripts and validate deployments
Client machine - This is where the developer works.  This machine needs to be able to access the development database (e.g., using your database IDE) and the Version Control System (VCS) (e.g., using a VCS client like GitHub Desktop or Sourcetree).  This is where Flyway Desktop is installed.


Flyway (FW) - Safely automate the deployment of your migration scripts with the Flyway command line or Docker. 
Continuous Integration (CI) / Release Management (RM) Agent - If you have Docker on your agent and want to use the Flyway Docker container, then nothing needs to be installed.  If you are not using Docker, then install the Flyway command line for CI and automated deployments.  Please add the location where you installed flyway to the Path in the agent's Environment Variables.  The Flyway command line is available for Windows, Linux, or Mac.  
If you want code analysis with SQL Fluff, you'll also need to install Python3 and add pip to your path.  See our Flyway Implementation Checklist for more information.

Using Docker is recommended because the image comes with all the prerequisites and nothing needs to be installed/maintained on your agents.

Sample Process Workflow - Database development and deployment with Flyway Enterprise

Starting in the bottom left:

  1. Work directly against your development database in your preferred IDE.
  2. In Flyway Desktop, see what has changed.  Save the object level and static data SQL scripts to disk. 
    1. Optional - If you wish to use migration scripts for deployments, generate versioned and undo migration scripts on disk.
  3. Use Flyway Desktop or your own VCS client to version control these scripts.
  4. Optional - Create a Pull Request (PR) so the database changes and optional migration scripts are reviewed.  Code analysis and database unit testing can be ran to catch issues early.
  5. Optional - Use your CI/CD system to generate a report of changes, check for drift (changes that happened outside the pipeline, e.g., hot fix), run code analysis and other testing (unit, integration, performance, etc.).
  6. Use your CI/CD system to deploy your database changes to your downstream environments (QA, UAT, Prod).  Optional - Set up a manual intervention before going to Prod, so releases can be reviewed and pushed on your time. 
  7. Optional - Refresh your development database using Redgate Test Data Manager (TDM) with realistic prod-like datasets, while keeping your prod data safe. 
  8. Repeat step 1.

Next steps:



Didn't find what you were looking for?