This is a companion discussion topic for the original entry at Getting Started with git Branching Strategies and dbt | dbt Developer Blog
Can you provide more details on hotfix branch strategy, and after hotfix, merge them back to lower env branches?
Can you please provide more detail on how the models are being built or the deployment strategy best to use this? How are you selecting/executing those models that are not in production for your qa/uat branch? I don’t necessarily want to build extra models that don’t have a purpose.
Hey, for hotfix scenarios with lower envs, the pattern should generally follow something like this:
- Create an issue for the hotfix.
- Create a hotfix branch from your production branch
- Implement your changes and perform all relevant tests on the hotfix branch in development.
- Merge the hotfix branch directly to production via pull request.
- Create a temporary branch from production
- For each trunk branch in lower envs:
- Merge trunk into the temporary branch and resolve all the potential conflicts. If there are conflicts, you will be prompted to put these changes on a branch different than the trunk, do this and give it a name.
- Once you’ve completed the merge in the previous step to temporary. Merge the temporary branch into the trunk via pull request. If you have more than one trunk to (mutliple lower envs) don’t delete the source branch. Don’t squash commits at this stage either.
- Verify if the changes work correctly on your trunk.
- If any of the above tests fail and you need to introduce some additional changes - re-open the hotfix issue and start again from step 2 (or create a separate issue if changes are more significant).
This is not the only way to do hotfixes, but usually what I recommend. The way to think about the process for getting lower envs up to date is that you need to take all lower env development that has happened since your last release and add it to your new production state (which we store on the temporary branch). This is a quasi-release in a sense. Once you’ve got all those commits on your temporary branch, you merge it back going the other way to get your hotfix onto all lower env branches.
Hey! Most folks choose to run their entire project in qa/uat if they have the environment. If you’re not really concerned about doing that, then it’s perfectly valid to not have a uat environment whatsoever (dev/prod only is a perfectly valid setup). That said, if you only wanted to run the things that are different between uat and production in your uat environment, you could use similar logic to a CI job (state:modified+) where you compare your uat state to your production state such that you only build the things that have been edited through changes made to your uat branch over the course of a development/sprint cycle (if you operate that way). At this point though, you’re basically operating a scheduled CI job that just targets your uat environment, which likely doesn’t add much value over a CI job that tests development changes against production and merging it directly there!
where/ when do you recommend BI (i.e. tableau, powerbi) developers connect to the models for UAT purpose?