I am setting up DevOps process with TFS and wondering about branching strategy. If I have the following sample branching (image from Guidance: A Branching strategy for Scrum Teams).
I have DevOps process set up (continuous integration and continuous delivery) with continuous integration from MAIN branch (with Jenkins).
How would I handle hotfixes? If developers merge frequently into MAIN branch to verify builds, how do I get the last released code for applying a hot fix? If I were to use Release branches, I would eventually have to integrate hot fix into MAIN branch in order to kick off CI process. However, MAIN branch could contain changes beyond the release.
Please advise on this issue.
Generally a hot fix should gets out from the relevant version on the main branch.
Then need to create a dedicated branch for the hot fix, merge it with the last stable branch.
If it passes the entire QA, unit tests, system tests, etc then merge it back to main branch as the next released version.
you can have a look in the following example when using git the reference is here: git best practice. The source control is not the issue but the main idea. Read carefully the article i believe you'll be able to find what you are looking for.
There are some organization that still working with patches...
I'm not a big fun of this solution, but if this is your case than let me know, because in patches there is a little bit different solution.
It's suggested making all your branches synchronized all the time. When you want to handle hotfixes, you can create a new branch "HotFix" from main. When the hotfixes are completed, you need to merge it from HotFix to Main, and merge from Main to Release.
If you have made any changes in the Release you will need to merge back up to Main in order to finalise the changes.
A hotfix is a patch to released software. If you've got a release branch, creating a hotfix branch off of that is appropriate. After that hotfix is promoted up to Prod, you can then reverse integrate back up the chain to Main. Hotfix -> Release -> Main, and even forward integrate that up to the next sprint, if needed.
Obviously, the answer that you choose depends on your particular requirements; however, typically, you should cut a release from main, and a hot fix from the release branch. Personally, I would say that that code should not go back into the release branch, but be double fixed in a development branch.
The main reason for this is that, once you've released code, that code branch should be locked as it was at release. If you follow this, then you can always go back to a previous state of affairs. As has already been suggested, you may be halfway through changes to a hotfix when the requirement or priorities change; or when the customer reports a bug in the live code. If you maintain a separate branch, you can always access that code.
How to handle this really depends on the release and maintenance strategy or customer agreements you have.
If your release branch happens also to be a maintenance codeline (it seems like it from your description) then create feature branch from it, implement a hot-fix, test, merge back and release a "patch". Ideally you should have CI set also for the "maintenance" branch.
After this you can integrate your hot-fix with main codeline or put the issue on backlog to implement it differently for the future new release.
BTW: Some nice articles here:
https://www.cmcrossroads.com/article/agile-perspective-branching-and-merging
and
http://www.bradapp.com/acme/branching/branch-creation.html
If you are using Agile, then feature branches can be a good option. The only thing is it has to be combined with a ticketing tool like JIRA or AGM. For handling hotfixes in such scenarios, you can have a user story in AGM or JIRA, which upon completion will be merged onto the mainline trunk.
Related
I have a situation where we were working on feature branches against a main development branch ('trunk') and each release cycle, a release branch would be taken from the current development branch.
However, a release was cancelled very late on and instead we were asked to issue the previous release with only some features - after these were all integrated into the main dev branch.
So what happened was the previous release branch was taken as the base of the new mini-release, and we now have to re-apply specific changes that were already made against the development branch. I luckily still have my feature branch and it was never merged. It is based on the development branch, however my branch was taken fairly early on in the release cycle and was not updated by re-merging parent (trunk) changes - so my branch's parent is actually not too dissimilar from the new branch I need to apply it to.
I know TFS has some facilities for re-parenting and baseless merges but what is likely to work best? More importantly if I try re-parenting, can I break my branch or am I safe that I can try things, back them out and try again if there are problems?
My branch is fairly large, maybe 50 changesets applied to quite a few separate modules. I suppose I could try to apply each changeset one-by-one instead?
In my experience, baseless merges are always terrible. In most cases I find diffing and merging the two branches manually via a compare tool (like BeyondCompare) is easier and more reliable than using the TFS tooling.
That being said I would challenge you to consider going to a single main branch. We made the leap (a huge leap for us at the time) but it has paid dividends many times over at this point. The key is being Release Ready:
https://dotnetcatch.com/2016/02/16/are-you-release-ready/
The Microsoft ALM Team describe the Basic Branch Plan as needing a MAIN, DEV, and RELEASE branch.
I am working on introducing branching/merging to a new team who currently uses source control with no branches whatsoever.
I was wondering how the RELEASE branch is actually used.
Can changes be made in the DEV branch then be merged up to the MAIN branch without needing a RELEASE branch? MAIN would still be read-only. It would basically be the RELEASE branch in essence. The reason I say this is because we don't have that many changes but I want to isolate the stable code from new changes. Our concept of a "release" per say is not yet well defined. I am still working on that.
I just don't know if my team needs a RELEASE branch (considering our needs specifically).
I would appreciate some comment about the strategy of just having a MAIN and DEV branch.
Typically the release branch(es) are used for "safekeeping". Basically the same as a label.
Releases to production are usually a pretty important event, and you want to know exactly what source you released (in case you ever need to go back to it). Way back when people used to create Labels to track this, but creating Release branches is better for a couple reasons:
Labels are mutable in TFS, meaning somebody could change a label and there would be no audit trail
Branches are also mutable of course (changes can be checked in), but this can be locked down via branch specific permissions
Also if a change is made to a Release branch (which it never should be), at least you have an audit trail through history
Even though a branch looks like a heavy-weight operation creating a copy of your entire code base, in reality TFS just creates a new pointer to the same files, so the storage cost is trivial
I went the other way when I implemented TFS at a client (replaced SVN). What I did was introduce a MAIN branch and a RELEASE branch and not a DEV branch initially as that seemed very confusing to the team. It is also hard to convey the purpose of a DEV branch to an SVN familiar team initially.
The main purpose of our RELEASE branch was to preserve a historical placeholder as said in another answer. Currently we are using Git and we have a CI server that does the release process and branches to release/$version_number. I think that concept might be easier to understand and convey to your team. i.e. automatically create release branches when you actually release.
We are in the middle of a complex system migration, and are on a three branch system - Feature, Main, and Release.
We released our last feature branch by merging to main, fixing integration issues, then branching to release 3.00. This is now our current PROD and hotfix.
Following 3.00, a new feature branch was created. We have merged the new feature to Main, resolved integration issues, and branched to release 3.01, our upcoming release.
Here now is the problem - release 3.00, our current production, was supposed to support employee discounts. It does not. The employee discount feature was developed in the new feature branch, merged through main, and branched into the upcoming release.
I need to merge future code into the past, and diagramming this has me looking like Doc Brown in BTTF2 where he's explaining the alternate time continuum. I need to take the future and merge it to the past Marty (see my attached drawing).
All that to say, how can I merge code from a younger branch to an older branch? I was going to post a drawing, but apparently I have to have a reputation before I can do that. So here's a shared link to google drive: https://drive.google.com/file/d/0Bw8tCgQHaBKMR2N5c1lZdEZIdkE/edit?usp=sharing
Now that's a fix to be in. The reality is you would likely be best re-implementing the feature on the older branch. You could maybe achieve a reverse feature integration if you have full unit tests going back to that older version. Otherwise you are looking at a line by line frankinMerge that you will be debugging forever.
My recommendation would be to go the re-implement route as the safest.
We are trying to implement the "Basic Dual Branch Plan" as described by the ALM Rangers in the latest Visual Studio TFS Branching and Merging Guide. From the guidance:
The basic branch plan with a MAIN, DEV, and RELEASE branch enables concurrent development for your next release, a stable MAIN branch for testing and a RELEASE branch for any ship blocking bug fixes. Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.
Additional releases are supported by creating release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch. Once the RELEASE branch is created MAIN and the development branches can start taking changes approved for the next product release.
We are undecided as to whether we want to use a single Release branch (and label releases), or create a new release branch per release. However, there are some questions that apply either way, that don't seem to be addressed by the guidance.
My main question is: At what point in time should we create a RELEASE branch (or move tested code to the single RELEASE branch if that's the way we go)?
My first reaction was to create it only when ready to do the release, but then you have the problem of creating a deadlock for development and testing of the next sprint's work; you cannot check these changes into MAIN until the RELEASE branch has been created (if you do, it's more difficult to separate out the changes you only want to go to RELEASE).
Second idea is to create the RELEASE branch at the beginning of the sprint, and as changes pass testing in MAIN, merge them down to the current RELEASE branch. Once we reach the end of the sprint, we can lock that RELEASE branch down, and create a new one for the next sprint. This sounds like it would work, but I see no discussion of it anywhere, so I just wanted to see what people are doing.
I would give the same advice as Adarsh Shah in that 2 branches (MAIN, RELEASE) are sufficient in most cases, and using feature branches for things that you don't want to commit into MAIN immediately because it would take a while to be fully ready for testing. And by RELEASE I mean a branch per actual release.
Keep in mind though that, in theory, MAIN should in a release-ready state at any moment. This means using feature branches for a lot of small changes too and not merging things into MAIN as long as the feature is not considered ready. Now, this is something that you should experiment with and see what works best in your environment. If you find that it is too hard to keep MAIN into a release-ready state, by all means, create a separate DEV branch to commit the daily work. In my experience however, with some good guidelines, automated and manual testing you quickly can get into a flow where MAIN can be considered quite stable. I've worked in environments where we had a DEV branch which was highly unstable and a stable MAIN branch, and environments where we didn't have a DEV branch. Sometimes the DEV branch was needed, sometimes it became a burden to keep them in sync as both DEV and MAIN were fairly stable and essentially just a copy of each other.
Now, when should you create the release branch. It depends on the type of development you are doing. For small desktop projects or websites which have a fairly steady release cycle (a single release per sprint, for example) I find it easiest to create a release branch at the end of a sprint, and only pushing it to production the sprint after.
S1 - - S2 - - S3 - - S4 // Each sprint
\ R1 - \ R2 - \ R3 // Release branch created at the end of a sprint
\ P1 - \ P2 // Pushed to production at the start of the next sprint
So, at the end of S1 I create the release branch R1 from MAIN but it's not pushed to production just yet. During S2 both new features are implemented on MAIN and critical bugs are fixed on R1. If a fix on R1 is approved, it gets merged back into MAIN too, if it's required. At the end of S2, a new R2 is created, and R1 is pushed into production. I have found this approach to work quite well. You basically have a full sprint to work out the last issues in a release branch.
Of course, if a serious critical bug appears on production this bug gets priority above all else. An RXa, RXb, ... branch can then be created of the existing R-branch that's in production, implement the hot-fix and push that hot-fix into production. You can then consider whether it's needed to merge the changes from the hot-fix into your MAIN branch. Don't create a hot-fix on the MAIN branch and merge it down though, you'll find that it quickly becomes too complex because on MAIN a lot of the surrounding code might have already changed.
Here is what I would suggest:
1) Do all development on the Main branch until Code Complete. Code complete is the time when developers stop working on new features for that sprint but can fix regression bugs. Code complete can be few days before the release or up to a week based on how long is your sprint).
2) Create a new RELEASE branch from the MAIN at that point . Deploy the branch to QA/Staging environment to do a smoke test. After that point QA team will use RELEASE branch to do the testing for the release.
3) Developers can start working on the new features for next sprint at that point and start checking-in changes to MAIN branch. Any regression issues found during testing will be fixed in RELEASE branch first and then merged back to MAIN.
4) Any changes to code in RELEASE branch will then be pushed to QA/Staging for further testing.
5) One the Release is done any bug found in production will be fixed in RELEASE branch and hot-fixed to Prod and also merged back to MAIN.
No. 1 will be too late and no. 2 will be too early IMO.
I would suggest to create a new branch for every RELEASE and then get rid of old RELEASE branches periodically instead of using labels.
Also, I prefer having only 2 branches MAIN(which is also DEV) and RELEASE except any branch developers need to any specific feature/framework change etc. Under the root folder I usually create MAIN, RELEASES(all release branches) and BRANCHES(all branches specific to a feature/framework changes etc. but these are created only in special cases not always)
When making a deployment to production, should I mark my code with a label or create a branch for the code that's in production?
In TFS, I would have a Release branch with a label identifying the specific version being released to production.
Which would imply you have other branches may I suggest the following
Three major branches: Main, Develop, & Release.
One Hotfix branch for your current fire.
0 to N Major-Feature branches to contain the disruption of development.
Details
Main Branch
Contains the latest stable builds
Tag/Label each release
Develop Branch
Branched from the Main
Where most of the work is done
Merge back to Main before release
Release Branch
Branched from one of the following:
The Develop branch
OR the Main branch (this may be better since it is "stable")
Bug fixes are done here
After fixes are tested and released,
merge to Develop branch
OR merge to Main branch and then forward integrate (FI - which is a merge from parent to child) to Develop
Tag/Label each release or bug fix
Hotfix Branch
Branched from Main
Merged back into Main
Forward integrate merge to Develop
Used to allow Main to remain "stable"
Major Feature Branches
Branched from Develop
Merged back into Develop
Used for major features that would possibly disrupt the regular development path
References:
another stack overflow question: when-to-use-a-tag-label-and-when-to-branch especially Martin Woodward's answer
Source Control How To by Eric Sink
A successful Git branching model by Vincent Driessen
This contains a very good graphic of a branching model
Ideally, both.
You probably want to have a label so that you know exactly what you delivered for a specific release. However, you probably also want to create a branch so that you can perform minor bug fixing to what was released and create a new release.
In practice, you could approach it in one of two ways:
Have a continuous developmental timeline that gets branched for each of your production releases:
example:
------------------------->dev
| | |
| | |
| | |
v1.0 v2.0 v3.0
Have your production releases "cascade" off of one another:
example:
---->v1.0---->v2.0---->v3.0
Ultimately, up to you in deciding what architecture to adopt, as long as it's consistent and makes sense to you.
You can use a combination of both. Here is how we do this internally for all projects.
We have structure with folder Branches and sub folder for each minor and major version. We also use labels that we set on individual sub folders so we can easily rebuild any specific version any time in the future.
$\Branches
\2012.01
\2012.02 (branched from 2012.01)
\2012.03 (branched from 2012.02)
\2013.01 (branched from 2012.03)
You can also check out Visual Studio Team Foundation Server Branching and Merging Guide for more details.
I have seen both done, Labeling is more lightweight and to me easier. But, it has been pointed out that labels can be deleted rather easily. A branch protects against this by not actually being deleted unless "destroyed". The reason I prefer not use branches is I hate having to cloak them as I tend to do get latest from the root and don't want all those branches filling up my hard drive
For the record, since it was pointed out to me about label's being deleted I have removed permissions for Labeling from everyone but Admins and the build service accounts to help mitigate this.