It is possible to add/edit Deploy Rules after your Migration Script has been saved. On the Migrations scripts, tab click on the Migration in the Migrations table to view the script at the bottom.  You can then add/edit/remove deploy rules and update the shouldExecute expression.

Note: Changing a Deploy Rule will not have any impact if the script has already been executed against an environment and there will not be a checksum warning on Flyway validation.

Configured Environments

For environments that are already configured in your Flyway desktop project, select the environments you want the migration to run against in the dropdown in the Migration script view:

Custom Environments

If you want to run the migration script against environments that aren't configured in the project, you will need to edit the shouldExecute parameter in <migration>.sql.conf file:

shouldExecute=${flyway.environment}==custom

This will appear in the dropdown in the Migration script view.  If deselected, it will be removed from the dropdown and removed from the shouldExecute parameter because it's not an environment configured to the project.

It is possible to include multiple environments that you want the script to run in:

shouldExecute=(${flyway:environment==dev}||${flyway:environment}==custom)

This will show in the dropdown with dev and custom environments selected:

Note: Please ensure this environment exists outside of the project.  Otherwise the migration will run against the environment, which is not what you were expecting. 

Running migrate

The Test1 and Test2 migration scripts have Deploy Rules that specify only execute if the environment is develop or target1 respectively. Since the Development database is the selected target, Test1 script has a status of Pending, and Test2 is ignored.  The pending migration script will be applied to the target database if you ran the migrate command. 

Following running the migrate command, Test1 successfully ran against develop and Test2 was ignored as intended.