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!
     DX

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 (If you don't have one already, no problem, simply create one with your preferred email address)
     • 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.
     • 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 (Flyway Engine) from the list (You may need to select 'Licenses on the left hand side menu)
     • 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 will be deprecated in time, 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.
       
       

       Tip: Flyway Enterprise trials are always available. If you have a contact at Redgate already reach out to them for a free trial to use for AutoPilot. Alternatively head to this link or reach out directly to the AutoPilot team : flywayap@red-gate.com

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 localhost:1433 for database connections. If your databases are hosted elsewhere, modify the connection strings in the YAML file to point to the correct server, instance, and port.
   • Review any additional settings in the workflow that may need customization, such as environment variables or paths.

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.