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.
Related
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.
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.
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.
Question:
What is the best practice for creating branches for development and release based on the information provided below?
Background:
I work in a small development team (2.25 frontend, 2 backend), and we have a yearly release schedule. Our environment does not allow for patches or services packs mid-year, but every once in a while if our user's environment changes we will release a "recompiled" version with a few bug fixes thrown in (on the current stable version).
Currently we do all of our development on the mainline and then create a branch (5 so far) for the code freeze and do minor bug fixes and the bulk of our testing. Once the version is sent out for layering and deployment we merge these bug fixes back to the mainline where we have continued to develop new functionality for next year's release. The branch stays in our repository forever.
The way TFS does its branches is by having a new "folder" in the source control, and it is starting to get a little cluttered.
Thoughts:
Maybe the way we are doing this is right, but it just feels like in a few more years there will be a large number of branches that are never going to be touched... seemingly ever. Maybe it is possible to create a single "Stable Release" line that has each new version labeled on it, and then if we need to go back to do a mid-year release then it can be recovered from this single line.
Upgrade your environment to 2010 ASAP - TFS 2010 branching is vastly superior, including management.
Your idea sounds about right - you branch off a release version when you have one, then just fix it.
You just have to live with the versions accumulating. This makes sense - until you totally retire one (and "never" is not real here, I bet after 7-8 years you kill an old version) there simply is no other way.
A few places I have worked would handle that like this:
Devs never touch "main" branch directly and it always represents what is in production
A single "maintenance" branch is used for all of your changes throughout the year.
At the end of the year, after all of the changes are ready to go, label everything approprirately and the maintenance branch is merged back into the mainline. A new release build is prepared from the mainline and sent out.
Ongoing changes happen in the maintenance branch.
Rinse and repeat as needed.
Benefit is that you only ever have 2 branches. That makes some SCM related tasks easier to deal with since you don't have to keep dealing with changing folder names, etc.