I was chatting with the product managers at Flyway and one asked me whether I’d seen the new tab for Automation in Flyway Desktop. I hadn’t and decided to take a quick look at how this works and what’s useful. This post looks at the new feature.
Tl;Dr this is a good way to start learning how to move to a more DevOps, automated way of deploying changes.
I’ve been working with Flyway and 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.
Working with Flyway Desktop
For a lot of customers, it’s not too hard to setup a project and start to capture code in a Git repo. However, adding in automation gets challenging for many, especially as the docs are hard to understand if you don’t already have some knowledge. I find that CI/CD is a bit of a chicken and egg challenge as we try to learn to get better, but knowing what to learn and do requires knowledge.
Which we don’t have.
In any case, I’ve taken an existing Flyway project where I am capturing some code. You can see the project below, with objects on the right. The database and the repo have the same object code and are in sync.
Let’s add a few new objects to this database in SSMS. You can see below I’m adding a new table and altering a proc. I’m also refactoring slightly to not keep the old style join convention in my proc as I add a new join.
Once I do this, in Flyway Desktop (FWD), I see my changes. I’ll save these to the repo and then generate a migration script. I won’t show that as it’s not important.
Once I’ve done this, I know I want to deploy code. If I go to Migrations, I can see I have these two scripts ready to go to QA, and I can deploy them with FWD manually. However, I don’t want to do that.
I want some automation. How does FWD make that easy? Let’s see.
The Automation Tab
There’s a new tab on the left, which is the Automation tab. I’ve expanded the left menu out and you can see it, but it’s a lightning bolt, which I might never have noticed (hence this post).
If I click this, I get a little explanation at the top, a few links, and then some CLI based code. This last part is the important part of what I need to move to CI/CD.
If you look at the code closely, you’ll see some placeholders in angle brackets for the environments I need. The code looks like this:
Above this, there are two drop downs where I can select my build and target environments. Build is the CI portion, and it’s a good idea to have a place to build code separate from QA. This lets me validate things, and more importantly, run some code analysis checks, summarize changes, and detect drift.
I’ve expanded the Build drop down below and you can see I have my environments listed, and I can also manage them from here. There is also an Environments tab on the left menu just above Automate Deployments that looks like a database icon.
Once I select an environment, the code changes to reflect this. That makes things easier to automate as I can take these commands and drop them into a task in my CI/CD tool.Note in the image below that I’ve selected NWInt and the code shows target2. The code needs the ID (or PK) of the environment, but the display name I entered is shown in the drop down. Trust me, these match.
I’ll also select a target and then open up a CLI to run the first item on line 5. I did have to auth, but this runs successfully. No doc checks, no experimenting, the command ran.
I’ve never saved any snapshots and so the drift doesn’t work right away, but I’ll get the dryrun script. When I run this, I get a summary from the CLI.
Then I can see the report (see above output for the path at the end. When this opens, on the Dry Run tab, I see my scripts.
Note, I did use the drop downs in FWD to select the environments I need for this.
Very cool.
Summary
One of the challenges with using Flyway is that there are a lot of settings, options, and more that one must learn to take advantage of the solution. Our docs continue to improve, but even for someone that has been using Flyway for a few years, I have to constantly check out things work. Plus, the teams are adding features on a regular basis, so it can get confusing to learn the new things.
This automation tab is really helpful to shortcut some of the things I need for the various environments in my project. I’m going to start using some of this in a new project, and so should you.
Flyway can do much more, and for smoother automation, check out Flyway Enterprise.
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. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.
Video Walkthrough