One of the cool things I’ve seen with the new Flyway CLI is that I can combine multiple actions together in one call, which can make the process of writing automations streamlined.
I’m not sure I love this, but I’ll show how this works.
I’ve been working with Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.
Making a State-Based Deployment from the CLI
In a previous post, I showed how to use the new prepare and deploy verbs to create a deployment script and then apply it to a database. This is a great way to handle simpler deployments if you want to work in a state-based fashion with Flyway.
That post showed two different CLI calls, which are shown below:
flyway prepare -prepare.source=schemaModel -prepare.target="env:qa" -prepare.scriptFilename="deploymentsFWState__deployment.sql"flyway deploy -scriptFilename="deploymentsFWState__deployment.sql" -environment=qa -executeInTransaction=true
Easy enough, and I like this structure as I’d likely build a pipeline that looks like this, where I prepare the script, then have a manual approval step to check this before deployment:
However, you might argue that someone would check the script in a QA or other deployment, so maybe you streamline things later, or you use this as a QA/test deployment and want everything to run smoothly after a PR.
In that case …
Chaining Commands
I can run this code instead.
flyway prepare deploy …
Let’s see this work. If you look, I have a couple of changes that I can see in Flyway Desktop. There is a table alter and a new stored procedure.
I can streamline the automation of these two changes in the CLI with the code style above with this code:
flyway prepare deploy -prepare.source=schemaModel -prepare.target=”env:qa” -environment=qa -executeInTransaction=true
Here is the pre-execution look at my database:
The execution, which didn’t use a transaction. I’ll have to figure that one out:
And the post database view with the table and proc changes deployed.
I built and deployed the script in one command, and it also appeared to have added my script to the deployments folder. No idea why that happened either.
If you want commands chained, you can do it.
Summary
This post showed how you can chain your prepare and deploy commands together in one command, which might be preferable in some situations.
I don’t know if I like this, or would do it, but it’s not a bad idea. Ultimately, I’d really like this deployment script to be saved back to the repo so I could track it, but that’s going to be some work, and likely that means not chaining commands.
Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today.