Options
Ready Roll with feature branches
Hello,
We currently use Ready Roll with "git-flow" https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow i.e. each development feature is created in it's own branch, however since these features are merged into the common development branch in no particular order we run into a lot of issues with the RR shadow database having data that is in other branches, which is especially troublesome when multiple features require modification of the same table.
Do you have any plans to support branching workflows like git-flow? Or even better is there already some support for it that we aren't aware of?
Thanks!
Luke
We currently use Ready Roll with "git-flow" https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow i.e. each development feature is created in it's own branch, however since these features are merged into the common development branch in no particular order we run into a lot of issues with the RR shadow database having data that is in other branches, which is especially troublesome when multiple features require modification of the same table.
Do you have any plans to support branching workflows like git-flow? Or even better is there already some support for it that we aren't aware of?
Thanks!
Luke
Comments
I'm sorry to hear that you've run into some issues with merging your database changes.
In terms of way you can mitigate the problem, there are a couple of options you might like to explore:
1) Use Semantic Versioning
ReadyRoll allows you to put an extra level of structure around the organisation of your migrations, in order to better control the order of deployment.
If you're not already using semver in your ReadyRoll projects, you might like to switch it on and create a folder for each of your feature branches. More information is available here: http://doc.ready-roll.com/display/RRSQL ... Versioning
2) Deploy static data using the "desired state" approach
If some of your tables contain data that is frequently changing, you might want to consider switching to the declarative data change method, using the appropriately-named "MERGE" T-SQL statement. This approach allows you to re-use the same script file for all changes to a given table's data. You can read more about this within the "Editing Static Data Offline" section of the following article: https://documentation.red-gate.com/disp ... tatic+Data
It would be great to hear any feedback on whether these options might work for your team, or if indeed you've already tried them.
Product Manager
Redgate Software
Sorry for the delay in getting back to you, I didn't see a notification you'd replied.
Our team actually already makes extensive use of the Semantic Versioning feature for each release that we do, however with git-flow we have many very short lived branches, so it wouldn't make sense to have a separate folder for each branch.
I looked over the documentation for the MERGE option, but it doesn't appear that it would work well within our workflow, I'll definitely work with the rest of my team to see if we can incorporate it though.
Is there any chance that the https://readyroll.uservoice.com/forums/ ... ogic-to-be feature request will be landing anytime soon? Then at least we could wire up git to automatically run the up/down scripts when we change branches.
Thanks for your help!
Apologies that you didn't get a notification about the post, and thank you for clarifying that you're using semver already.
May I ask, in terms of the workflow for the MERGE solution proposed, is the issue there that it would force you to follow an "offline" editing approach? i.e. that you wouldn't be able to readily import the static data from your database? Management of static data is definitely something we're keen to improve in the product in future, so it would great to hear whether you have a preference for online vs offline static data editing.
In terms of the automated "undo" scripting functionality, we don't have any immediate plans to implement this. The main challenges with this feature are validating that the "down" scripts in-sync with the "up" scripts (e.g. if they are manually changed) and orchestrating the back-and-forth motion between the database states. To keep the deployment logic as simple as possible, ReadyRoll prefers a forward-first approach. When switching branches, we recommend dropping and recreating the database from scratch, or alternatively, restoring your database environment from a "gold" backup after switching branches.
If these approaches are not workable for your team, ReadyRoll offers some alternative approaches that allow you to preserve the state of the target database when switching branches:
1. To undo changes to programmable objects, simply deploy the database project from the target branch. This will automatically deploy the correct versions of procs, functions, views etc. Note that you'll need programmable objects setup in your project for this to work. This works in both Visual Studio, continuous integration and deployment. See more here: https://documentation.red-gate.com/display/RR1/Programmable+Objects
2. To undo changes to stateful objects and static data within Visual Studio, you can use the DbSync tool's "Revert" feature to do this. Read more here https://documentation.red-gate.com/display/RR1/Switching+branches .
3. To undo changes to stateful objects during continuous integration, setup drift correction on your build server. After switching to the target branch, this can generate a script to roll back changes to tables, security objects, etc. It can be optionally configured to automatically apply the changes to your target server. See more here: https://documentation.red-gate.com/display/RR1/Managing+Schema+Drift
I hope this helps.
Product Manager
Redgate Software