Currently I have few custom activities in the main build template. Each additional activity is stored in same binary but different class. To update binary I need to delete old one, check-in delete, copy manually from bin folder to tfs build controller folder, add items to source control and check in changes.
I would like to prevent problem of missing custom activities binary from build template while doing this process.
Can I do it any other way. So there is no time when binary doesn't exist in source control.
You can easily check in the new DLL over the top of the previous one.
If you are using a local Workspace then you just drop the new DLL on top of the old one. This can be automated with a post build script.
If you are using a server workspace (and files are read only) then you will need to check out the file before copying the new one over the top.
You can have an automated build that automated this entire process.
Usually, you should have two projects in your solution. One of the projects is for the custom code and custom activities, the other one to modify the build process template.
After you modify the process template, you need to check in process template and custom activities. The custom activities path should have been specified in your build controller.
Check this blog on how to create your own activity: http://www.ewaldhofman.nl/post/2010/04/29/customize-team-build-2010-e28093-part-4-create-your-own-activity.aspx
Related
In our project we are building project with TFS build definition feature.In TFS build definition there is one option like "workspace" where we mention all require folders which contains file which used to build project successfully. We have separate folders as per requirements which contain different units. this units are in large numbers hence when we build project and mention any folder in workspace then it extract all files in that particular folder. actually we require only few of them for project build because we used different files per project but that files under same roof.
could any one help us that how we build our project with only require files in workspace rather than whole folder?
Status =Active Source control folder =$/Artiion/ADO/LibForms/Loginf.pas: Build agent Folder=$(SourceDir)\LibForms\Loginf.pas
above example works fine
There is no reasonable way to do this. When you tell TFS Build what source folders to use, that is what you are telling it: get these folders. In theory I suppose you could modify or write your own process template and provide custom fields in which you could provide data to the build process about what files you need for that build, and then create some custom action to call out that would then replace the standard TFS Get function in the process template. But what would be the purpose? If you have certain files that are to be included in the solution build, then simply have separate solutions or projects which would include the appropriate files. Then build the specific solution based on which subcomponents you need, and then only those files will be built and copied to the drop location. Sure, they would still have been retrieved in the build agent's workspace, but they would not have been used in the actual build or placed in the drop location. If that's not good enough, and you need to actually Get different groups of files per build, then you should rearrange your files so that the necessary files are in the appropriate subfolders.
I have a build process that I've defined with a custom build process template, and I'm looking for some advice on how I can solve a problem I've run up against.
The build process (TFS 2012) is used to build the code that drives our load tests, and I have a separate process that needs to reference a specific path within the drop folder so that it is always using the latest version of the load test code. Automated load testing, pretty standard stuff.
However, I'm wondering if there is a way to get the TFS build to overwrite files it finds in the drop folder. Right now I have it set up to drop to a very specific folder, and not put anything that would change in the folder name (no build number, date, etc.). The thought is, this way the automated utilities that rely on those files have a fixed point to look at.
However, when I currently run the build it gives me error TF42064: The build number '<build>' already exists for build definition '<build>'.
Currently I have the build definition set up to only retain the latest build, because this process is specifically for those automated tools. We have other build processes that are fired for debugging/troubleshooting/logging purposes. Is there a way to get the build definition to overwrite the drop folder each time, or will I have to dig into the .XAML template file to have it delete the folder it finds before the build fires?
The way I approached this requirement was to start with the default template and let the build copy to the normal drop location which allows me to keep historical builds in the same way as all other builds.
Once the build has been completed I then copied to a single drop location from the standard drop location by extending the standard build template, the activity was added just before Check-In gated changes.
The steps involved were as follows:
Within SharedResourceScope:
Delete Unified Drop Location
Create Unified Drop Location
Copy Directory (source: BuildDetail.DropLocation)
By default TFS Build creates a new folder, using the unique build name/number, and drops the files there.
If you want to change this behaviour to overwrite files in a known location (instead of creating a new folder each build) you need to modify the build workflow/XAML (as #Oswald mentioned in the comments).
You can read about customizing TFS Builds from the ALM Ranger Build Guidance on CodePlex: http://vsarbuildguide.codeplex.com/
I have a customized build process that sets the build name to the current version, updates the FileAssemblyVersion, drops to two different folders, and removes all unessential files from the drop folders, and I'm feeling that I'm starting to get the hang of custom actions and the workflows now.
So now I want to include a changelog in my drop folder; the Changeset comments. Either only the Changesets associated with this build, but possibly all changesets from a given changeset (such as a version number change, or another event).
What is the best way to approach this?
The Codeplex project TFSChangeLog can help you. From a command line you can create a XML file. Using XSLT you can create an output file of your choice.
http://tfschangelog.codeplex.com
I have the following scenario: The company edits aspx/xml/xslt files and copy manually to the servers in order to publish them. So, no build is done. For the sake of control we've decided to adopt TFS Preview since it tracks the version, who edited and so on. Needless to say, it works like a charm. :)
The problem is that since we are unable to build the apps we can't set a build definition to automate the copy of files to another place which, as I've stated before, is done manually.
My question is: Is it possible to copy the files to another place (a folder in a server or local) during the check in? If so, how? (remember, we don't build. so we can't customize the build process...)
You have two options.
1) Create a custom check in policy. I'm not familiar with this process enough to give you any pointers, but I believe it can be done.
2) Create a custom build template, and use that for your builds. You should be able to wipe the build template down to nothing, and then only add the copy operation to it. This is probably the route I would take. Get started here.
You mention you are using TFSPreview, which is hosted on the cloud so it won't be able to access any machines in your network unless you're prepared to open up your firewalls :).
You can copy source controlled files around the TFS Instance ([say into a Source Controlled Drop F1) and then check this out after the build completes.
Start by familiarising yourself with customising the TFS Build Process.
When you're up to speed, you need to look at adding a "Copy" Activity in the Workflow to move the files to the drop folder.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.