Redgate Flyway Enterprise

The main use case for Redgate Flyway  is that previously we had to manually manage our different environment database scripts. We are using a .NET application with a Dapper back-end, and we have numerous SQL objects including stored procedures, views, table scripts, and DDL and DML scripts each time we deploy. We needed to manage scripts for the development environment, then for the staging environment, then for production, and that caused too much discrepancy and human effort during the release. After learning about Redgate Flyway , we started using it and have managed multiple environments within it. Redgate Flyway provides support for different branches, allowing us to manage our scripts with each script recorded with a version number. This has reduced the discrepancy in our deployments and accelerated our procedure significantly. The human effort required has become considerably less.

Regarding how Redgate Flyway fits into my workflow, as a team, we always wanted to automate or record everything we do and maintain transparency. From the database side, we needed a tool that transparently shows what developers have done and what we will take to production deployment. Redgate Flyway aligned with our needs in this way. Our next target is to create pipelines for Redgate Flyway, but it is currently working well for us. We have set up different environments in Redgate Flyway and it is functioning properly. We have a repository on GitHub  and we push and pull from there.

Redgate Flyway has positively impacted my organization in achieving significant improvements. I would point out a specific improvement that even our client has recognized. We are a service-based company and our client is located in the US with a considerable time difference. Their downtime starts around 11:00 p.m., which is our morning at 7:00 a.m. or 8:00 a.m. Previously, when we deployed things manually, discrepancies occurred and we had to spend long hours fixing them, ranging from two to three hours or more. Our client also suffered from these issues. Now, after using Redgate Flyway, we have very specific scripts and know exactly what we will deploy, with approximately 99% chances of success. Today was a release day and I was involved in the release in the morning, and it was extremely smooth. The client praised us and gave us positive feedback. On a company level, we are introducing the same practice to other teams as this tool is helping tremendously. We developers are paid on an hourly basis, and if we spend our hours fixing unnecessary issues, that is not actual development. It is a form of technical debt that affects the company's revenue. In this way, Redgate Flyway has helped the company, the client, and the developers.

The best features that Redgate Flyway offers, if I had to pick a few that really stand out, would be multi-environment support. On the migrations tab, I do not need to go to an environment and change settings or anything. I simply change the branches of the environment and it shows me what is available and what has been run on a certain environment. The environment feature is very user-friendly and helpful, so I would keep it at the top of my list. The feature of changing branches on the migrations tab is very helpful.

An example of how Redgate Flyway specifically helped with discrepancies is that previously we did not have any tool recording database changes. We work on an Agile Scrum pattern, so we have to do deployments frequently, within every two to three weeks or sometimes four weeks. Previously, we had code repositories for front-end and back-end, but for the database side, we did not have any repository. We were not saving database-related changes in any GitHub  or AWS CodeCommit  repositories. Every time, we have a Jira  board where developers update their scripts. For example, if I work on a ticket and update a stored procedure, I must mention the stored procedure on the ticket. When deployment time arrives, the release manager must pull out or scan all the tickets and extract the objects. For example, if we deploy 10 Jira  tickets from a sprint in the next release, we must go through all 10 tickets and see the post-deployments of their tickets. Then we extracted the objects from the development environment, deployed on stage, and then deployed on production. In this scenario, many objects and discrepancies occurred. Sometimes a developer or the release manager would forget the object to take to production. Now, after using Redgate Flyway, I have restricted access as the release manager of my team. I manage the release for my team and have restricted developer access to environments other than the development environment. If developers want to take anything to the next environment such as demo, staging, or production, they must make a script. When they create a script, it is in our record. Now, after using Redgate Flyway, we do not need to scan all the tickets on Jira or see the post-deployments of each ticket. We simply view the Redgate Flyway script showing what has been run from this to this version, and what pending deployments need to be run on production. In this way, it has helped tremendously.

