1

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?

Jonn
  • 4,404
  • 7
  • 43
  • 65
  • I do not understand why you would point away from the trunk to the tag after you tag the build. Don't you want to keep developing on the trunk and building from it as well ? – Orn Kristjansson Oct 20 '11 at 02:38
  • Edited it. I meant point the new build config that I created for the tag to the release folder. – Jonn Oct 20 '11 at 04:42

2 Answers2

1

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

Community
  • 1
  • 1
devdigital
  • 33,472
  • 8
  • 93
  • 117
  • How can teamcity grab the version number from the file? – Jonn Oct 21 '11 at 01:29
  • Answer updated. I would certainly go this route to keep the process automated, otherwise it could become insufferable to maintain if you have to change the build version manually each week. – devdigital Oct 21 '11 at 05:40
1

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

Orn Kristjansson
  • 3,417
  • 4
  • 23
  • 37
  • I'm not exactly changing. I'm maintaining both build configs in this case and when a bug fix needs to be issued I do branch from the tag and then merge the changes back to it. The build config then runs on my tag folder. Does my workflow need changing? – Jonn Oct 21 '11 at 01:42
  • 1
    What you need to change is to have the build config run from the branch not the tag folder. As I pointed at before, tags should only be a snapshot in time ( they should not be changed once they are made ). Branches are used to do development that differs from the trunk. If you create a branch from a tag you should never check it back on the tag. Take a look at the first answer here as well - http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-really-mean – Orn Kristjansson Oct 21 '11 at 02:42
  • Shoot. I've been doing it wrong all along. I've read that post before but understood tags as snapshots where I build into afterwards. Thanks for the correction. But then does the increment remain as a manual task? – Jonn Oct 21 '11 at 03:09
  • Like you state, now you have one configuration for trunk and one for branch. I would just update the minor by hand each week. The branch configuration might or might not be one version behind ? – Orn Kristjansson Oct 21 '11 at 15:10