We have TFS 2010 builds queued to be run on a build controller, which is not available anymore.
I've fixed the build definition to use the available controller, so all the further builds will go to the correct one.
But is there any way to move existing queued builds to be run on a different build controller?
Or should I just cancel them and re-request builds manually?
Related
I am trying to improve our general automation process. We use VS2012 and TFS2012.
Here is what I want to happen upon checkin to our CI branch:
BUILD
Build the selected projects / solutions as configured in the build definition settings.
Generate a deployment package that can be used to deploy the websites (without having to rebuild the entire project again)
Generate a nuget package that can later be published (without having to rebuild the entire project again, i need the dlls to match the symbols created from indexing so we can debug them)
TEST - IF AND ONLY IF BUILD WAS SUCCESSFUL
Run all configured unit tests.
DEPLOY - IF AND ONLY IF ALL UNIT TESTS PASS This is to prevent breaking changes entering our development environment
Take deployment package from (1.2) and publish it to it's intended environment (hopefully configured using Publishing Profiles and transforms)
PUBLISH - IF AND ONLY IF ALL UNIT TESTS PASS
Take nuget package from (1.3) and publish it to our private nuget gallery
I don't need a full tutorial (although that would be awesome) for the entire process, but more how to go about integrating it.
For instance:
Should I use msbuild on a wrapper project?
How do I deal with creating the packages upon build on the TFS build server?
How can I enforce the "IF AND ONLY IF ALL UNIT TESTS PASS" constraints?
What is the best / easiest way to perform the deployment /publishing after as part of the build.
This is the process we want to use and any help is realising this is very much appreciated.
And I'm sure many other people are interested in how to set about integrating this style of process.
Also if it's relevant most solutions have a mix of shared dll projects, websites / apis, and unit tests. One of the reasons I want this process is to be able to split them up and modularise our large dlls into smaller isolated units, which would be to unmanageable ATM without this auto publish mechanism.
Thanks,
Gary.
BUILD Build the selected projects / solutions as configured in the build definition settings. Generate a deployment package that can be
used to deploy the websites (without having to rebuild the entire
project again)
This is out of the box, add deployment profile to your projects, call them 'Release'
Add the following to your MSBuild Arguments
/p:DeployOnBuild=true;PublishProfile=Release
you don't have to use Release, as long as your Publish Profiles match what you put in the MSBuild arguments
This will generate the deployment files as part of your build (MSDEPLOY)
Generate a nuget package that can later be published (without having to rebuild the entire project again, i need the dlls to match the symbols created from indexing so we can debug them)
See Nugetter on code plex http://nugetter.codeplex.com/
TEST - IF AND ONLY IF BUILD WAS SUCCESSFUL Run all configured unit
tests.
Should be out of the box, but you can change the build template to fail the build should compilation be unsucessful, if this suits your needs better.
DEPLOY - IF AND ONLY IF ALL UNIT TESTS PASS This is to prevent
breaking changes entering our development environment Take deployment
package from (1.2) and publish it to it's intended environment
(hopefully configured using Publishing Profiles and transforms)
PUBLISH - IF AND ONLY IF ALL UNIT TESTS PASS Take nuget package from
(1.3) and publish it to our private nuget gallery
See Nugetter on codeplex as listed above
We have multiple groups running their own TeamCity setups inside the firm. My group provides a set of generic libraries that other project groups use in their projects. We use TeamCity to push versions of our libraries to production. What I need is a way to automatically trigger builds on other group's CI system that depend on our libraries once we push a new version to production? I already have have the scripts to upgrade to the latest version etc ready. Right now it is manual, i would like to automate it and have a new build of the dependent projects triggered once we release a version to production. I am looking for a way to push the trigger notification across Teamcity instances.
You can trigger TeamCity builds using an HTTP request so you could modify your build script to make the required requests at the end of the build. This does have the downside that you need to hardcode the list of builds that need to be triggered on the remote servers into your build script.
The syntax for the HTTP request is:
http://<user name>:<user password>#<server address>/httpAuth/action.html?add2Queue=<build type Id>
For full details take a look at this page of the TeamCity documentation:
Accessing Server by HTTP
I have a single build controller with many build agents strewn across many build servers.
Some build servers are more powerful than others (better CPU, more RAM, etc.). Without resorting to using "tags filter" for agent settings per build, how can i set the build agent priority?
Build agents have no Priority property, and the build controller will just pick the one from the available build agents in the pool to execute your build.
Using the tag or name filtering, as described here, probably helps but I understand it is not a replacement for the priority.
Let's say I have one TeamCity build configuration depending on artifacts taken from another.
It is possible to publish artifacts while build is in progress in TeamCity.
My question is: is it possible to trigger build when all necessary artifacts are available even if builds that are providing these artifacts are still in progress?
The purpose of this is to speed up builds a little.
Thank you!
TeamCity, as far as I know, only has the option to trigger on finish of another build configuration, not after publishing artifacts which as you say you can do while the build is still in progress.
Let me ask you another question:
Since whatever you are doing in the build after the publication of the artifacts didn't of course stop you from publishing the artifacts, can't you extract that part out into another build configuration and then have that part fetch the artifacts from this one? This way you can make whatever build configuration you wanted to trigger as soon as you get the artifacts, trigger, well, as soon as you get the artifacts.
I'm trying to understand how to configure TFS Team Build to provide a CI solution for my project. I have a fairly common setup that I have several categories of unit tests. For simplicity lets say there are two categories:
Exchange2003
Exchange2007
Each test category needs particular software to be installed on the Build Agent so I would create two Build Agents, BuildAgentEx2003 and BuildAgentEx2007, with the obvious configurations.
Now when I kick off a CI build I want a few things to happen:
Exchange2003 tests to run on BuildAganetEx2003.
Exchange2007 tests to run on BuildAganetEx2007.
All tests categories get run and their results aggregated.
Is that supported and if so how would I configure it.
P.S. In reality of course the situation is very much more complicated. I have a large matrix of test categories and build agents. Each Build Agent would typically be capable of running many different categories of unit tests and each category of tests can be run by one or more Build Agent. The requirement being only that each category of tests be run once for each CI build.cat
Set up one CI build for building the code base. Set up one build for every configuration you need that is a manual build.
After the CI build is successful queue a new build for every configuration using TFSBuild.exe
Pass the original build number to the queued builds as a parameter.
As the last step in the manual builds you publish the test results to the CI build using MSTest.exe
Team Build 2010 should support this scenario out the box - although it will take some work to set up build agents and assign tags to them. But once you do that you should be able to use distributed builds to build and run tests on particular build agents.
It would be much more complicated with Team Build 2008.