Now that you've committed your migration scripts to the hosted repository, it's time to set up continuous integration and deployment (CI/CD) using GitHub Actions. This setup allows your database changes to be automatically applied across all environments, ensuring a smooth deployment process.

Step-by-Step Guide

1. Navigate to GitHub Actions

   • Go to your GitHub repository and click on Actions in the top menu. You will likely need to enable actions on the repository before carrying on, as seen below!
     

2. Locate the Workflow Files

   • The repository is already set up with multiple workflows designed for different operating systems.
   • In the repository’s file structure, navigate to the .github/workflows folder. Inside, you will find several YAML scripts clearly labeled with an OS suffix based on the operating system of your self-hosted runner (e.g., windows.yml, linux.yml).
     
   • Do not run any workflows yet—we need to configure the runner and license first.

Configuring Your Self-Hosted Runner

1. Add a Self-Hosted Runner
   • Navigate to Settings in your GitHub repository.
   • In the left-hand menu, click on Actions > Runners and select New self-hosted runner.
     
   • Follow the instructions provided for your specific operating system (Windows, Linux, or macOS) to set up the runner.
     
   • Once installed, this runner will serve as the environment that runs the Flyway commands in your CI/CD pipeline.

Adding a Personal Access Token (PAT)

1. Set Up a Personal Access Token (Click here for more details)
   • A valid Flyway License is required in order to authenticate Flyway within a pipeline. The most secure and industry standard way of doing this is through setting up a Personal Access token, linked to your Redgate Portal account.
     • Step 1: Navigate to https://identityprovider.red-gate.com/personaltokens
     • Step 2: Login with your Redgate Portal account
       • This should link to the Redgate Account used when starting your trial within Flyway Desktop.
       • If you're still unaware which account to use, navigate back to Flyway Desktop and validate which account was used or sign up for a new trial.
     • Step 3: Click '+ New Token' to create a new Personal Access Token
       • Ensure you save this somewhere, like a password manager, as there's no method of seeing the token again in future. 
       • Treat this token just like any other secure password you use. If the token is lost, or compromised, simply choose to revoke the token and create a new one.
     • Step 4: Navigate to the Redgate Portal website (Where you can see all licenses linked to your account) - https://portal.red-gate.com/licenses
     • Step 5: Select Flyway Enterprise from the list (You may need to select 'Licenses on the left hand side menu to see it)
       • If the Flyway Enterprise trial was started through Flyway Desktop, your Email Address will automatically have been allocated to the license 'Flyway Desktop Enterprise'.
     • Step 6: Ensure the license is allocated to your email address. To do this, click '+ Allocate' > Enter your email address > Click Add User'
       • 
     • Note - Flyway CLI License Keys (Which start FL01) are still valid and can be used within pipelines. However, these are now deprecated, therefore Redgate recommends moving to PATs as described above. Reach out to the AutoPilot team at flywayap@red-gate.com if you need any further details.
   • In your GitHub repository:
     • Go to Settings > Secrets and variables > Actions on the left-hand menu.
       
     • Click New repository secret and create two secrets. The names as as follows:
       • FLYWAY_EMAIL
         • This should contain your Redgate Portal email address used in the PAT creation steps above
       • FLYWAY_TOKEN
         • This should contain the secure PAT created in the section above. This token should be treated like any other password, thus added a secret in GitHub for security
     • See below for an example of adding a secret.
       

Editing the Workflow Files

1. Configure the Workflow
   • Open the .github/workflows folder and locate the YAML file that matches the operating system of your self-hosted runner (e.g., windows.yml for Windows-based runners).
   • The workflows are pre-configured to use the environment details configured through Flyway Desktop, stored in the flyway.toml project file. Therefore, use the 'Migration Scripts' tab in Flyway Desktop to validate these by clicking 'Manage target databases'.
   • Review any additional settings in the workflow that may need customization, such as environment variables or paths.
     • Common Changes - The pipeline is setup to run Flyway against three environments (Build/Test/Production). If integrated security is used to connect to your database, then no further changes are required! However, if not, then it's necessary to provide Username/Password details for each database Flyway connects to. Therefore, at the top of the YML workflow (referenced by the comment '### Step 1: Stage Variables'),  all the variables that may need changing can be found (Alongside a handy comment detailing what they are).
     • 

Running the Workflow

1. Run the Workflow

   • After setting up the runner and editing the workflow file, go back to the Actions tab in GitHub.
   • Select the appropriate workflow (e.g., windows.yml) and click Run workflow.
     

2. Monitor the Workflow

   • Once the workflow starts, you can click on the workflow run to monitor its progress. It may show as Queued if the runner is not yet available.
     
   • Make sure the runner is correctly installed and active, as it will execute the Flyway commands for the pipeline.

3. Check Logs and Output

   • Click on the individual jobs within the workflow (such as Deploy Build) to view detailed logs of the Flyway commands being executed.
     
   • You should see the Flyway commands running to apply your migration scripts and any database changes detected.

Post-Deployment

1. Review Deployment Reports
   • After the workflow completes, check the deployment reports generated by Flyway. These will show the status of your migrations, any changes that were successfully applied, and any drift or errors detected.
   • The reports will either be part of the workflow output or accessible directly in the repository.
     

Next Steps

Now that your CI/CD pipeline is set up with GitHub Actions, Flyway AutoPilot will handle automatic database migrations across your environments. This setup ensures that changes are versioned, tested, and deployed consistently, helping you maintain control over database development.