Redgate Flyway Enterprise

My main use case for Redgate Flyway  is to maintain the database structure, especially when coding with other developers, and I view it as a version control system for databases, similar to Git .

A specific example of how I have used Redgate Flyway  to maintain the database structure is in starting out a project, where I have used two flavors of it, writing raw SQL queries and also using the Java class version of SQL queries. I started from scratch because we needed to ensure that other teams see the update of the database since we are all coding differently. Once you pull, you notice there is a new migration and have to run that migration to maintain the update of the database. We built it from scratch and used the raw SQL queries.

Redgate Flyway is used at every level of the project. If there is a new column added, I have to update the SQL query migration. If there is any constraint change, table creation, or indexing to add, I have to include that in the Redgate Flyway migration. Once that is pushed, our database team gets a notification that the tables or the database have a new entry, and they also do reviews. Once anybody pulls the code, that person also gets the new migration change.

The best features Redgate Flyway offers are its usefulness when working with other people, as it maintains consistency in database changes, and it is helpful when shifting databases because Redgate Flyway provides the migration script that can be run in different environments without needing to rely on Spring  auto updates to create those tables. It is a well-structured tool for managing table creations.

Managing migrations across different environments has been quite easy for my team to adapt to and use Redgate Flyway without any challenges. We recently moved from a Docker  database to an actual database in a different environment, and it was easy for us to share the migrations. Once they were done running them, we shifted connectivity to their environment and everything worked without issues.

Redgate Flyway has positively impacted my organization by maintaining consistency among developers. One real added feature is using migration tools, which allows rollbacks although I think rollback has some bottlenecks. I acknowledge that Spring Boot  does not have a migration tool by default unlike Entity Framework in C#, but having Redgate Flyway is becoming a default tool for migration in Spring .

Redgate Flyway can be improved by looking at all circles of software development so that if someone did not start with Redgate Flyway from the beginning, they should not experience issues starting in the middle or end of the project. A review on that cycle for people using Redgate Flyway would be beneficial.

I rate Redgate Flyway seven out of ten mainly because of some issues when introducing Redgate Flyway in between projects instead of from inception. Sometimes, errors with migrations can be very disappointing, as often it requires deleting everything and starting over. Additionally, maintaining the versioning of the scripts must be done very carefully, which requires some experience when using a specific pattern such as date-time to prevent clashes when another person is updating the database. This necessitates a learning curve.

I have been using Redgate Flyway for approximately four years.

I consider Redgate Flyway stable to an extent, around eighty to ninety percent.

The scalability of Redgate Flyway is good.

I have not had any issues with customer support at Redgate Flyway, so my database team would be better equipped to answer that.

I previously used Liquibase  and switched to Redgate Flyway because I had to follow the company's requirements, as most companies I have worked with use Redgate Flyway.

Regarding maintaining consistency and rollbacks with Redgate Flyway, I have luckily not had many issues. In the past, I sometimes had to delete all migrations trying to recreate them. I do not think it is really smooth when you have already started the project and want to now introduce Redgate Flyway halfway through. While I cannot remember the exact scenario, I know it was not smooth. It is usually better to use it from the beginning of the project, though it is a bit more complicated in between projects.

We have independent work with a separation of roles. We have those maintaining things concerning databases and a team that manages pricing, while my job role is primarily focused on writing code.

I see a return on investment with Redgate Flyway, as it is leading compared to Liquibase  and others, and most teams I have worked with utilize Redgate Flyway, which is definitely pointing in the right direction.

My experience with pricing, setup cost, and licensing is that we have independent work with a separation of roles. We have those maintaining things concerning databases and a team that manages pricing, while my job role is primarily focused on writing code.

Redgate Flyway is a tool that works, and I have not had many issues with it. My advice to others looking into using Redgate Flyway is that it is a good tool, especially when the development team is large and you want to maintain database integrity, consistent updates, and also handle migrations, as Redgate Flyway has become a default tool to use.

Regarding Redgate Flyway's artificial intelligence capabilities, I have not really examined artificial intelligence with Redgate Flyway. Security is a general issue, but I have not faced any security issues with Redgate Flyway and have not looked into Redgate Flyway's artificial intelligence capabilities. I have not actually looked at it or its accuracy and reliability of output recently, but it is something I would like to explore.