In this step, you’ll provision the necessary environments by creating pre-configured databases using Flyway AutoPilot FastTrack. This differs from the alternate 'BackUp and Running' AutoPilot version where you supply a backup and multiple scripts.

FastTrack simplifies the setup process by using a single script to create the databases. These prebuilt databases are designed for testing Flyway’s features quickly, minimizing configuration and setup time.

This approach is ideal for testing migrations, CI/CD processes, and deployments, with databases either on SQL Server or PostgreSQL.

Why Use Prebuilt Databases?

By using FastTrack, you:

• Speed up the setup process by eliminating the need for manual configuration or schema-only backups.
• Get fully functional databases for development, testing, and production without complex scripts.
• Can explore and test Flyway’s features with minimal initial setup.

Note: You can run this script on any server (local or remote). If you run it on a server other than localhost, you’ll need to update the connection strings inside Flyway Desktop accordingly.

1. Creating the Databases

With Flyway AutoPilot FastTrack, you only need to run one script to create the databases. Follow the steps below:

1. Open the CreateAutoPilotDatabases.sql script in your preferred IDE (SSMS, VS Code, etc.).
   
2. Connect to the target server where the databases will be created. This can be localhost or a remote SQL Server/PostgreSQL instance and ensure your user account has the necessary permissions to create databases.
3. Execute the script to create the databases automatically.
   

After running this script, you’ll have the following databases set up:

• AutoPilotDev: Development environment
• AutoPilotTest: Testing environment
• AutoPilotProd: Production environment
• AutoPilotBuild, AutoPilotCheck, AutoPilotShadow: Support databases used in CI/CD pipelines.

You now have a fully functional environment tailored for Flyway migration testing and CI/CD integration.

4. Configuring Connection Strings

This step is crucial, as it helps to validate that the databases we created can be accessed by Flyway, with the best location for doing this inside Flyway Desktop. 

To do this:

1. Open Flyway Desktop: Navigate to the project settings.
2. Update Connection Strings: Modify the connection strings to point to the correct server or environment where your databases are hosted.

This flexibility allows you to run the project on different servers or even in cloud environments, such as Azure, by simply adjusting the connection settings.

If you head into Flyway Desktop, you should now see that the error goes away when being refreshed, and can connect to the Databases that we just created! 
It is important, however, that we check the connectivity before moving forward as if everything has gone well, we should be done with the setup! 

To test our connectivity, do this:

1. Open up Flyway Desktop, and click on the settings icon in the top right! 

2. We can edit the connections of both our Development and Shadow (the database used by Flyway for calculations). 

3. It is important that we edit the connection, and update the values to match wherever you created the databases with the script. As mentioned, it is by default looking for a database on LocalHost. If you did this somewhere else, update the connection to point to the server and then test the connection!

4. Once this has been validated, we want to head to the migrations tab, and make sure all of our 'Target Databases' are also correct! 

5. As we did before, edit each of these connection strings and test that a connection is possible! Once this has been done, We should be ready to use the project in its full capabilities!

About the Databases

After provisioning, you will have the following databases:

• AutoPilotDev, AutoPilotTest, AutoPilotProd: These represent a linear pipeline of databases where changes flow from development to testing, staging, and finally production.

• AutoPilotBuild, AutoPilotCheck, AutoPilotShadow: These databases support the CI/CD process but are generally not interacted with directly by users.

Next step > Capturing Schema