I understand I can write my own custom activity (in C#) to execute custom logic during the build process. My understanding is that Powershell can also be used, but I am not sure where it fits in. I do understand Powershell is used for executing command line commands but how and where would I use it to customize the build process?
Thanks
The decision whether to use Powershell or a Custom activity is for me based on who is responsible. If you have an activity that is created by the build master (for TFS) and therefor reusable for all the teams in the organization, I create a custom activity.
If the project team is responsible (for example a deployment script), the I use the powershell. I create an argument where the team can enter the path of the powershell script that needs to execute to deploy. The project team can optionally choose to enter a value in that argument. The project team can also maintain their powershell deployment script themselves without the help of the build master.
So in short:
A reusable activity: Custom activity
Activity for the team only: Powershell
For me, powershell is the way to go. Here are my reasons why:
Script Independence:
You get script independence using this approach. Example: I have a number of scripts that run after the build (i.e. the compile) process has completed:
Instantiate Database
Deploy Database Code
Deploy Web Applications
Verify Deployment
Run Acceptance Tests
All of the above can be launched, debugged and tested independently without the need to queue a new build.
Powershell is easy to work with:
Custom assemblies tend to add a lot of complexity and flakiness to the solution. Example: Upgrading from TFS 2010 to TFS 2012 was very painful, because all of the Build Templates broke. We had to recompile all of our custom assemblies, and only one dev on the team knew how TFS Build was set up to run our custom activities. I have recently removed all custom assemblies from our build templates, and am using Powershell exclusively.
I have customised my process templates to call a user-defined powershell script after the TFS Build has completed. I do this by using a paths argument in the build definition. This argument is simply an array of strings pointing to the scripts. I agree with Ewald, above, that TFS does not pass the build arguments to scripts. To solve this, in my workflow template I parse each script in the string array, and replace well-known tokens with the build arguments - e.g. #(BuildNumber), #(SourcesDirectory) etc. I find this to be a very easy and solid solution.
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
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.
I am attempting to automate my process for deployments.
Currently, the following steps need run:
Run an external tool in Visual Studio to call Migrator.net (using MSBUILD) to update the database
Right-click the web project and publish locally
Copy the publish folder to all web servers for that specific website
I have now been looking at how to deploy directly from Visual Studio Team Services.
I have created a build definition that will compile my code, and using MSBuild arguments in the "Process" tab of the build definition, will use a publish profile to publish directly to IIS on a target machine. The arguments are something like this:
/p:DeployOnBuild=true;PublishProfile="test_publish.pubxml";UserName=xxx;Password=xxx
This works like a charm for the actual web content, but it does not deal with the database side of things.
The external tool to update the database, as I mentioned, calls MSBUILD with the following:
$(ProjectDir)\Migrations.proj /target:MigrateUAT /p:To=-1 /p:password=xxx
How would I change the build definition to also deal with this MSBuild call? I am at the limit of my MSBuild knowledge.
Thanks in advance.
I have not found out how to do this directly. So I am taking the approach to write a large MSBUILD script that will do everything I want, and only use Team Services to call this script. Rather than use the work flow stuff within the build definition.
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 have sucessfully setup two machines. The first machine uses as TFS Build Controller and the other machine use as TFS Build Agent.
There are two things I want to do.
Run SQL scripts on TFS Build Controller machine. I have all SQL script files on TFS but I have no idea how can I get it run.
I want to do is upload the output (dll and exe files) from TFS Build Agent machine back to TFS Build Controller machine then run test on this machine. (I want to run test after I run all sql script files)
Please let me know if this is possible or not. You can just give me a link since I know it might take a long explanation. I would appriciate if you could write down the answer. :)
Yes, that is all possible, but I would strongly suggest not using the Build Controller for that. Build Controllers are meant to just dole the builds out to the Agents that do all the work. Also Build Controllers are typically shared between Team Projects, so if a single Team Project is abusing the Controller it can affect others; whereas Build Agents are usually dedicated to Team Projects. You should be able to run your SQL Scripts and tests on the Build Agent, that's what most people will do.
Having said that, if you're set on still doing it, you can modify the build workflow template to accomplish it. Anything inside the Run On Agent activity runs on the Build Agent, anything outside of that runs on the Build Controller. See Ewald's Blog series on customizing TFS Build if you've never done it before: http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx