I am trying to build my solution at the TFS2010, after successfull build, I am trying to make TFS2010 run another application, like VS Post-build event.
It can be possible? and How can I make It?
What you probably need to do is add an activity to your process template for your build.
In your build configuration, the Process area allows you to specify the template that will be used to execute the build. This XAML file should already be source controlled in your TFS project. You can create a new XAML based on your current one, or if you have already created your own just check out your XAML and edit it.
I'm not familiar with DBDeploy or how to invoke it, but if it has command-line arguments you can likely add an InvokeProcess activity to your build workflow and execute a Powershell command script to do what you need to add after the build.
Related
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.
We have a TFS (2012) project that we use as a PL/SQL source code repository. This project does not contain any .Net code or solution just PL/SQL code.
We have a command line build process & deploy process to move the PL/SQL code to the database. Currently we are running the command line daily by hand. I would really like TFS to kick off the command line daily.
I have created a custom TFS Build Process Timeplate that just contains an Invoke Process function however when I go to create a new TFS Build Definition it requires me to fill in Items to Build. I do not have any items to build I just want to kick off the Build Process template.
Is there any way to create a striped down TFS Build that will just run the Invoke Process and not worry about the Items to Build?
You have made the good choice, but your custom activity Invoke Process must be integrated to your main build, items correspond to your solution c#.
So when you create your build, you compile your items, and in the end you execute your check for pl sql.
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 configured a TFS Build using the default template and run my build based on a schedule. I also have a separate msbuild file that needs to be run along with TFS Build for which I have created an InvokeProcess activity that executes a batch file with msbuild command.
However I get exceptions msbuild cannot be recognized as an internal or external command. Is this the right way to do it?
Thanks
Jai
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.