Automated database releases have reduced errors and now save a full day of deployment effortThe 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.
