During the past few days I have struggled with how to handle versioning and our branching strategy while using Azure DevOps, so I decided to find some more information regarding how Microsoft does it..
However.. the versioning-part isnt really shared anywhere from what I have seen.. but I just watched how they handle branching over at this video:
Git patterns and anti-patterns for successful developers
However.. the part I dont quite get is.. its quite common to have your verison of your product configured as variables in your yaml. So for instance, during development you might have the following variables setup:
variables:
Major:1
Minor:1
Patch:0
Now lets say that we release version 1.1 and create our release-branch according to the above "relase flow" git stratgey.. we would once the release branch is created "bump" the version in our master-branch to for instance:
variables:
Major:1
Minor:2
Patch:0
Now.. all new code thats branched of master would end up with version 1.2.0.. however.. if we suddenly need to hotfix our production code, the release flow branching stratgey mentioned in the video would branch of master for our bugfix, this would give us a branch which has version 1.2.(1), but the minor and major we actually are trying to "patch" is 1.1... so as suggested by the video, if we now PR our bugfix into master and our release-branch, we would also not just patch our prodiction code with the bugfix, we would bring it up to a new minor-version.. which I would argue is not a prefered way of versioning the code, since the "logical" verison for our new bugfixed production-code would be 1.1.1
Any ideas of how this is solved?
The way I understand it in the release flow org site, if you cut a release branch to correspond with what is in production, your maintenance work (i.e. hotfixes/patches) happen on the release/1.1.0 branch. You then apply the same fix to mainline (e.g. master). See the following diagram:
Furthermore, if you want to avoid full branch merges to propagate fixes to mainline and other release branches, git cherry-pick is your friend. Just cherry-pick the commits into another hotfix off of mainline or another release branch and make any adjustments needed to get it working with that version of the code.
Cheers!
Azure DevOps and Release flow, hot to handle versioning when hotfixing?
If the minor and major we actually are trying to "patch" is 1.1 and you do not want to patch production code with the bugfix branch, we could try to merge the master branch to the hotfix after completing the development work, give the version 1.2.1.
After completing the above PR, we could merge the hotfix branch to the master, then we went back to our previous scene:
Now, we could forget the hotfix branch and continue to develop and release on the master branch.
Related
I'm currently attempting to move my team to this gitflow workflow and I am wondering if it's best to merge my release branch into my master branch once it's ready to go live or replace my master branch with my release candidate branch altogether.
We're doing all of our regression testing on the release candidate branch and are worried that my merging it into master it may affect it in some way making all of our regression testing ineffective.
Anyone ever had to deal with this before?
What you describe is a standard Git Flow, though the Atlassian documentation doesn't seem to clearly illustrate this part of the process. What you'll want to do is merge the release branch into your master branch, making sure to tag it:
You shouldn't 'replace' your master branch with the release branch. Your master branch is the 'core' of your project, and the master branch should be always be the 'last know good point', as you only ever push to master from either a release, or when there's a severe production bug and you're adding a hotfix.
In theory you should also be merging your release branch back to develop (as well as master) after a release, though if there are no hotfixes, the code will be identical and this won't be necessary.
There's no need to worry about somehow making regression testing ineffective -- regression testing should be done on the release branch, and you should be testing the changes each time a cut is made to the release branch. If this is your first release, there can't be any regressions, and there's nothing to regression test against.
You will, however, want to make use of tags each time a release is made. This will clearly indicate in Git the exact point at which the release cut was made.
Setting up new projects and branch designs in TFS 2015. This detail may be significant - I'm using it for PowerBuilder projects, not .NET - VS2015 is used to set up branches and perform merges, the files themselves will be checked in and out in PowerBuilder. Far as I can see that shouldn't make a difference, but mentioning it in case I've missed something
Using the following sample layout:
Prod branches to/from Mod, down to Dev. New CO projects branch from Prod (so they always start with a fresh set of the latest live code), then merged (via baseless merge) to the DEV branch, and re-parented once the connection is set up. That way the users wouldn't have to remember to do a baseless merge; Dev will become the default merge target
Merges would them go back up from Dev to Mod, then back to Prod
The issue is that as a test, I tried the baseless merge after the branch, expecting no files to be merged, as nothing has changed yet in any branch. But the merge from the CO branch to Dev merged ALL files. Not an issue now since there's no changes in place, but would be quite a problem once several projects have been merged to DEV.
After that merge, I made a small change in the project and tried a merge; only the one changed file merged.
My best guess is that since the new CO branch was created after the Dev Branch, it was seen as everything in it is newer than the Dev branch, so it rolled over everything. Not sure how it would treat changes in Dev not seen in the Prod branch yet, haven't tested that scenario. It SHOULD at the very least tell me there's changes that I need to merge, but I fear it might just roll over them with the "new" files in the CO branch.
The question is, how can/do I tell the system that this new branch is "not newer" than the Dev branch? Does indeed the fact that these are PowerBuilder files somehow limit the ability of TFS of recognizing versioning in some way?
Or even more simply, is the branch layout I'm trying not the best method?
EDIT - here's the structure I'm currently using for my .NET projects - I was trying to use the layout above instead for the new code.
It uses the "Main" branch suggested below in the comments, but since I'm pulling "CO Branches" from Dev, I get code currently being tested, and not pristine Prod code. I'm assuming trying to branch and re-parent from Prod in this layout would result in the same scenario.
So is this the better way to go after all?
You may have a Main branch, which is the junction branch between development and release branches, representing a stable snapshot of the product.
You can branch from Main to Dev, Mod and Prod, when the work on Dev branch finished, merge from Dev to Main, when you want to release the product, merge from Main to Prod. So when you want to branch from the latest live code, you can branch from Main. In this way, you can merge from CO to Main, then Main to Dev or Main to Prod. All changesets will be reserved.
Caveat: I am fairly new to both git and GitHub.
So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:
Pull latest from master
Start hotfix
Commit changes
Merge hotfix branch into both master and develop and push both upstream
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
CI hooks to run tests and stuff
a place to put code-specific comments not directly related to the underlying "issue"
avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes
But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.
Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.
As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.
I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.
My recommendation would then be the following:
Create one PR from hotfix to master and have someone review it to validate the fix
Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
If there's no merge conflicts, then have someone review the PR
An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.
The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.
It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.
When should one branch/tag in Mercurial (hg), both at the local repo level and at the centralized/originating repo (that you hg clone)? When should you merge (again at the local level and in the central repo)?
I come from a SVN background where branches were used for new features ("feature branches"), as well as "release branches". In the case of feature branches, a developer would create a branch if he/she knew a project was going to span multiple sprints/releases. The feature branch would then be merged back in once the developer was certain they'd be releasing the new feature during the given sprint. The release branch would then be created and deployed to QA and a staging environemnt for QAT/UAT testing respectively. Any bugs that arose during testing would be committed directly to the release branch. When the release branch was finally ready to be released, it would be tagged (for archival/record-keeping purposes) and then finally, after the release branch was deployed live, it would be merged back with trunk.
How does this process change with a DVCS such as hg?
Branching|merging policy can does not differ at all. These processes just give less headache in Mercurial (you will not be a victim of "Refactoring Hell" with a minimal level of accuracy, unfamous Tree Conflicts are also history) - DVCS vs CVCS will change almost nothing here, Mercurial give you just more freedom: branch when|if you want
I've got a project where we're rolling out v1, and beginning work on v2. I'm afraid that we're going to see bug fixes and minor feature changes to v1 over the next few months, some of which we're going to need to roll into v2, some of which we're going to need to keep separate. (We need to maintain v1's major feature set, but fix any bugs as they're found.)
We're using SVN at the moment. I've considered switching to Git, but I'm a little reluctant to change tools. Aside from that possibility, what are some general strategies and best practices to make managing this situation as easy as possible?
Update: everyone's suggesting I branch the code in Subversion. That was so obvious to me that I thought it was implied by the "we're using SVN" statement. Apparently not. :) I am going to look at Mercurial and Bazaar as well as Git, though. Anything else?
Using SVN, the best you can do is branch your repository:
In the trunk, keep the latest version - not necessarily a stable one.
Whenever you need to separate a new major version from there, branch to, say, 2.0 and you can keep both latest version and stable versions in the same repo.
If you find changes in branch 2.0 that need to be merged into the trunk, you can do it seamlessly.
we are using TFS, but for your specific problem, the solution will be quite similar: create a new branch.
[Depending the application environment you are using, apparently not Microsoft]
We have benefited from TFS because:
You can do merges between branches [baseless merges]
You can work with workitems, [for bugtracking]
With sharepoint support, you may have documents, test scripts can live together happily at one portal.
With powershell scripts, you can have nightly automerges
For different versions the best practice is to store the named versions in the "tags" subfolder. (SVN docs recommend you have a trunk, tags and branches folder for each project).
Whenever you release a version, copy the trunk to the tags folder and give it a name. That version can live on and bug fixes can be made to it separately and merged back and forth.
SVN docs on repository layout:
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html
You should use SVN to tag the v1 code. That way you can create a separate branch of the code to support fixes to that code base.
Have you considered branching your trunk and doing v2 development on the second branch once the v1 branch is frozen? If you fix bugs on the v2 branch that affect v1 and you'd like to release an update/patch for v1, just merge those specific changes back to the v1 branch from the v2 branch.
All of that is perfectly doable in SVN, but it is much easier to do branch management with a tool such as Mercurial or Git. I can't tell you if it's definitely worth switching or not since I don't know your company or codebase, but it's something to consider if you can forsee this situation arising repeatedly in the future as you release more versions.
Using git you can use the following approach:
Your git repository could have the following branches. Each hotfix branch contains a feature release that must be maintained.
master - version: 3.0.0 (latest release)
\
dev - version: 4.0.0 (next release)
|\
| hotfix-1.x - version: 1.0.1 (current hotfix 1.x)
\
| hotfix-2.x - version: 2.0.1 (current hotfix 2.x)
\
hotfix-3.x - version: 3.0.1 (current hotfix 3.x)
Fixes:
Bugfixes are made in hotfix-1.x and merged "up" into hotfix-2.x and from there to hotfix-3.x.
hotfix-1.x -> hotfix-2.x -> hotfix-3.x ...
Bugfixes can also be backported using git the cherry-pick command from hotfix-3.x to hotfix-1.x (if needed). With the cherry-pick command it is possible to pick one single commit and apply it in a different branch. Git will also detect moved and renamed files and still apply the change correctly.
You can also add release branches in parallel to your hotfix branches in order to prepare the releases in those branches (omitted for this example). This is useful when you don't want to block the hotfix branches for new commits. Please checkout gitflow if you want to know more about the details of hotfix and release branches.
Feature Releases:
New features are based upon the dev branch and merged back into the dev branch once completed. A new hotfix branch is created for each new feature release.
Steps:
Merge changes from current hotfix branch into dev
Merge feature branches back into dev
Create new hotfix branch from dev
Release from new hotfix branch
Merge back into master
Notes:
I think the master branch is no longer very important when you decide to keep your hotfix branches. I belive the common gitflow scheme works that way that you trash your hotfix branches and release branches once you are finished. Your releases should all be tagged and are therefore accessible.