Tag: Flyway

I’m really excited about some growth in Flyway support. I’ve been asking about this for some time and we now have Databricks and Snowflake support.

I’ve been working with Flyway and Flyway Desktop and helping customers improve their database development. This series looks at some tips I’ve gotten along the way.

Analytic Platforms

There has been tremendous growth in the usage, and the capabilities of many major analytics platforms. A few years ago Snowflake was the dominant platform, but Databricks has grown quite a bit. I still don’t see a ton of Fabric usage (outside of PowerBI), but it’s on our radar.

I wanted to note that both Snowflake and Databricks advannced capabilities  in Flyway have moved to General Availability (GA). Both capabilities were developed quickly, with the help of AI. We knew what we wanted, we’d designed this, and our engineers were porting over functionality we knew how to build, guiding AI to get the work done quicker than humans typing.

Both of those platforms help with managing notebooks in a software development lifecycle, but they don’t do much for schema changes. Esp if you don’t want a desired state configuration, which can be complex to manage in a team world.

When I create a new project, I have options for Databricks:

and Snowflake

You can read about the advanced capabilities for Snowflake and Databricks, and then start getting those teams to use a well tested, tried-and-true, repeatable, reliable deployment process in Flyway. The same way you do for other platforms.

Summary

I’ve been wanting us to add capabilities for these platforms for some time. Thanks to all customers who’ve provided feedback as that helped us press the teams to prioritize the analytics work.

If you work with Flyway, and you are looking for other platforms, please email a request to your AE or sales@red-gate.com. Those emails, with the details of the need and size of team help us get work done.

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.

It’s a small change, but a handy one. Flyway Desktop (FWD) now includes the object history for different schema changes, so as you are evaluating how your changes might fit in with others, or you are trying to determine where something broke, you can see a list of historical changes. This post looks at checking history quickly in FWD.

I’ve been working with Flyway and Flyway Desktop and helping customers improve their database development. This series looks at some tips I’ve gotten along the way.

Checking History

In Flyway Deskop, I can see all of my objects on the Schema Model tab on the right side. Here I’ve selected CustProc in the list, and at the bottom I see the current version of the code. However, if you look where my cursor is, there’s a small clock there.

If I click this, I see a blade pop out with history. On the left, I see the various versions. At the top, I have the uncommitted change I just saved. This is shown as the older version on the left, which is committed in Git. My new changes are on the right, with green shading to highlight what I’ve changed in code.

However, maybe I wonder what was the previous change. If I click the top commit (c398a9d), I see this view. Note the red shading on the left, which are the columns I removed. I also have the green shading on the right, where I’ve added a comment and removed a comma. My commit message is at the top with my name and the time (upper right).

I can flip through the various history iterations of code here, just as I did with Git, but I can do this while I’m doing development work in the same place I’ve capturing changes.

I have a “go to Version Control at the top as well, which opens the VCS tab. Here I can commit the change.

Once I do that, my change appears as a new commit for this object in the history.

AI Sparkle

It can be easy to sometimes see the changes made by a developer and understand them. However, sometimes there are complex changes, or you don’t notice something. Here I’ve got a more complex object history.

In the upper right, there’s an AI sparkle next to the “Explain this change”. If I click that, and have AI features enabled, I get an explanation. I’ve zoomed in to see this at the top.

This is a summary of the changes, which in the chaos of work, can be helpful. I get a quick summary.

I wouldn’t just trust this, but instead this guides me along the code to look at what’s been removed and added, and this summary helps me double check that the code does this, and that I understand it.

Summary

This a small improvement, but one that keeps you focused on the work: what changed. No hunting down the changes in Git or changing somewhere else. This also is easier to see than a git diff for me. It also gives me a quick summary where there are a lot of changes.

If you work with Flyway, update your desktop and give it a try. We would love to hear your feedback.

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

Watch me do this in video:

