I have automatic build numbering setup, based on build date/name, using approach proposed by John Robbins from Wintellect described here. So the version/resource file is automatically created on build time but not checked-in.
I wonder how to approach a problem of rebuilding historical versions (based on labels) and having the original build number/name in them. Is it possible to detect 'GetVersion' parameter of MSBuild and try to recreate the original build name from it?
Is it a sane approach anyway? What alternatives do you see?
It's not easy to build a specific changeset (though possible, if you pass the changeset number into your build script and modify the "Get Latest" portion of the build).
However, one easier way of handling this is to create a branch of your code. You can branch at a specific date or changeset, which will create a copy of code from that point in time. Your build scripts can then be pointed at this code.
With respect to your versioning problem: you may find that the only sensible way to do this is to hardcode the required version number. My understanding of your version numbering strategy is that it doesn't relate to anything you can derive from the source (such as the changeset number, date, or file content), and it isn't checked in - so re-calculating it will be pretty complicated!
You ask question Rebuilding historical builds but it actually Rebuilding historical change Set or label, I know what you mean but I am trying to tell you what I need to say, so I don't see that we need to build a label with the specific name the label or change set can has many build as needed and since we use the date and time in the build number it will more realistic to has the current time and date the build was taken instead of old one
Thanks
M.Radwan
Related
Simply, I have created multiple builds in Main Branch. However, BuildDetails.BuildNumber is same and incrementing.
I know if I branch my code, it would reset to 1.
Q: Is it possible to reset this number for each build without creating branches?
Update: The only option I find up till now is to save my BuildNumber in Version.txt, checked into TFS repository. Checkout this during build, get the number, increment it, use it in versioning, and Checkin the file. However, still looking for some better solution.
A bit unclear on what you're after. Let me try to explain how build numbers work:
Build "numbers" are generated using the Build Number Format build definition parameter, which by default is $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r). The $(Rev:.r) part automatically increments, and resets back to 1 when the day change (all this happens separately for each build definition). AFAIK there's no way to reset $(Rev:.r), nor should there be, because that would case multiple builds with the same build number, which would be confusing.
Rather than having your version number stored in source control you can use the build number generated by TFS.
If you change the format from "$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)" to something like "$(BuildDefinitionName)_1.5.$(YY)$(ddd)$(Rev:.r)" then you can set it as part of the build definition.
You can then parse out this number and use it to version your application, and change it how you like by branch, or whatever.
Scenario if given 2 builds how do you view the changesets in the later build that aren't in he earlier. Are there any other ways to view and query changes...
Any thoughts appreciated
Since a label can be edited post hoc it's not possible to get the raw changesets between two labels. The diff commands will only give you file or folder differences.
However, if your builds label by changeset (or label the tip), which is a pretty typical scenario, then it is possible to look at the project history (by changeset) between the times when the two labels were created and build up a picture of what's changed between two points in time.
As a general rule, if your build system supports it, it's always helpful to put something useful in the label comments like 'Label xxxx created for build yyy at changeset zzz' which makes the label history a lot easier to interpret.
If you use Teambuild the build template can be configured to give you a breakdown of changesets since the previous successful build label, which might save you some work going back retrospectively to find the information.
I'm currently looking at a TFS build server setup & I was trying to set up a process whereby I can set up a build template to build to a folder based on the version number of a .NET assembly that's part of the build (As per the assemblyinfo.cs file). I've got it building to the standard looking folder ("Release_20130502.1"), but that's not exactly useful in 4 months time when we want to find the build for the v1.1.0 release.
Basically I want to make a special build template which will create a major release, and I'd like the folders it makes to be more noticable as versions rather than timestamps. I'm also hoping to automatically label the release as that version too. I know how to copy the files & make labels, but I'm not sure how to get at the version numbers.
I'd also love if I could get this into the Build Name recorded in TFS somehow but I suspect that might be a bit optimistic.
Does anyone have any idea how to do this (Or alternatively any other technique that'll get me easily recognizable release version builds)?
Take a look at build number format property for build definitions this is used to generate the build number and in turn the build folder during build and label in sourcecontrol if its enabled, you can modify this manualy to pass desired build number. The mentioned drop folder can be manually given as well. And you can always copy the folder after build by hand.
You can use revision variable to create something that works similiar to what you want, Revision number gets incremented if there is build with same name in system
Format: Release v1.$(Rev).0 - this would give you Release v1.1.0, Release v1.2.0, ... on each build
You will have to customize build definition with custom activity for your defined goal to work without manual interaction. However with details you have provided this approach has issues - each project has its own assembly info - which one do you use, what if they are different? This should get you started.
http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx
You can take a look at these may find something useful
http://tfsbuildextensions.codeplex.com/
It all comes down how often do these build take place, if its week or more then doing it by hand is perfecly valid aproach in my book.
Does TFS offer a way to save, track, and later redeploy builds by build number, or can you only deploy .dlls compiled from the current codebase? I'm looking for functionality similar to what you find in Changeman DS.
Yes. Every build definition in Team Build has a "retention policy" that defines how many historical builds should be kept, depending on certain criteria. You can also mark individual builds as "keep indefinitely." Kind of like a Tivo...
Example walkthru with screenshots: http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
If you need to recover a build that has already been deleted from the drop share, you can do that too -- you'll just have to rebuild it. Simply queue up the build definition, but before you hit Go, type /p:GetVersion="XXX" in the text area at the bottom labeled "additional MSBuild arguments." XXX can be any versionspec, just like you'd use at the tf.exe command line. Examples might be "C12345" or "D1/10/2010" or "LsomeLabel".
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.