Voice of the DBA

Category: Blog

  • The Four Different Types of Flyway Files

    This is documented, somewhat, but I wanted to put this down for myself, as the I don’t love the docs and they are hard to sort through.

    Flyway is open source software owned and maintained by Redgate, my employer. There are also paid versions with additional features.

    The Main Files

    There are essentially 4 different types of files you can use for scripts in Flyway. These are:

    • versioned scripts
    • repeatable scripts
    • baseline scripts
    • undo scripts

    I’ll discuss each of these in light detail below. This isn’t intended to replace the documentation, but give a short explanation of each.

    For each type of file, there is a naming standard, which is the same for all. Essentially, there is are four parts. As an example, I’ll use V8.2__add_new_table.sql to explain this. The four parts are:

    • The prefix for the type of script, in this case, a V script.
    • The version. for my example this is 8.2.
    • The separator, always two underscores
    • The description, add_new_table, in my case.
    • The suffix, which is an extension

    Versioned Scripts

    These are the V scripts, which are named with a V to start. These are scripts which are run once on each target, and intended to be those that change the schema. The “V” is the default, but this can be configured. I wouldn’t change this.

    These are typically the CREATE or ALTER scripts that you run to change objects. You can have as much SQL code in here as you’d like. Think of these as a SQL Compare deploy script. One or my objects changes.

    The run once is nice because once you’ve deployed these, you don’t want to run them again. If you write idempotent scripts, you wouldn’t care but most people don’t do that well.

    Repeatable Migrations

    These are used less in the current Redgate paradigm, but these are repeatable scripts. They are designed to run every time you run “flyway migrate”. Again, the default is an “R” script, but this is configurable. Again, don’t change this.

    These scripts don’t have versions because they execute over and over. This could be used for creating or recreating programmable code objects, like view/procedures/functions/packages. They could also be used for places you need to ensure data is always there or has certain values.

    These scripts run after the migrate scripts, so be aware of that.

    Baseline Scripts

    By default, baseline scripts are “B” scripts. This can be changed. These scripts have a database version that you want to start with for some purpose. Like a new development effort or new deployment project.

    These are run for new environments only, and usually contain all the base objects you might need. If you start a Flyway project on a database that has objects, put all the code to recreate this state (CREATE objects and add data) in a baseline script.

    Undo Scripts

    The undo scripts are the “U” scripts. This can be changed, and these should have a version that matches a versioned script. We can run one of these scripts corresponding to those versions to “undo” changes. Since you can’t really undo anything in the database world, these should include code that reverses the action of the V script.

    Be careful with these, especially if you run these more than a few minutes after the V script. Flyway isn’t checking that you won’t lose data.

    I’d only use these after extensive testing in a pipeline and then only if my deployment broke immediately. These are good for putting in a previous version of a view/proc/function and quickly rolling back.

  • A New Word: Volander

    volander: n. the ethereal feeling of looking down at the world through an airplane window, able to catch a glimpse of far-flung places you’d never see in person, free to let your mind wander, trying to imagine what they must feel like down on the ground – the closest you’ll ever get to an objective point of view.

    I snap these types of photos all the time. This was me leaving Denver for Fort Lauderdale recently:

    2023-06-05 17_11_39-Photo - Google Photos

    Here was last year above Hawaii:

    2023-06-05 17_13_08-Photo - Google Photos

    and leaving Melbourne:

    2023-06-19 11_45_08-Photo - Google Photos

    As I fly, I sometimes think about the world below me, what it’s like from the ground, what it’s like for people who’ve walked there. Sometimes I plan to go someday and see.

    Often, I know I’ll never get there.

    I flew to Las Vegas a few weeks ago, and there are lots of places I could visit that I see, and some I have. However, much of the mountains above Colorado, the desert outside Las Vegas to the East, these are places I’ll never go.

    But I can dream.

    From the Dictionary of Obscure Sorrows

  • Agile West–How Do I Get Started with Database DevOps

    This week I had the chance to deliver a talk at Agile West in Las Vegas. I linked some resources on my blog, and feel free to check them out.

    Tl;Dr – Start with deployments

    After the talk, I had an interesting question from someone in the audience. This person had a lot of developers writing code and then sending to a DBA, who executes it in SSMS. This was for SQL Server development, and that’s a common way many companies deploy database changes.

    Even companies that have software developers who embrace DevOps will still tend to work this way.

    This is error prone, inefficient, and it’s not the way to build better software. We know that DevOps produces better software if you adopt it, and we know that you can’t forget the database. That’s integral if you want to be a high or elite performer.

    My advice for many companies is that they start with deployments. If you have some manual process or DBAs involved, often they’re just running a script you produced in some way. What I’d do is start adding Flyway Community  (or Teams/Enterprise) in and putting those scripts into a folder (hopefully in Git) and naming them as appropriate. That’s a small change for DBAs or Ops people deploying code, but it starts to enable a process.

    From here, I can alter this process to use tooling (Azure DevOps, Bamboo, Jenkins, etc.) and continue to put scripts in a location. Then I can work backwards and start getting developers to build better processes for capturing and saving code.

  • A Short Break

    I’m in the air again, hopefully. I should have taken off about 20 minutes ago for Orlando. This time, however, it’s not work, it’s personal.

    This is a short break, heading off to the AAU Girls Junior National Championships. My last few days with a team of girls I’ve been coaching since January, and many of whom I’ve know for many years. It’s a bit sad to think that I won’t see most of them again on a regular basis Sad smile

    However, that’s the way it goes. Hopefully this week won’t be too stressful as we’re likely placed in a division a bit too high for us, especially with two players unable to make the trip.

    In any case, I’m gone the rest of the week, with a scheduled blog for Friday (another new word), but otherwise, see you next week.