At the Redgate Summits this year, we’ve highlighted a few things in the Flyway solution that help developers improve their ability to get work done safely and quickly. While lots of developers are moving to automated systems and catching issues in pipelines, plenty of you are still working in an IDE.

This post looks at the new code analysis feature in Flyway Desktop that can help warn you of potential issues before you create that PR.

I’ve been working with Flyway and Flyway Desktop and helping customers improve their database development. This series looks at some tips I’ve gotten along the way.

Generating Good Migration Scripts

Flyway gives you determinism and consistent scripting when you generate migration scripts. Plenty of developers still do this manually, often after a lot of work and testing is done on the schema model. Once you’re sure of the changes you want to make, you can select those changes to include in a deployment.

As you can see below, I have a lot of changes, but I want to just pick one to put into a deployment.

If I click on the change, you will see that this is simply adding a new column, something developers do all the time. I’ll select that and click “Generate Migrations”

When the tab changes, the default screen shows the next numbered migration script, based on my patterns and a default description of my name. Note that there is also a “Code review checks in progress” item to the left, which is running as the code is generated.

Once this completes, you can see my code rules passed, and the Flyway AI has generated a better description of the changes than I might have typed in.

There are a number of rules by default, and these are run when the migration script is generated. You can change, add, disable, customize, etc. for these rules as appropriate for your project.

Let’s go back and select a different change. In this case, I’m selecting the “Grant” table and dropping it. It’s in the current view of the db, but not the next one.

When I click Generate Migrations and go to the next tab, you can see that the code review shows me two things: a high severity error and a warning. These are summarized at the top next to the “2 issues” button (which hides or reveals the details) as dots. If I had a lot of issues, and some of you do, this gives me a quick look.

Below that I get the details. Both of these are for the same line, which is highlighted in the middle by a triangle next to that line.

If I click the High Severity item, I have the options to learn more, which links to the actual rule on the Redgate documentation site. Or I can ignore it. This allows me to comment in the code to not run this review again.

For the warning, since this wouldn’t stop a deployment anyway, I just have a Learn more link.

There are certainly times this might be the desired action, so I like the ignore button. However, much of the time developers might be making changes to objects and not thinking about potential future issues. Code review here catches things early, before others have to get involved, and helps educate developers about the styles and standards we want enforced in our projects.

If you work with Flyway, update your desktop and give it a try. We would love to hear your feedback.

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

Watch me do this in video:

One of the nice things about Flyway Desktop is that it helps you manage your database code as a project and see what changes are being built. However, many of our customers end up working with multiple databases, so there is a need for multiple projects.

This post looks at the new addition to the GUI: the ability to work with multiple projects at one time in the same GUI.

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.

Opening a Project

Flyway Desktop (FWD) used to only allow one project to be open at a time. This proved cumbersome. We debated allowing multiple instances of FWD, but keeping track of them can be cumbersome. We decided to allow multiple projects inside the same FWD instance.

You can see this below, where I have three projects open at once. I have Northwind, a Synapse project, and an Autopilot project. These are listed across the top as tabs, and clicking each brings that project to the front. The current project is showing the Autopilot one.

If I click the Northwind project, notice the little red underline. This indicates the project being shown.

To add a new project, I click the plus (+) at the top to the right of my projects.

This gives me a list of my projects, the same way I’d see them when I started Flyway Desktop. Notice the 3 I have open are listed first, as they were most recently touched.

If I click any of these projects, like my SimpleTalk_Timestamp project, it opens up. As with any project, the comparison on the Schema Model tab starts automatically.

Now I can switch projects quickly with a click, and my existing projects don’t close.

Summary

This is a small change, but one that has a big impact. The teams are constantly working on small and large changes like this. The ability to manage multiple projects is one that’s been requested and we were working on it, testing designs with customers and finding the best balance for most of them.

We settled on multiple projects in one GUI, which I like and seems to be working well.

If you work with Flyway, update your desktop and give it a try. We would love to hear your feedback.

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

Watch me do this in video: