The next page has more detail. This is the text from the facing page:
What we do is very difficult, the current situation is hard to understand ,and the future is uncertain. Mistakes are an inevitable consequence of attempting to get the right stuff done. Unless we can make mistakes visible both individually and collectively ,we will be doomed to mediocrity.
One of the things that I’ve enjoyed about being at Redgate is that we try stuff and we sometimes fail. We talk about those issues in engineering and we do a decent job of an RCA and retrospective that we publish publicly (internally). I like that. Not every group does this, but many do, and lots of groups have influenced others to start or get better.
We’re not perfect, and we know it. However, we are striving to accept those imperfections in others, even as we try to improve.
I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.
The Advocates at Redgate Software had an interesting discussion about deployments in databases and how you go forward or back from the point at which you discover a problem. You can watch the episode, but a few things occurred to me while we were having our discussion.
The first thing is we all agree data makes things hard. A database is a stateful object, and dealing with stateful objects is hard. That is one of the things I’ve internalized the last few years that has tremendously changed how I work with Redgate customers. The more I consider state, the more I am able to work with the challenges that databases bring.
The second interesting thing from the episode for me was that each of us had a tendency for what to do. Do you tend to aim to get to a previous state or move to a new state? Each of us had a preference.
I think lots of us aim for a new state, mostly because we’re optimistic about our ability to “fix” the broken thing. I also don’t think this is a DBA, engineer, or technology thing. I find lots of people in the real world making mistakes and thinking they can do a new thing to fix the situation. Mechanics, lawyers, doctors, plumbers, they all think they can roll forward to a new state.
What’s occurred to me is that the people I know who are very much in demand for their skills and expertise are often the ones with a tendency to roll back to the previous state. They acknowledge the mistake and undo it. I’ve seen people in construction and other professionals also try to go back to the previous state when they realize they are in a situation where their fix didn’t work, and they abandon that plan.
In the DBA world, we might prefer this even when our deployment caused data changes. We often will save data, roll back, and then decide what to do. This often means reconciling data, which isn’t a fun task, but a necessary one.
Watch the episode and decide what your tendency is for adjusting for changes. Do you think about patching the issue and rolling forward? Or do you want to roll back to a known state and re-test our changes in a lower environment.
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.
It’s the Redgate company wellbeing data, where everyone gets the day off. I’m traveling back from Florida after coaching all weekend, so you get to re-read Detecting Issues.
Voice of the DBA 