I've been bitten by a strange (IMO) behaviour in TFS today. This is the third time I've seen this in the three years I've been using TFS. It's best explained with an illustration...
I have an In-progress branch of a webforms project, that is used for quick bug fixes and small changes. From that, I do a branch for larger development projects.
Last week a customer reported a bug on Page123.aspx. We did a branch, fixed the bug, and merged Bug fix branch back to In-Progress branch. All changes were committed at each stage.
This week we deployed to the live system from In-Progress, only the see the bug had mysteriously come back.
At no point on the In-progress branch was Page123.aspx modified. When I compared local/server versions, the server version had the fixed page, and the local version was still buggy. However, I am the only developer, so I don't understand how this could happen.
When I branched again from In-Progress to New dev branch, the buggy Page123.aspx obviously remained.
The only way to force my TFS/VS2013 to remember the fix was to do a Get Specific Version on Page123.aspx to replace the local version with the server version.
Is there some kind of bug in TFS that causes this, or is it stupidity? 99% of the time merging correctly gets the latest version of every page.
Related
We were using Sonarqube Enterprise Edition and it’s version is 9.2 and we upgraded it to 9.3 yesterday. So we always use latest version for Enterprise Edition.
I think Sonarqube New Code definition is working wrong. I will try to tell you with our example.
You can see what our project’s New Code definition is.
I think Sonarqube should calculate difference code from the previous version. But it did not do that.
P.S. We scan our repository’s develop branch on Sonarqube every night as scheduled. So the previous version is yesterday’s scan.
We work with feature branches in our repository. Basically, we create new feature branch from develop, then we develop our features in the feature branch. Sometimes it takes one or more weeks. We did a lot of commits in this duration. After we finish developing, we merge the feature branch to develop. And that night, Sonarqube scan develop branch again. I think the merged feature branch’s codes is all new code. But Sonarqube only considers commits made that day(last day). Previous commits’ codes are not shown in New Code reports.
I hope I was able to explain my problem.
Update 1:
I tried to fix the Sonarqube Project’s version nubmer. After that, the New Code definition shows as “Started 5 days ago”. As you can see the below image. It means it takes 5 days period.
But I tried to tell before. I want to see all merged branches, commits to develop in new code report for every day. Is there any other suggestions?
Thanks.
I expect this is a common issue, but one I am not aware of a sensible solution to.
We have adopted the procedure where all local dependent modules are moved straight back to SNAPSHOT once the release has been done. Time passes and we come to do a new release.
When we come to release we need to make a decision on whether a particular module has had any changes or not. If not, we dont need to update release the dependent snapshot and we can simply build against the previous release version as nothing has changed.
The difficulty in this process is establishing whether anything has actually changed since the last release or not. The only way I can imagine establishing this is to look in the subversion logs to see if any significant change has been checked in since the last release, and if it has then we need to release the dependent module. If it hasnt, we are ok to use the previous released version. This seems very labour intensive to me.
Is there a plugin or a better way to achieve this?
I have an ASP.NET MVC solution (VS2012) under TFS. Let's say I have the latest version on my hard drive (lets name it version X). I know this version is OK (tested and ready for moving to production but waiting for approval). Now I would like to work on another request on this solution.
My question: how can I preserve actual state of my solution BUT continue to work on this solution. At some point, when I get approbation, I will need to retrieve the version X from TFS and move it to production, then continue to develop my pending request.
How can I proceed? Using labels or branches?
We do this using branches.
The day after our code cut off we cut a new branch from the Trunk. We then work with test to make sure this is stable, all bugs are fixed and merged back to Trunk.
This branch is then owned by the test team and anything that goes into it must be approved by them.
We also have seperate Daily and Buddy builds for this live branch. Test can use this to build the latest from that branch at any time.
Before deployment day the test team then build this live branch to create a package. This package is stable and tested. After this has been done, only exceptional circumstances will allow anything else to go into this designated deployment.
Branching is the answer to this problem.
The best branching guidance I've seen is the "Visual Studio Team Foundation Server Branching and Merging Guide".
It includes everything you need to make a decision on your branching structure, including pictures!
I recommend that you start with either the Basic or Standard branch plans, then see how badly you need something more complex.
I've been doing some reading about continuous integration recently and there is a scenario which could occur which I don't understand how to deal with appropriately.
We have a stable mainline/trunk branch and create branches for features. Each developer will keep their own feature branches up to date by merging from trunk into their branch on a regular basis. However it is entirely possible that two or more feature branches could be created and worked on over a period of several weeks or months. In this time many releases of the software could be deployed. This where my confusion arises.
It is very likely that changes for one feature branch will cause merge conflicts with other feature branches. CI suggests you should merge into trunk at least daily which would resolve the conflicts quickly. However, you may not want to merge the feature code into trunk because it may not be finished or you may not want that feature available in the next release. So, how do you deal with this scenario and still follow CI principles of daily code integration?
There are no feature branches in proper CI. Use feature toggles instead.
The idea explained more fully in this article is to merge from the trunk/release branch to feature branches daily, but only merge back in the other direction once a feature meets your definition of 'done'.
Code written by one feature team will be pushed into the trunk once it's complete, and will be 'distributed' to the other teams, where conflicts can be dealt with, as part of the daily merge process.
This doesn't go as far as satisfying Nick's desire for a version control system that can be used a backup tool, unless the changes being made are small enough that they can be committed to the feature branch within a timeframe where the the risk of losing your work is acceptable.
I personally don't try to reintegrate code into the release branch before it's done, and although I've never really tried, I'm sure building feature toggles in for unfinished work has its own issues.
I think they mean merging mainline into the feature branch, not the other way 'round. This way, the feature branch will not deviate from mainline too much, and be kept in an easily mergeable state.
The git folks do the same thing by rebasing feature branches on top of the master branch before submitting a feature.
In my experience with CI, the way that you should keep your feature branches up to date with the main line changes as others have suggested. This has been working me for several releases. If you are using subversion make sure you to merge with the merge history enable. This way when you are trying to merge your changes back to line it will only like you are merging the feature changes to line, not trying resolve conflicts which your feature might have with the main line. If you are using more advance VCS like git the first merge will be a rebase where the second will be a merge.
There are tools that can support you to get thins done more smoothly like this Feature branches with Bamboo
Feature branches committing back into the mainline, and OFTEN is an essential feature of Continuous Integration. For a thorough breakdown, see This Article
There's now some good resources showing how to combine both CI and feature branches. Bamboo or Feature Branch Notifier are some ways to look.
And this is another quite long article showing pros of so called distributed CI. Hereunder, one excerpt explaining the benefits:
Distributed CI has the advantage for Continuous Deployment because it keeps a clean and stable Mainline branch that can always be deployed to Production. During a Centralized CI process, an unstable Mainline will exist if code does not integrate properly (broken build) or if there is unfinished work integrated. This works quite well with iteration release planning, but creates a bottleneck for Continuous Deployment. The direct line from developer branch to Production must be kept clean in CD, Distributed CI does this by only allowing Production ready code to be put into the Mainline.
One thing that still can be challenging is keeping the branch build isolated so that it doesn't pollute your repository of binaries by pushing its branch builds to it. Bamboo seems to address that, but not sure it's as easy with Jenkins.
I'm having trouble with branching in Visual Studio TFS. This may be due to the method in which I am developing, but if this is the case, please let me know what the best practice is with branching and I will change our procedure.
About a month ago, I branched a project so that I could begin developing a new version of the web application, but didn't want the main trunk of the application to be affected by my changes as I tested and tried to get things to a production level status.
So as of a couple days ago, we became aware of a few bugs with the current version of the application that is running in production. I fixed these bugs on the main branch, redeployed the web application, and checked in the bug fixes to the main application trunk. And here is where the problem lies. Now the main trunk has the bug fixes, but my new version branch does not.
Here is my question: How do I go about doing a version compare or something of the sort to get the bug fixes into the branched project?
I may be doing things un-ordinarilly. This is due to my lack of knowledge of branching and development life cycles. Please let me know if there is a better method that you all practice in your development shops.
Cheers,
C
Sounds like you are doing the correct thing to me, you just need to merge your changes into your dev branch.
To merge the changes, you need to be in Source Control Explorer. Right click on the "source" branch (in your case that is the main branch) and then select "Merge". You will then go into the merge wizard where you can pick which branch you would like to merge into (your development branch). Personally, I always pick the "selected changesets" option on that page as it then gives you a list of changesets and you can pick the start and end of the range of changesets that you want to bring into your development branch.
Hope that helps.
Martin.
You just need to merge those changes to the new-version-branch.
A good starting point is the branching and merging guidance. Read it to find out how you can organize your branches.