I'm trying to get a weekly release up and running in TeamCity and I'm having a hard time trying to comprehend how I'm going to version it. Currently versioning goes as follows
[major].[minor].[buildnumber].[svnrevision]
major = major release
minor = incremented on release (weekly-basis) to production
buildnumber = teamcity's autoincremented build number
svnrevision = revision number from svn
Does this mean that every week, after creating a tag, I'll have to create a separate Build Configuration for the new release just so I could increment the minor version like so?
1.1.{0}.%build.vcs.number.*%
to
1.2.{0}.%build.vcs.number.*%
and point the new build config from trunk to the tags\release-1.1.0 folder?
Is there no easier way to do this?
I guess I'm a little bit confused as to why you would change your build configuration from the trunk to the tag / release folder as the codebase version number changes.
If I were doing it, I would simply create one configuration that builds from the trunk. Once a week you can up the version number, say from 1.1.x.x to 1.2.x.x in the TeamCity configuration screen and keep building from trunk. Next week you up it to 1.3.x.x and you keep building from trunk.
Usually the tags are just meant to be snapshots in time, it is the exact source that was used to make a certain build back in time. I would expect your tags build folder to look more like \tags\release-1.1.232.3232, etc.
Sometimes you might have to take a specific tag and create a branch out of it. That is if you need to work on a former release to do some bugfixes before you release your next version ( from trunk ). In that case I would create a new configuration to do the branch build, the codebase would then be something like \branches\release-1.1.0
Now you have one configuration for the trunk, that one will probably be at 1.2 or 1.3 and keeps incrementing while the branch configuration will be at 1.1 or something similar. At a later time you might use the branch configuration for another version number since bugfixes are done in 1.1 like you suggested with the tags.
It seems to me from reading this over again that perhaps your using the concept of branches as tags...
In TeamCity 6 and up, you can have multiple build steps.
You could create an initial build step, before the actual build, which uses a custom MSBuild task. This would check out a global AssemblyInfo.cs file which all projects link to (see Automatic assembly version number management in VS2008) for more details), grabs the version number from the file, increments the minor revision, writes the new value back, and checks in the updated file.
Additional build steps would then run the build, and tag.
You can communicate updates to TeamCity from your build script using service messages, including reporting the build number, see http://confluence.jetbrains.net/display/TCD65/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingBuildNumber
Related
I just started working with ant a few days ago. Right now I have a general buildall.xml which should call each project's build.xml. Because some projects depend on each other, I need to rebuild some other projects which depend on it. This isn't a problem--I'm just setting the depends property of the target. However, ant is always building the dependencies, even when the files haven't changed.
Let's say project1 has no dependencies; project2 depends on project1; project3 depends on project1, 2; project4 depends on project1, 2, and 3; and so on.
I could hack a solution which looks at project K, and checks if project 1 .. project K have updated files using uptodate. If so, then run the target. This is messy and appears unnecessary.
What is the cleanest way to implement this?
EDIT: So I decided to just hack in a bunch of targets, "check_projectK" where it does the uptodate checks on all of its source files, its build file, and the build files of the 1 .. K-1 projects. Due to dependencies, this is always handled correctly. However, this is still a large amount of copy and paste for a large workspace. I will leave this open.
Short answer, ANT can't do it, not unless you have some kind of way to connect to your version control system and check if anything has changed (you are using source control right?). Ant doesn't know about when what the last time a file changed and then see if it matches with what was built; it doesn't have the concept of a dependency repository. The whole purpose of Ant is that it just builds.
The solution to your problem isn't Ant, it's Maven. Maven HAS a dependency repository. There's also a very nifty plugin for Maven used specifically with Flex appropriately called FlexMojos. By using this, Maven can know when something was last built because it's uploaded to the repository. Then your other projects can add it's dependencies and download the SWC needed.
On top of that, it mixes great with a continuous integration engine like Hudson, Bamboo and Teamcity, which builds a project every time a file has been committed to your source control system, and then updates all dependent projects automatically!
I want to obtain the assembly version from my solution and apply that to a cc.net label. I think I'm doing it backwards since all the info out there have the CI server set the version. But I'm not sure how to integrate different release versions and the development branch into CI. Every time we release we up the revision number. Would/should I add a new project in cc.net for every branch? Is there a way to automatically get the latest branch? Sorry for so many different questions in one...question. I'm new to this CI stuff.
FinalBuilder and the AssemblyInfo Updater
[Update : Cool, can't add hyperlinks. Put FinalBuilder and 3xw en dotcom in the end in front of the following url:)
/Products/FinalBuilder/FeatureMatrix/FeaturesCompilerActions/tabid/98/Default.aspx
Use "PropertySet Define" based on .NET Assembly Numbers
Use "PropertySet Load"
Use "PropertySet Incremement"
Use "AssemblyInfo Updater" to save it again
And you're done. :)
You will find this all much easier if you switch to TeamCity. I've wrestled with so many nant scripts/cruisecontrol config files in the past I'm almost blind from angle brackets.
I cried like the accountant who was shown the first spreadsheet program when I started messing with TeamCity. It will make your life 1000% easier.
We currently have a CruiseControl.Net server that is merrily building the trunk on our svn server. I have a new requirement to build the "latest" branch as well; is there a best practice in CruiseControl to handle this? What specific changes are needed to build from the trunk and a branch at the same time?
Make a second project just like the original where the source control is pointed to the proper branch.
As far as Cruisecontrol.net is concerned, a project is a project. It doesn't care whether it's a branch or a trunk. Simply setup another project in the ccnet.config that points to where the branch is located.
To keep things organized, i like to add the version number to the name of the branch projects like this:
ProjectX <- Trunk
ProjectX-4.0 <- Historical branch for v4.0
I generally create a new working directory named branch, set up the source control to monitor the branch and pull to the new folder. I also put in an exculusion filter on the trunk build so it does not get kicked off by a check in to the branch (our branches usually reside within the trunk realm of checking for changes). I also remember to change the labels, if we label, to reflect the branch naming convention. One very helpful thing you can do is if you will only ever have one branch active simply name it branch that way once you have your configuration all set You only have to comment or uncomment those parts in the config file as needed, instead of having to upgrade it in all the places like if one time it is branch 6.1 and next time it is 6.2, it saves a lot of cut and replace and I only have to changed the project name and the label the next time we use a branch.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.
What are the strategies for versioning of a web application/ website?
I notice that here in the Beta there is an svn revision number in the footer and that's ideal for an application that uses svn over one repository. But what if you use externals or a different source control application that versions separate files?
It seems easy for a Desktop app, but I can't seem to find a suitable way of versioning for an asp.net web application.
NB I'm not sure that I have been totally clear with my question.
What I want to know is how to build and auto increment a version number for an asp.net application.
I'm not interested in how to link it with svn.
I think what you are looking for is something like this: How to auto-increment assembly version using a custom MSBuild task. It's a little old but I think it will work.
For my big apps I just use a incrementing version number id (1.0, 1.1, ...) that i store in a comment of the main file (usually index.php).
For just websites I usually just have a revision number (1,2,3,...).
I have a tendency to stick with basic integers at first (1,2,3), moving onto rational numbers (2.1, 3.13) when things get bigger...
Tried using fruit at one point, that works well for a small office. Oh, the 'banana' release? looks over in the corner "yeah... that's getting pretty old now..."
Unfortunately, confusion started to set in when the development team grew, is it an Orange, or Mandarin, or Tangelo? It looks ok. What do you mean "rotten on the inside?"
... but in all honesty. Setup a separate repository as a master, development goes on in various repositories. For every scheduled release everything is checked into the master repository so that you can quickly roll back when something goes wrong.
(I'm assuming dev/test/production are all separate servers, and dev is never allowed to touch production or the master repository....)
I maintain a system of web applications with various components that live in separate SVN repos. To be able to version track the system as a whole, I have another SVN repo which contains all other repos as external references. It also contains install / setup script(s) to deploy the whole thing. With that setup, the SVN revision number of the "metarepository" could possibly be used for versioning the complete system.
In another case, I include the SVN revision via SVN keywords in a class file that serves no other purpose (to avoid the risk of keyword substitution breaking my code). The class in that file contains a string variable that is manipulated by SVN and parsed by a class method.
An inconvenience with both approaches is that the revision number is not automatically updated by changes in the externals (approach 1) or the rest of the code (approach 2).
During internal development, I'm using milestone numbers (M1, M2, M3...). After release, I'll probably just update dates ("the January 2009 update").