I'm intrigued by the idea in TeamCity of pre-testing commits (i.e. verifying they don't break the build before allowing check-in to occur) and I'm wondering if there is any way to implement this in TFS. It looks like TeamCity can interface to TFS version control as a backing store but of course I'd prefer a free solution.
In TFS there is the notion of check-in policies where you can execute code on the client and that can validate check-ins before allowing them to occur. However - what you are after sounds more like the notion of a "Gated Check-in" where a build is attempted on a central build server before the check-in is committed to the main code base. Take a look at the BuddyBuild project on CodePlex to add that functionality in the current versions of TFS.
In TFS 2010, gated check-in builds will be a feature out of the box.
Related
My development environment is set up behind a corporate proxy through remote VMs. We uses Visual Studio as the main platform for our code developement , so we had no issue with code review process as Team Foundation Server have this feature.
However recently, we switch to eclipse while still maintaining the projects in TFS. Eclipse have TFS plugin which is good as we can continue on from our previous track without much effort. The only thing missing is the code review.
So, is there anyone who worked using TFS and eclipse in offline mode behind a corporate proxy, have an alternative way to do code review just like visual studio + TFS.
It's based on which version control system your team are using.
If you are using GIT as source control.
For now, the Team Foundation Server plug-in for Eclipse (Team Explorer Everywhere) supports pull requests to review code and collaborate with members of your team.
Collaborate
Work and code together
Use pull requests to review code and collaborate with members of your
team. Triage and track comments at each stage of the work to ensure no
feedback gets lost. Finally, configure merge, build, and review
policies for your Git branches and stay up-to-date with alerts.
Source: Team Explorer Everywhere
If you are using TFVC as source control.
There is no this function in the plug-in directly. You may need to use 3-party code-review plugins to achieve it. Such as SonarLint, Checkstyle Plug-in...
If you want to enforce Code review before any checkin in TFS server. You may need to use check-in policies which can evaluate whether the pending changes meet the validation requirements before they can be checked in to the server. So, if the code review through Sonar can be called programmatically, then you can build a custom check-in policy that calls Sonar inside the Evaluate method.
I'm advocating using Visual Studio Team Services for our source control solution, and have actually started doing so. However, my manager, who is somewhat apprehensive when it comes to cloud-hosted storage and services, wants to know what our contingency plan is in the event of Team Services ceasing to be accessible for whatever reason.
I've pointed out that we have our source code on our developers' computers, in their mapped work spaces, but admittedly if we ended up with just that and no access to Team Services we'd certainly be in a bit of bind. They might all be working on different parts of the same solution and we wouldn't be able to check all of their changes back into the central repository or merge changes made in separate branches. We also wouldn't have access to the comments associated with previous check-ins, or our backlog, tests, etc.
So, the question is, is there a way to backup everything that we're hosting in Team Services so that, in the event of something going wrong, we'd be able to restore all of that to a locally-hosted installation of TFS (or somewhere else)?
I'm a bit late to the party but we developed a Team Services backup tool. We scheduled it as a scheduled task and it runs once a night. It then just clones all our repositories to disk.
Taken from this blog:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
You can also fork it on GitHub here
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items, pull requests, builds, test plans or anything else that the service offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source repository, including all history and commit comments. From there, it's a simple task to push the git repository to a different git hoster (such as bitbucket or github) and make them your new centrally hosted git repository.
On a historical note, Visual Studio Team Services at one point offered a data export for a period of time. You might want to add a vote or three to this related UserVoice idea to help raise the importance of the feature with Microsoft.
Side comment: The business risks in using Visual Studio Team Services will come from either Microsoft shutting down the Visual Studio Team Services service or that the underlying Azure infrastructure has such a catastrophic failure that your Visual Studio Team Services account is unrecoverable. Both of those are extremely low risk, and very likely lower than the risks you'd have running TFS on-premises, in your own data centre, unless of course, your infrastructure and staff are better than Microsoft's :-)
Not a full VS backup in terms of a restore of service. But you can take a full Zip from root down using the Code web site. Right click the root folder and has a zip download option. Pretty neat feature.
The easiest way to back up everything is to use something like the TFS Integration Platform to periodically pull off all your data into an on-premises TFS solution. I've set this up using an Azure VM that we turned off when we weren't actively backing up, which makes it really low cost. For more info on using the TFS IP with Team Services, see this: http://nakedalm.com/migration-from-tf-service-to-tf-server-with-the-tfs-integration-platform/
I'm evaluating tools that helps to manage branch for my team. We are working on a commercial product, so the tools must be chosen carefully to handle multiple releases, potential hotfix on older versions, etc.
Basically, what I want is to reach what git-flow allows.
But because we are already using TFS (2012 today, but 2013 upgrade in the pipe) with Visual Studio 2012 (but we didn't use branches before), I'd like to "stick" to a full MS product line.
Then I was looking for guidance, and I found this software. I've seen the short webcast Quick tour of the TFS Branch Tool VS Extension on channel9 that demonstrate the tool. But it only covers the creation of the initial structure. What about day to day work?
Let's say I've finished working on a feature or a hotfix. How can I guide the developer to merge to the correct branch? How can I have a easy to read view of the work?
The tools said "automate branching task in the ALM Rangers branching guidance"... but I don't see any menu that can do that. The only thing I see is the "Create initial structure" menu.
Did I miss something? Is there any other resource that can help me?
I like GIT... I believe in its strong branching features. But I feel the git experience in VS 2012 is terrible... so I'd like to give a chance to TFS.
As my team (including me) is not mature in managing branching, I must keep things as easy as possible, so any advise is welcome.
In TFS 2013 you have the choice of 2 types of source control repositories: traditional TFS (TFVC) or Git. You can use a fully-featured Git repository hosted in TFS that gives you all the other goodness that comes with TFS. You can use any git client tools that you prefer to connect and work with the TFS-Git repository (including Microsofts new git tooling inside VS - but that's still a work in progress). Then you can do any git workflow you like, such as git-flow.
More info on Git in TFS here: http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx
Alternatively, if you stick with TFSVC, you need to educate yourself on branching workflows that are supported (TFVC is more restrictive than Git on what workflows are supported, but you can definitely achieve something like git-flow). The best source of knowledge for this is probably the ALM Rangers Branching Guidance: http://vsarbranchingguide.codeplex.com/
Note: The tool you linked only helps with creating the initial branch structure. The day to day work is done using the out of the box source control and branch/merge tooling in Visual Studio.
I am looking for alternatives to NWDI (Stands for Netweaver Development Infrastructure by SAP) source control system for developing
Java EE Applications. Primarily because:
NWDI is not DVCS : So developers have to be online to do just about anything.
User Interface: Its very difficult to use and train developers on using this system.
Tracking Changes/Generating Reports: Very limited support for this.
For example I cant find out what projects (Files within the project) have been changed in the last 2 weeks.
Code Review: You can do code reviews, it has a good diff utility. But thats about it, there is no way to attach code reviews to a change request.
Branching and Merging are extremely painful.
However the current system has a few handy features:
Automatic Builds: No need to write any build scripts , everything is built in. So when a new repository (we call it track)
is created it automatically configures the build based on the type of components (Supported by the repository) selected on creation.
A Central Build is triggered whenever a developer commits (Activates the changes). Irrespective of the status of the build the changes are now inflicted on the entire team.
Automatic push to Central Test Server: While creating a repository you can define all the servers (Central test, QA, Prod). A developer can push his changes by a
click of a button to Central Test Server. Again everything is built in and there is no need to extend any hooks like you have to do in Mercurial.
I was exploring Mercurial, Kiln and but couldn't find anything helpful. For mercurial Hooks can be used to do the same but I guess some customization effort is required.
Are there any cool DVCS like Mercurial which does the above 2 as well or is it something that I have to customize to make it work?
I don't know of a DVCS proposing everything build-in.
The only alternative (not DVCS, but with some of DVCS characteristics in it) is Rational Team Concert or RTC (free for up to 10 developers).
With a DVCS alone, the usual setup for CI and reviews is:
Git
Gerrit (review)
Jenkins (scheduler)
See "Using Gerrit Git Review with Jenkins CI Server"
Looks like there nothing useful out of the box. I am going to try out Kiln as it appears to be easy to use and try customizing it.
TL;DR: is it possible to set up gated check-in for one solution in Team Project so that this won't mess with other (non-related) code in same Team Project?
Detailed:
We have TFS Team Project with several solutions in it, each in separate folder.
Most of those solutions belong to dev team and are built daily using build server.
One solutions is for QAs, it contains automated UI tests.
Now we want to set up gated check-in (by instructions from here and some other docs)
This involves creating a build definition and CI trigger for it.
But it seems to us that a build set up like this will be triggered on each commit to the Team Project, not only on those performed by QA team.
So, question is if we can do gated check-in for our QA folder without migrating to separate Team Project and messing with devs.
Thanks.
EDIT: Related question
Your gated check-in build will be always triggered when you change something in the folders specified in the build definition workspace. Set up your build definition workspace to include only folders used by QA solution and cloak folders used by others if possible.