CODEWITHSUNDEEP
build-processversioningteamcity
Jonn
Jonn

Reputation: 4661

Teamcity Weekly Release Versioning and Workflow

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?

Upvotes: 1

Views: 480

Answers (2)

devdigital
devdigital

Reputation: 34349

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

Upvotes: 1

Orn Kristjansson
Orn Kristjansson

Reputation: 3485

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...

Upvotes: 1

Related Questions