I have managed to chain two TFS builds together using Jason Stangroome's chaining build definition template. This gives me the capacity to execute one build definition after the next:
CertificateRepository-CI (Continuous Integration Build)
CertificateRepository-IntegrationTests
The latter will automatically be executed if the former is successful. I am stumped by the lack of Build Definition Templates that are able to download and extract the contents of the preceding build's drop folder and perform actions upon these artifacts, in this case running SpecFlow/NUnit integration tests.
In this case I am using:
Visual Studio Online
Git for the codebase being tested
TFVC for the ALM components (NUnit Adapter, Build Definition Templates)
Any help greatly appreciated.
If you are using TFS for source control: I don't have a template for this but you can follow below steps to achieve this.
In CI build set the Staging Location option to Copy buildoutput to following Source Control folder
Download the drop folder by mapping it in source settings option
in build definition
Under drop location folder in TFS, every CI build will create a new folder, you need to pass this folder name to the second build definition. Please check another post from Jason for passing parameters to second build
Execute the tests by invoking the commandline tools using Invoke
Process activity.
Related
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx
How do I or can I, create a hierarchy of build definitions in TFS 2012?
I currently have a master build script (.cmd) that calls multiple child scripts (.cmd).
I want to migrate this to the TFS build system and maintain the hierarchy.
I can't seem to figure out if this is possible using the TFS 2012 build system.
Here's what I'm talking about:
MasterBuildScript.cmd
call componentscript1
call componentscript2
call componentscript3
call ...
call packaging routine for all components
componentscript1.cmd
build solution componenta1
build solution componenta2
build solution componenta3
...
componentscript2.cmd
build solution componentb1
build solution componentb2
build solution componentb3
...
more components...
Is there a way to do this with the standard TFS 2012 Build Definitions?
- Bruce
There is a way to do this without doing any custom coding. You will have to make a minor addition to a build process template, however. That doesn't use code, it uses Windows Workflow Foundation.
Essentially, you would need to setup TFS Team Build definitions for each .cmd build script that you currently have. One for the master build, one for each component build. The real work involved here is converting your .cmd script into a TFS build definition.
Then, to auto queue the "child" builds, you can edit the process template for your master build definition and add an "InvokeProcess" activity - this lets you shell out to the command line as part of the build process. You can use the command line utility TFSBuild.exe to kick off the "child" builds. http://msdn.microsoft.com/en-us/library/aa337622(v=vs.90).aspx
I've used something similar in the past where I have a build for my core set of assemblies. That build then kicks off all of the builds which have dependencies on those assemblies.
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
Have a CI build set up in a very simple solution (MVC webapp, Service, MSTest project)
The build shows orange with the following:
Handle MSTest Exception There is no working folder mapping for
/Heartbeat/Source/BvtAutomation/Local.testsettings
Now, here's the kicker, that is not the source branch being built, it is another project altogether! I cannot find any reference to it in the build definition or anywhere in my solution (WinGrep .. the whole nine yards!)
Anyone seen anything similar to this or have a suggestion as to what I might try?
Thanks!
In TFS2010 when building with DefaultTemplate.xaml, the test files to run are not specified relatively to the mapped workspace, but instead by their complete path from Source Control.
So to fix the issue:
Edit your build definition
Go to the Process tab
In the 2. Basic section, select Automated Tests and click the ... button to edit the test settings.
In the Automated Tests dialog, browse for the .testsettings file in the branch you're building.
This may help: select build definition in the Team Explorer, right-click -> Edit build definition. On the 'Workspace' tab you can configure sources to be got to the build machine. HTH
I have been using a msbuild file that builds and packages my solution to 'Client' and 'Server'. So far I have been using the below cmd to build from VS cmd prompt:
msbuild.exe MyBuildFile.proj /t:Build
(I have a target called 'Build' which will kick start build and do the rest).
Now, my team wants to queue builds in TFS build server. I read about TFSBuild.proj file. Should I once again write all the scripts in to TFSBuild.Proj or is there a way by which I can call my 'MyBuildFile.proj /t:Build' from TFSBuild.Proj.
Any help is appreciated.
Thanks, Mani
You can just include your existing MyBuildFile.proj in a TFS 2010 build:
Create a new build definition
In the Process page, choose the UpgradeTemplate.xaml workflow
Select the directory of your checked-in MSBuild.proj file of choice (checked-in under the name TFSBuild.proj)
There might be some subtle differences between your development system and the build server that you need to take care of, but above steps should take you 85%. Enable Diagnostic level build information verbosity (also to be set on the Process page) to troubleshoot loose ends.