We are developing a project and we use VS 2013 and TFS 2013 Express for version control. In team project source control settings I created two check-in policy. First is changeset comment policy that works and builds check in policy that requires last build was successful. But I think builds check-in policy that does not work because any file that prevents successful build (for example there is a syntax error in this file and project cannot be built) can be checked in. I can check in all broken file(s) although builds check in policy is added. So I need your help, I don't want broken code in tfs.
You need to set up a gated check-in build. Gated check-ins are a form of continuous integration that forces a build to run and validate that the code builds successfully (as well as enforcing that unit tests pass and code analysis is successful, depending on how you configure it). Only if the gated check-in is successful, is the code actually checked in.
However, checking in broken code is a cultural issue. Developers should be compiling and testing their code on their own without the need for an automated process to slap them on the wrist first. Gated check-ins will help you solve the cultural issue by making life inconvenient for people who routinely check in broken code.
On a large application, you'll actually want to have multiple gated check-in builds -- one for each logical subsection of the application. The gated check-ins need to run as fast as possible, because every second that someone else is waiting for a gated checkin to complete so they can get the latest code is wasted time. The longer they have to wait, the more likely it is that they'll go get coffee, use the bathroom, or otherwise take a break, which can be massively counterproductive if they were in a productive, focused headspace when they were more or less forced by the tooling to stop focusing.
Related
How do you people handle the scenario of having to build the solution multiple times every day during the development process? Our .sln takes about 2 mins to build, but waiting for those 2 minutes every day, multiple times a day during development adds to a significant number and also breaks the coding flow. Is there a better way to handle this necessity? Something that will continue to build the solution and run the test on background without the developer having to hit ctrl+shift+B and wait for the build to complete, before checking in the changes into TFS?
VS doesn't support building the same solution before the previous one completes. But you can achieve your requirement by using TFS Build.
When you checkin your solution into TFS, you can create a Dev branch of this solution. All changes will be checked in to Dev branch and automatically build (Gated checkin). Once the build result is what you want, then merge from Dev branch to the original solution.
Looks like you actually working with Builds check in policy which only allows code to be checked in after build succeed. If so, just as you described, you can't work on the project during the build. You have to wait for it to complete.
We are currently running multiple branches within TFS 2013:
Development
Release
Trunk
etc.
Each branch has an automated test build. The purpose of these builds is to publish the latest code (and database changes) for each branch to our test server for manual testing. We maintain a separate IIS application for each branch so that different versions can be tested simultaneously.
Each branch has unique .csproj, .xml profile and web.config settings which control which application and database each branch deploys to, which works great.
However when we merge from one branch to another, auto-merge replaces these branch specific settings causing us to deploy our test builds to the wrong URL and database.
I am aware that auto-merge can be completely disabled in Visual Studio settings but is there a way we can continue to use auto-merge except for specific files?
Any suggestions welcome
This is a well known problem with any code promotion model. I would suggest that you move instead to a binary promotion model.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
With a binary promotion model you build the bits once with replaceable parameters and create or use a tool that orchestrates the release and feeds it with the correct variables for each environment.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
I recently built out an end to end scenario using VSO. You can see in the post the passing of the values for each environment.
The software industry is moving towards continuous delivery and continuous integration. Neither of which is possible in a code promotion model.
You could disable auto conflict resolving during merge, but in this case you have to resolve these conflict manually (ignore)
Options -> Source Control -> Visual Studio Team Foundation Server
Attempt to automatically resolve conflicts when they are generated
or you could use tf.exe for merge:
tf.exe merge /discard CS
use a changeset which will be always discard from merge.
We have a single solution on which we want to start doing gated check-ins. The biggest problem we're facing is that we want the build agents to build all of the configurations and platforms (ASCII and Unicode on 32 and 64 bit) to validate the changes.
We could do this with one build agent and run them in sequence but that will take far to long for continuous integration, so that's not an option.
We could have 4 different build definitions that would build on 4 different agents, but we don't see anyway to have a gated build run 4 different build definitions on a gated build.
I suppose we could do it with a manual process of having the developer shelve their changes then manually kick of the 4 build agents building with the shelf set and only check in when they all succeed, however we'd much prefer a more automated process.
Does anyone know of a way to do this?
Thanks
You should be able to parallelize gated check-in builds using the Parallel Build Template - see a detailed description on Jim Lamb's blog.
Note that there is a potential "gotcha" when using this with gated check-in: by default, Team Foundation Server will take an exclusive (check out) lock when you pend a change on binary files. When the parallel build template runs as part of gated check-in, it will unshelve your checkin shelveset on the multiple build agents. This will fail if you have binary files as part of the gated check-in.
Thus, you'll either need to avoid including binary files in your parallelized gated check-ins, or you'll need to turn off exclusive check-outs for binary files.
I would like to implement a sort of CI where I build my solution on every checkin. There is one problem, however, and that is that my build scripts often will automatically update certain files that do not change the actual compiled assemblies. Is there a way to stop the automatic build (or to not even start) if the only check-in that's triggering it is from one of these "content" files?
Thanks,
Matthew
You can add the *NO_CI* tag to the checkin comment for these changes and they wont trigger a build. Bing it and you'll find lots of examples for how to use it.
I already have a CI build running on my Tfs2010 instance, but I'd like to get a Gated checkin build running as well. There are subtle differences between the ways I would like these two builds would run, however. Specifically, I'd like the Gated checkin to not produce bug workitems on failure, not associate changesets and workitems on build, not move builds to the drop, and not maintain previous builds. Since builds initiated by Gated checkins are uncommitted changes, these steps seem unnecessary to me, but I would definitely like the CI build to perform these functions.
Unfortunately, there's this NO_CI thing that appears on my changesets after they're committed by the Gated Checkin build, and the CI build is never triggered. I found this thread that seemed to indicate that my DefaultTemplate.xaml should have a "Get Activity" NO_CIOption parameter in there somewhere; however nothing in the configuration file seems to indicate anything of the sort. Neither string is present, and I can't find any reference documentation in the msdn library.
In fact, in the msdn library, there's a page that seems to link to the page I want, however where the link would actually be there's a misplaced, duplicate link to "Control where the build system places your binaries." You can see the identical link directly below it.
Anyhow: how is the NO_CIOption parameter used in the build template files? Where is it placed? Has no anyone else ever wanted to do this before?
Side note: is it bad practice to cross-post between SO and the MSDN forums?
To follow up on this, after looking through the Xaml and using reflector on the Build binaries, I found the NoCIOption property on the SyncWorkspace action. Setting this to false seems to have allowed CI builds to trigger after gated checkins, as well as removing the somewhat unsightly NO_CI checkin comment appendix.
See http://donovanbrown.com/post/How-to-have-CI-builds-run-after-a-Gated-Build for information on how to do this.