So while this is completely do-able (albeit using some fairly fancy scripting) in Jenkins, I'm just wondering if it's do-able in VSTS.
I'm not too familiar with capabilities of VSTS (have read https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-build-git).
I want all changes pushed from a feature branch to master to be automatically merged into all other active feature branches. So basically, I want (what I call) true CI.
Is this possible in VSTS, and if so, how would I do it?
EDIT 1:
Read this:
https://learn.microsoft.com/en-us/vsts/build-release/actions/scripts/git-commands#merge-a-feature-branch-to-master
This would work for me by simply switching the merge direction; instead of merging from feature branch to master, merge from master to feature branch.
So the question now becomes:
How to get a list of all active child branches?
Given that I'll be using work items mapped to branches, would this suffice?
https://learn.microsoft.com/en-us/vsts/report/extend-analytics/work-item-links
No, it is not supported in VSTS, with Pull Request it just can merge source branch to a target branch.
The workaround is that you can create the Pull Requests for related branches during the build/release, refer to this thread for detail steps:
How can I create a Pull Request when a release completes in VSTS?
Update:
The other way is calling git command to merge branches: Merge a feature branch to master
Regarding active branch, as we discussed, you can link them to a work item, the work item has the TO DO, In Progress etc... states that can identify different "state" of branches, and you can retrieve the work item through Work Item REST API.
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.
In our org, we work on many feature branches under the same project.However we face many issues when merging code where people working in other branches don't know the changes made.Due to concurrency issues,sometimes it breaks in production. Can anyone recommend a tool for TFS similar to what sourcetree does for github?. We face many concurreny issues as there are many people working on the same project with many branches. We would like to notify use if any merges have been made in the main branch or the feature branch.
To get alert when there is a merge to main branch, you can create a Checkin Alert "A file is checked in under a specified path" to make "Server item" "Under" "$/TeamProject/MainBranch". In this way, when there is checkin on MainBranch or FeatureBranch, an alert will be sent out.
By the way, to use Feature isolation branching strategy, the considerations should be include:
Each feature branch should be a full child branch of the main branch.
Keep the life of your feature development short, and merge with
main frequently.
Feature branches should build and run Build Verification Tests
the same way as main.
Merge frequently from main to feature branches if changes are
happening directly on main.
Merge from feature to main based on some objective team criteria.
You can get more information about merge and branch at website:
https://vsarbranchingguide.codeplex.com/releases
I have the following scenario:
I have a Dev and Stage branch
Code is checked into Dev, and at some point those changesets from Dev are merged into Stage
No direct edits/check-ins happen to stage (beyond the merges from dev)
What I want to do is identify/verify that no new code has been introduced directly into the stage branch which did not originate from a changeset in Dev.
It does not appear possible to secure Stage (from a source control perspective) to only allow check-ins of merges from dev (since all operations appear to be merge,edit after I do the merge), so what I thought I could do is create a TFS Check in policy which attempts to compare the merged changes to their source.
I have created a class which derives from PolicyBase and have over-ridden the Evaluate method. In the Evaluate method, I spin through this.PendingCheckin.PendingChanges.CheckedPendingChanges and check the .IsMerge property and .ServerItem property to see if the item in question is a merge and is destined for my Stage branch.
When I spin through each change however, I don't see a way to track its lineage or access the parent from where it might have originated (ie: the Dev branch version #).
How do I only allow merges, but no direct edits on my Stage branch?
The only way to achieve this in TFVC is for you to take ownership of all merges. If you do the merge then you have the control. Many organizations with these sorts of draconian policies create an automated script that does the merge and rejects if there are any conflicts. That way the developer is forced to pull from Staging to Dev and resolve all conflicts before requesting the merge through a web portal. If the merge is successful it was conducted on a server by a single service account and no coder required permissions to Staging of any sort.
This is however dysfunctional. Either you don't trust your coders, or they are not competent enough to work in your code base.
Another method might be to move to Git in TFS for source control. In Git merges are non-editable and are performed as a single action rather than the merge/edit you get in TFVC.
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'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.