Voice of the DBA

Tag: FWTips

Friday Flyway Tips–Linking a GitHub Issue to a Code Commit

Recently I was doing a demo and a customer asked how I had linked my commit in Azure DevOps to the work item that existed. It’s easy, and tldr; it’s with the commit comment. This post shows how that 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.

Creating an Issue

Many people use GitHub and adding issues is easy. You go to the Issues tab, click “New” and enter details. What is required might vary by project. I have a public demo project here: https://github.com/way0utwest/FlywayNorthwind

My issues tab has a few items, but you can see one of the issues below. Note, I’m not proud of this, as I just added this for a demo. I didn’t really add enough detail for anyone to work off this. I’ll do better with other issues.

In any case, the thing to note is I have a #1 at the top, meaning this is issue #1. If I type a comment or note anywhere in this project and include #1, a link is created to this issue.

Linking A Commit in FWD

This is very similar to the technique I showed in Azure DevOps. Actually, it’s the same. I’ll make some changes for a products table and generate a migration script. When I go to the Version Control blade, I see the changes and I commit them with a message that includes #1.

In the GitHub code tab, I see my commit message, and the #1 is hyperlinked. If I hover over it, I see the issue.

In the Issue itself, I see a flow with the commit listed.

Now I’m not only tracking discussion and comments of the issue, I’m linking commits as well.

This is less a Flyway Desktop feature than a GitHub one, but you can access this from Flyway Desktop by writing good commit messages with Issue numbers.

Try Flyway Desktop out today. If you haven’t worked with Flyway Desktop, download it today. There is a free version that organizes migrations and paid versions with many more features.

Video Walkthrough

I made a quick video showing this as well. You can watch it below, or check out all the Flyway videos I’ve added:

January 19, 2024
Friday Flyway Tips–The Version Control Blade

The Flyway Desktop Version Control tab is gone and a new blade has appeared in its place. This post looks at the changes and what that means for a developer.

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.

The Version Control Tab

It’s gone. Here’s an old screenshot of what this looked like. It was one of four tabs across the top of a project. Note that this just had the title, with no information.

That’s unlike most other tools that provide VCS features, in that there usually is some status. On the tab, you can see the files to be committed, and push/pull/etc., but you have to select the tab.

We wanted to do better.

A Version Control Blade and Status Bar

We realized that version control isn’t really part of the workflow of Flyway Desktop; it’s a separate function. We also had lots of requests to help developers know there are changes in the repo to commit, push, etc.

We’ve been testing this for some time as a feature flag, which was annoying because I’d see the tab and the blade, but it released recently. I’m not sure which version got this, but it is in 7.0.3.

You can see it below, on the right side. Note that we have an arrow at the top to expand this. We also have a branch icon, a refresh, which tells you the last time something push/pull/fetch’d, and then there are down arrow (remote commits not pulled), a circle with a line (uncommitted changes), and an up arrow (commits to push).

If I select the object listed, and click Save, I’ll see this after the operation completes I have an uncommitted change. Notice the “1” in the middle of the blade.

I can expand the blade, but I can just click the one (or icon) and I see the blade expand. From here, I can add a commit message and commit this change (if I select it).

I’ll make another change, generating a migration script. Now my expansion shows 3 changes, the schema file, the migration script and the undo script.

I’ll commit these three as one item. My blade closes after this and I see a committed change to push.

I’ll generate another migration script. In this case, I now see multiple changes. I see my two new migration scripts added, and I still have a commit to push.

If I expand the blade, I can see the details. For example, on the push tab, I can see the commit and files included. For a small screen, or small window, I get a tooltip if I hover and can see the full file name and path.

If I make a change in the remote, likewise, I’ll also see a commit to pull.

I’ll push and pull (and commit) and then I’ll see a clean list nothing in my VCS blade.

Summary

This isn’t a big change, and I’d argue this makes FWD much easier to use and more comfortable for many people. Developers are less likely to have their local repo out of synch with a remote.

