Good day!
I have two progects on TeamCity and can't figure out why there is only one tested brach in first project and why there are so much tested branches.
The only thing i've found is Active Branches but this setting is about branches drop-down list.
Our the solution is to set clean-up configurations?
Project page Screen
Related
TeamCity automatically kicks off builds for the branches created by GitHub Pull Requests. This is all fine, and its "Active Branches" list has the same number of items as there are Pull Requests in the monitored repository.
However, if I go to run a custom build for a specific branch, the "Build branch" list has many, many branches, the vast majority of which have been merged and deleted (we've got nearly 400 in the list now):
Is there any way to clear this list down to only show Active Branches?
(this is TeamCity 10.0.4)
As far as I am concerned, the inactive Pull Requests that were shown in the UI were Closed Pull Requests.
As a workaround, instead of using the run command which display a combobox which is not filtered, I use the dropdown inside on the top left corner at the project level, and not at the build configuration level.
If there is more than Closed Pull Requests, but merged one in the list, you should consider to set the parameter: teamcity.activeBuildBranch.age.hours to 0.
You can also reduce the number of showed inactive branches by adding the parameter: teamcity.branchChooser.inactiveBranchesLimit with the desired amound of inactive branches.
the vast majority of which have been merged and deleted
If you absolutely sure that all of them have been deleted in your Repository and you still see them in TeamCity that means only one thing: you keep whole history of all your builds in TeamCity.
If you setup custom Clean-up policy for your build configuration you will reduce number of inactive branches in this list.
As variant you can make special build configurations for your Pull Requests and apply custom Clean-up policy only for it.
What the difference in configs ?
Project with Branches Tab:
Project without Branches Tab:
If you only have one branch specified in the VCS config, you won't see a Branches tab.
TeamCity doesn't show branches in a project in case it knows nothing about them, i.e. there are no builds/changes in the project since project have been created. So if there is an old project with builds, newly created one has no knowledge regarding those builds. Try running a build in a branch, it should help.
Our TFS Source Control is setup like this:
TFS Project
Solutions
WebApp1Solution
WebApp2Solution
Libraries
SharedLibrary1
Web Applications
WebApp1
WebApp2
When I open solution WebApp1Solution, it loads my workspace with projects from Libraries and Web Applications folder.
I would like to suspend my current workspace environment for both web apps and all shared libraries and start working on a specific version of this code from an earlier label (our last deployment). We do not have any branching as of yet.
From what I've read, I think these are my options:
1. Shelve pending changes on the solution and get the specific label version of the solution. What would happen when I check any changes back in?
2. Create a branch in Source Control from the specific label version. Would I have to create the branch on all of the folders in the different locations? How would I switch back and forth between my current code and new branch code?
Any help or advice will be greatly appreciated! Thanks!
Just create a branch at your TFS Project folder into a development folder. You should actually be doing this normally for all of your development. Your mainline branch should never contain anything except for your production deployable codebase. You should always be able to get latest of your mainline and build and run as the production end product.
All developers/teams of developers should have their own TFS folder where they can branch from mainline, make changes, test, etc... then once it has passed all approvals, merge it to mainline and destroy your devline.
As for "switching" your branch is a separate folder from your mainline. You can open both at the same time in different instances of Visual Studio, just like opening two solutions at once. Branching creates a copy of the folder/solution/project structure from the point of your branch. Then when you merge it back it reports differences and attempts to merge. If there are conflicts you will be prompted to review and resolve them. Most of the time TFS does a good job at auto-resolving, but I always carefully review all conflicts before selecting a method of resolution.
What's the best way in your experience to designate where work items should be coded? Do you use a particular field? We currently use a custom "Version to Fix" field in our WIT, but it doesn't relate directly to Dev or the Main line code branches. We end up communicating which Versions (v6.1, v6.2, etc) relate to which branches, but there is still a "mapping" that needs to be done. This really only works for a "Hot Fix" in a released version because the branch is named the same as the "Version to Fix". How are work items designated so that is easy for developers to know where to code and provides the least amount of maintenance?
Updated: Just to clarify a bit ... we have Dev, Main, and Release (one for each release) branches. We do 90% of our development in Dev. Once an iteration has ended we reverse integrate Dev to Main, however we don't release it at that point. Testing is done on Main for a while and select bugs could be fixed on Main. This all goes on while the next Iteration (new stories) moves on in Dev. Once things look good on Main we'll branch to a new version (new Release branch) and development on Main will end until the next iteration starts and we again Reverse Integrate to Main from Dev. Of course we forward integrate Main to Dev once things are fixed on Main. At any point we may have a bug that we want fixed on Dev, Main, or on a Released version. Where we have bug fixes going on in Main, Dev, and Release we are confusing some developers. We tell them the "version" but they have to know what future or current version links back to what Branch. That's where I'm trying to find the best practice with the Task work item.
You can have multiple versions (changesets) within a branch, but the proliferation of branches is not a good idea.
A simple (but powerful) branching strategy is to create a main brach, then create 2 children: 1) Dev, 2) QA Now the question is a non-question. Developers do their work in the Dev branch. When they're ready they reverse integrate changes to main. Then changes are forward integrated to QA. If the build passes QA, then it can be rolled to production.
Some organizations will employ special branching practices like creating a branch for a new Major version or even a branch for a special feature. These follow the same process of reverse integration into main (and subsequent forward integration dev branches when appropriate).
Builds can be linked to changesets. If a particular build has a bug, the developers look up the changeset number, pull it down from version control, check the work in associating it with appropriate work items for the Bug, and rebuild it. That new "bug fix" version now has a unique build id and changeset id associated with it.
That's really going to depend on your shop; our environment works on an iterative build, so the bug fixes always go into the most recent branch (named via date stamp - IE Branch_05252011 or so).
If you have some other kind of versioning / branching strategy, the best option would be to place the desired fix branch in the title:
V6.2 - Fix the ItExplodedException occuring in SomeClass
Alternatively, I believe TFS can also even offer a specialized drop down that you can populate when creating the work item with custom content. You could then populate that with the branch to target.
Here is a very effective solution: Set up a check-in policy using TFS Power Tools, and associate a Custom Path policy with a Work Item Query policy, so that all checkins for a branch will require association with a work item that falls into a branch-specific query. That way if the checkin does not have a work item that matches the branch, it will not be allowed. The query can be defined using whatever criteria you need, and the queries themselves can be updates and reassigned to different branches as needed.
One caveat, however: the queries themselves are evaluated at client-side, so as an administrator you can update the query to block or allow certain items into a branch, but the developers will need to refresh Team Explorer to update their query, otherwise it can allow unauthorized items in, or it can block items that are authorized. One solution I am looking into for this issue is to add a custom check-in policy that will always be satisfied but in the meantime will cause the VS IDE to refresh Team Explorer. I have asked MS to add this directly to their TFS Power Tools Work Item Query checkin policy but they have not responded.
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.