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
Related
We are using T4ToolBox / TextTemplating.15.0 for generating part of the code based on models. Unfortunately it is slow and unstable on local workstations more and more as the project grow.
I am trying to move this process to TFS server and the target is the following process:
after checkin on TFS in specified folder (where the models are) the
custom tool should run on specified .tt files
a shelveset should be created from generated files
and finally email sent about result
My biggest problems is the following: how to genereate code, exclude these files from checkin (because additional code review is necessary as it may broke the main build) and create shelveset.
Any help is really appreciated, thank you in advance!
If you mean perform text transformation as part of a build process, you can refer to Generate files with the TextTransform utility and Code generation in a build process for details.
To exclude these files from checkin you can create a .tfignore file for TFVC or .gitignore file for Git.
To create the shelveset, you can use the Shelvesets Command
Our builds generally have a mish mash of work items and commits associated with them and I cannot tell how TFS determines what to add. We are using TFS 2015 update 3 and TFVC.
When a build runs, it gets code from a location somewhere in the branching and folder of TFVC. Typically, something like "root\dev\src\component name" in this way we avoid getting all of the code in our repository and we have CI set up to run so that any changes in this folder will result in a CI build running.
We also run daily builds which run more tests and create a release package that is used by TFS Release Management. I would expect that any changes to code inside of the folder defined in setting up the repository for this build to be included in the associated change-sets of a build. I also expect that any changes checked-in outside of these branches would not be associated. But this is not the case. We see commits from across the entire project.
Does anyone know how this is supposed to work?
I am not sure if this should go in the question or the answer but I have found some additional information, thanks to the hints provided in the answers below.
It appears that the source settings will take the common root between mapped folders of the repository settings, so if I have 2 folders $/Relo/Dev/B1/src/Claims.Services and $/Relo/Dev/B1/src/PSScripts it will take the common root $/Relo/Dev/B1/src as the source settings and include any changes from that folder down within the build. Can anyone confirm this? Of course thats not what I want to have happen. In the History tab of the build definition if I looked at the diff I can see a field "defaultBranch" in the json which seems to be the value that controls this, is there any way to update this field directly?
TFS determines what changesets should be mapped to a build based on the Source Repository Mappings (Build vNext) in the build definition and the last successful build.
So, you will see a list of the changesets with files committed in the lowest common base of any of the mapped folders including all their descendents, since the latest successful build. Whenever you get a successful build (I hope that it happens more often than failing ones ;-)) the list will shorten and only show the last check-in.
Example mappings below will result in any changeset made to anything below $/Relo/Dev/B1/src (because it is the lowest common base):
$/Relo/Dev/B1/src/Claims.Services
$/Relo/Dev/B1/src/PSScripts
Similar it will pick up all the related work items to the above changesets.
This is what should happen. If you see something else, I would have a closer look at the Repository Mappings or Source Settings of the build definition.
#Noel - I guess you are using vNext build and not XAML builds. Or are you using a mix of XAML and vNext?
In general a scheduled TFS build will associate all changes which were not associated in the last successful run of the same build.
I suggest you check once again if the source folder locations are the same for CI build and Daily build?
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
My team is moving to TFS and we are currently testing migration from VSS. The VSS Converter requires all TFS projects to be created prior to conversion. We have upwards of 30 projects and it is time consuming to create these.
Is there any way to refresh the source control portion of our projects between tests (returning them to their original blank state) while leaving the projects intact, thereby allowing us to run multiple conversion tests without having to recreate our project collection and projects every time?
[Edit]
To answer John's question below: When creating a Team Project TFS, by default, creates an empty source control folder by the same name and associates it with that Team Project. The conversion file requires that source control folder to be available.
I'm going to make some assumptions.
you're using TFS 2008 or 2010
you're not afraid of the command
line :-)
I think in this scenario the "tf destroy" command is going to be your friend.
e.g. "tf destroy $/TeamProject1/FolderToBeWiped"
You could easily write a script that wipes all of your existing folders in source control. As a word of caution, DO NOT do "tf destroy $/" as this will take out the Source Control part of the team project(s) and you'll need to create it (them) again.
As a follow-up, I finally found a way to automatically create the requisite projects. Essentially the process is to drop and recreate the collection, then generate the projects from your xml mapping file. If anyone is interested I blogged it here
http://irwinj.blogspot.com/2011/05/tfsautomated-project-creation.html
I am trying to come up with best practices regarding use of TFS source control. Right now, anytime we do a build, we label the files that are checked into the TFS with the version number. Is this approach better or worse than simply checking the files in and having the version number in the comments?
Can you then use the changeset to go back if necessary or the labels are still more versatile?
Thanks!
They have two different purposes, ChangeSets are when the files have actually changed and you wish to keep a permanent record of that change. Labels mark a certain version of the files so that you can easily go back to that point. Unless your build actually changes files under source control and you wish to record these changes. You should be labeling.
Also, labeling is much less resource intensive. And you can have multiple labels on the same version of a file.
You should label the versions of source files that make up your build. If you're using TeamBuild, it does that for you automatically. It combines the name of your build definition, date, and the build number. So you don't need to do anything.
Your other option is not very conventional and requires a lot of unnecessary work. If I understand it correctly, you would check out your source files during the build process and then check them back in with a version number specified in the check-in comments. This is as Alex mentioned very resource intensive in terms of your build process and also your source control repository. Moreover, how would you get the source files for a particular version if the version information is embedded in the comments? It will be very hard and you would have to sit down and write your own application that uses TFS source control api to download the source files to a workspace by searching for the version number in the check-in comments. This creates unnecessary complexity and headaches.
If you use labels instead, you can do a get by label in VS IDE to download the source files that make up that label. You can even tell TeamBuild to use a label instead of downloading the latest source files during build automation. That way you can build previous versions of your application easily. With labels, you can also apply later changesets to an existing label if there were code changes by simply getting that label and then getting specific changesets and then doing a quick label or creating a brand new label.
Labeling is very powerful, convenient to use, and is a part of TFS. Rather than coming up with your custom solution that requires a lot of effort to make it work and maintain, just try to use what's already available.
Right now, anytime we do a build, we label the files that are checked into the TFS with the version number
You don't need to do this. TFS can refer to a state of the codebase in numerous ways, of which labels are indeed one - but so are builds and even changesets. You can see the available ways to reconstruct a particular point in time by doing a Get Specific Version... and examining the options in the Type dropdown:
Changeset
Date
Label
Latest Version
Workspace Version
Changeset allows you to get just after any changeset; Date is obvious; Label is too, except that builds automatically* create labels (choose Label from this dropdown then have a look in the Find Label dialog).
*I think it's automatic! Unless it's something we've set up specially where I am at the moment...
StackOverflow won't let me comment on the answers above, so I'm writing this as a new "answer". I want to clarify some of the misconceptions listed above.
First, using TFVC Labels is MORE resource intensive than using changesets. A lot more. Commands such as Branch, Merge, and Get by Label is slower. For enterprise servers with huge databases you do not want to be using labels.
Second, Builds don't automatically create labels, although the default build steps include a step to create a label.
Third, as others already mentioned, labels can be moved or deleted, so they are much less dependable than changesets which are immutable.
Overall I recommend you NOT use labels. The simplest alternative is to just remember the changeset number for your builds. Or if you want to isolate different release versions, you should create release branches.
Labels are OK for small systems, but are not good for large enterprises.