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.
Related
Is there a way to alter a build using the CLI after having published it?
UseCase: A deployer (be it automated or manual) wants to add additional files (e.g. Testresult-logs) to an already published build (because they need very long to be created but the artifacts of the fresh build should be published asap).
When I redo a jfrog rt bp over and over again I get "new" builds with the same description (same buildnumer etc.) instead of overwriting/extending existing build.
Appreciating any hint :-)
The main idea of the buildinfo in Artifactory is that they are immutable, which means they cannot be modified post publish. This is to make sure the integrity of them.
In your case, a possible way to achieve this may be:
When publishing the artifacts themselves, you might want to not publish the buildinfo.
You can collect buildinfo through your build cycle, and publish everything as a single buildinfo object after all the tests.
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
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).
I would like to have TeamCity Artifacts be checked back into source control.
I have used TFS Integrator before. So I am used to its approach where, through config, it can check in the output builds back into source control. Then when people do a get they will receive these artifacts.
Or is there a completely different way of achieving this with TeamCity?
The two ways I can think of are
VCS Labeling
specify a path in your working directory to label and the location relative to the trunk to check it in. jetbrains explains it here
/project/trunk/dist=>/project/tags/%system.build.number%
from the build script
manually checkin the artifacts from the build script and add an ignore to the place where your checking in to so it doesn't trigger the build again.
e.g. use -:user=devA:project/sources/** to prevent build triggering after a change of VCS user devA made in subfolder project/sources/**
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").