Try Flyway Desktop out today. If you haven’t worked with Flyway Desktop, download it today. There is a free version that organizes migrations and paid versions with many more features.

Video Walkthrough

I made a quick video showing this as well. You can watch it below, or check out all the Flyway videos I’ve added:

January 12, 2024
Friday Flyway Tips–Linking Commits to an Azure DevOps Work Item

Recently I was doing a demo and a customer asked how I had linked my commit in Azure DevOps to the work item that existed. It’s easy, and tldr; it’s with the commit comment. This post shows how that 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.

Creating a Work Item

In Azure DevOps, there is a board menu. Under here, one of the subitems is Work Items. You can see these below:

I tend to work from the “Boards” item, which looks like this:

Let’s assume we have a new item, so I’ll click the “New Item” at the top of the left column. This gives me an edit box, which I’ll type in a name.

When I hit enter, this gives me a new work item, which you see below, as 250 create products entitty.

Since I don’t want to leave a spelling error, I’ll edit the title to look better. Now I have a work item.

Linking A Commit in FWD

In SSMS, I’ll create the products table. Once I do this, I’ll go to Flyway Desktop and refresh the schema model. When I do this, I see my change. I’ll select this and save to the file system.

Once this is done, I’ll go to the Version Control tab, and I again see my file changed. Here my file is selected, and I’ll enter a commit message, but I’ll include the work item number after a #. This creates a link.

I now click commit and push. In Azure DevOps, in the Repos –> Commit item, I see my commit.

Note the details item under my cursor. If I click that, I see commit details and near the bottom, a link to the work item.

If I click through to the work item, or I access the work item from Boards, I will see my commit linked on the far right of the work item.

This is very handy to have your actual code linked to the work that it relates to. If I have PRs or multiple commits, as long as you use the #nnn, where nnn is the work item, you’ll have everything linked together.

This is less a Flyway Desktop feature than an Azure DevOps one, but you can access this from Flyway Desktop by writing good commit messages with work item numbers.

Try Flyway Desktop out today. If you haven’t worked with Flyway Desktop, download it today. There is a free version that organizes migrations and paid versions with many more features.

Video Walkthrough

I made a quick video showing this as well. You can watch it below, or check out all the Flyway videos I’ve added:

December 29, 2023
Friday Flyway Tips–Above Target Migrations

Recently I was working with Flyway Desktop (FWD) and practicing deploying certain migrations and not others. I don’t recommend this, but a customer was doing this and I wanted to reproduce some things they were trying to help them.

In doing this I discovered a bunch of scripts marked as “Above Target” in the GUI, but not in the database. I learned a few things from our support team.

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.

Setting a Target

I’ve got a FWD project here, and you can see the migrations below. In this case, I’ve selected a target of my QA machine and we can see that I have migrations applied up to 3.1 and there are pending migrations from 4-8 (ignore the undo).

Now, I want to migrate QA, but only to version 5. When I do this, from “Advanced Settings” on the right, I’ll see the target is listed as a parameter, and if I’ve highlighted the parameter on in the script.

I’ll run migrate, which works.

When I close this, I now see a different view. I see success next to migrations 4 and 5, but I also now see “above target” listed for the other migrations.

That’s not great, for this reason. If I check the “only show pending migrations”, I lose all my migrations. In large, complex projects, this isn’t good.

Getting Pending Migrations Back

The easy solution to this is to remove the target. If I click the “x” on the target parameters…

And then click Refresh at the top, I now see my migrations as pending.

Seems obvious, but I’d forgotten about the target as I was focused on testing the code I’d released and then wanted to release other code. Peter in support educated me on what I was missing.

Try it out today. If you haven’t worked with Flyway Desktop, download it today. There is a free version that organizes migrations and paid versions with many more features.

Video Walkthrough

I made a quick video showing this as well. You can watch it below, or check out all the Flyway videos I’ve added:

December 22, 2023