I can share that the migrations tab and branch changing helped my team in a specific situation during our second last sprint. Two developers were working on the same object, and one change needed to be deployed on stage while another change needed to be deployed on the demo environment, which is our QA level. Our QA and demo are the same environment, and then we have stage and production. We have three environments other than development. Previously, without Redgate Flyway, what could have happened is that we would take the stored procedure from demo if we needed to deploy it on stage and take it directly to stage. This was our previous practice where we would go to the database explorer, take the stored procedure, and move it to the next environment with the ticket. Now with Redgate Flyway, we have different versions of that stored procedure. We simply took the version of the stored procedure that needed to be on stage, and the second version that needed to be on the QA level remained there. Redgate Flyway helped in this case, and we have many cases.

Redgate Flyway can be improved in a way that sometimes I experience loading time or migration time issues. If there are any conflicts in versions or version numbers, there should be an option to fix it through Redgate Flyway. Sometimes we experience conflicts with version numbers and need to run repair and other functions. The feature of version numbering and loading time could be enhanced. The rest is working well.

I have been using Redgate Flyway for the last seven to eight months.

Regarding Redgate Flyway's consistency, it has been consistent for me. Over the seven to eight months I have been using it, it has remained stable.

I can share specific metrics regarding how much time was saved during releases since using Redgate Flyway. During our normal release, there are around 20 to 30 Jira tickets that we take to production, typically representing two sprints or sometimes three sprints. Previously, the release manager and developers had to sit together and check all the post-deployments of these tickets, then extract their object names into an Excel file or some other file. They created a filter file to filter out stored procedures from the staging environment and pulled all objects such as stored procedures, tables, and alter commands. They kept everything on a separate file and consolidated it. On deployment day, they ran it on the production environment. The extraction of objects, filtering from the database, creating a file, maintaining an Excel file, and communicating with each developer used to take around four to five hours or more, and could sometimes take a whole day for developers and the release manager as well, especially if a developer questioned whether a change was theirs. Now using Redgate Flyway, we do not need to do any of this procedure, so this whole process has been eliminated. Almost a day is saved through Redgate Flyway. On release day, when the release database scripts run using Redgate Flyway, there are 99% chances that the scripts will run successfully without issues. Over the last seven to eight months, we have not faced any issues and the client has praised us. Previously, it was a normal practice to take the script to the production environment and run it, and it was normal to have errors including syntax errors or object errors. We would fix these errors and two to three hours or sometimes four hours of developer time would be spent on release day. Overall, around 10 to 15 hours have been saved from using Redgate Flyway, along with reduced human effort.

There is nothing specific to add regarding needed improvements.

The advice I would give to others looking into using Redgate Flyway is to integrate it properly through pipelines and manage it properly. If you are using Redgate Flyway, you must not update any objects or scripts manually so that you can achieve 100% of what Redgate Flyway can provide.

Regarding additional thoughts about Redgate Flyway before we conclude, I cannot think of anything right now. Everything is working well currently.

I would rate Redgate Flyway overall as an eight on a scale of one to ten.

The reason I chose an eight rating is that Redgate Flyway is providing tremendous support and helping in different scenarios, but there could be some improvements. For example, if we want to attach it through code pipelines or connect it with our code, something could be added. Currently, we are using Dapper, but if we go to Entity Framework Core, there could be some connection. We have a connection with our entire system including the front-end, the back-end, the repository, and the AWS  infrastructure, but Redgate Flyway seems to be an isolated system in itself. It is not connected with anything else and is just for the database. If it could connect with other tools as well, that would be beneficial. However, this is just my opinion and I cannot comment on the science behind it.

Regarding Redgate Flyway's security and governance, they are normal. We have other tools and applications that are enterprise-grade providing general security and governance. I cannot say that it is highly secure, but the features are good. The security aspect, where we have to log in through our SSO  and corporate emails, is quite better. It is similar to other tools we are using, such as GitHub and AWS . The intelligence of Redgate Flyway is quite better, but there is nothing such as bots working for me. I would not say that this is great in AI or artificial intelligence.