• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Continuous Integration: builds and version tags

 
Gian Franco
blacksmith
Ranch Hand
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

My CruiseControl now builds according to the changes in the HEAD branch (i.e. mainline), I made this a simple setting in a properties file the build.xml uses: tag.name=HEAD

If I want to build a version or branch I could change this to for example tag.name=ver50 where ver40 is a version tag in cvs for the given project.

But how could I organize this differently so that:
1.) I can use a succesful build of the mainline,
2.) deploy it, test it (functional, acceptance),
3.) deploy it in production, and
3.) tag the mainline at the point the build was made without including any changes to the mainline code introduced after that build was made?

I'm afraid I should create a version everytime a build succeeds, is this so,
or could I solve it in some other way.

Gian
 
Adeel Ansari
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gian Franco:

I'm afraid I should create a version everytime a build succeeds, is this so,
or could I solve it in some other way.



I don't think so.

We are using Cruise Control as integration tool. We just deal with the trunk, which is the main svn repository in our case. We seldom pull out a new branch for doing new story cards, - when there is a chance of complex conflicts - and after a we release a version to our test team. Meanwhile we continue the work in Trunk and wait for the feedback from test team. Once all tested we create a tag from the branch - which is immutable logically in our case. So, we can release any version any time to any client in case. If got few bugs in the release we don't create the tag then we fix the things in branch after getting OK signal, we merge the changes to trunk and create the tag from the branch. So, the idea is our branches and tags are not really participating in continuous integration. Yes, after merging those back to trunk would do the thing. Branches was pulled out from the trunk, it guarantees the code. We normally do bugfixes in branches, so it doesn't really participate into CI process, I believe. But yes, if we do new story cards in a branch, lets say, then we don't keep that branch apart too long, we merge it back to trunk as soon as possible.
 
Gian Franco
blacksmith
Ranch Hand
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Adeel,

I didn't look at it that way yet.

Do you let CC make the branches automatically
after a successful build?

Gian
 
Adeel Ansari
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gian Franco:
Do you let CC make the branches automatically
after a successful build?


No. As I said, we do it manually when we plan a next release. We create a branch for that and fix bugs in that branch in case. After release we make a tag from that branch, which is logically immutable, and merge the branch back to trunk if has some fixes/modifications.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Adeel Ansari:

No. As I said, we do it manually when we plan a next release. We create a branch for that and fix bugs in that branch in case. After release we make a tag from that branch, which is logically immutable, and merge the branch back to trunk if has some fixes/modifications.


Same here.
 
Gian Franco
blacksmith
Ranch Hand
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, it's clear.

Gian
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic