7

I've set up our continuous integration system, and it has been working for about a year now. We have finally reached a point where we want to do releases using the same. Before our CI system, the process(es) that was used was:

(Develop) -> Ready for release -> Create a branch -> (Build -> Fix bugs as QA finds them) Loop -> Final build -> Tag

(Develop) -> Ready for release -> (build -> fix bugs) Loop -> Tag



Our CI setup:
1 server for development (DEV)
1 server for qa/release (QA)

The second one has integrated into CI perfectly. I create a branch when the software is ready for release, and the branch never changes thereafter, which means the build is reproduceable without having to change the CI job. Any future development takes place on HEAD, and even maintainence releases get a completely new branch and a completely new job, which remains on the CI system forever, and then some.

The first method is harder to adapt. If the branch changes, the build is not reproduceable unless I use the tag to build [jobs on the CI server uses the branch for QA/RELEASE, and HEAD for development builds].

However, if I use the tag to build, I have to create a new CI job to build from the tag (lose changelog on server), or change the existing job (lose original job configuration).

I know this sounds complicated, and if required, I will rewrite/edit to explain the situation better. However, my question:

[If at all] what process does your company use to release software using continuous integration systems. Is it even done using the CI system, or manually?

3
  • a new CI job ==> as in automated build, or automated testing on commit, or some kind of source code synchronization?
    – rwong
    Commented Feb 8, 2011 at 8:43
  • new CI job = new build setup on the CI system. (Job = 1 project x 1 branch/tag/head). Therefore a single project with two builds (one from head, one from a branch) will have two jobs. Build and testing on commit take place as part of the same job, and source code is synched automatically.
    – Sagar
    Commented Feb 8, 2011 at 13:49
  • I can strongly recommend embedding the build id in your build so that you have a unique identifier from which you can reliably reproduce the source from which the build was built.
    – user1249
    Commented Feb 13, 2011 at 11:34

3 Answers 3

2

We branch on release. I think that's inevitable if you release patches, because patching means going back and updating the release. We also tend to keep coding during the RTM process, which means the shipped release is out of date before it leaves the building. Some of our users skip versions, so right now we have two active versions in the field plus the new version we're working on now. So we have 1.0, 1.1, 2.0, 2.1, 2.2 and soon 3.0 in use (and we get support calls for all of them). Testing the patch/version matrix keeps QA quite busy.

Our process is more like this:

(develop) -> branch to QA -> RTM -> ship -> patch branch ...
          -> keep developing in trunk -> merge patches ...

I'll be interested to see what other options appear.

1
  • Thanks! I think we're in the same boat, except we use dates (trying to get this changed too) for versions (yyyy.mm.dd). The issue seems to be getting back the (current patched version - 1) or (current patched version - 2) build. Arcege seems to have an answer for that (tagging every build).
    – Sagar
    Commented Feb 9, 2011 at 14:32
1

We use the following: (Develop on mainline) -> phase 1 testing -> phase 2 testing -> (Branch from mainline) -> phase 3 testing -> RTM -> Patch on branch

Each build is tagged after the fact. The gold build have a more traditional tag. Development starts working on the next release on the mainline during phase 3 testing.

3
  • What version control do you use? Does tagging every build cause issues for developers (looking up a particular tag in a huge set)?
    – Sagar
    Commented Feb 9, 2011 at 14:33
  • We use Subversion (previously CVS). The build system, Hudson, uses generic tag names (e.g. "JobName_latestsuccess") where it deletes the existing build tag and recreates it from the build's revision. To see the history of the tags, look at the log of the containing directory.
    – Arcege
    Commented Feb 9, 2011 at 15:48
  • We're using Hudson too, and CVS/Subversion both. My only concern is having a very large number of tags when developers need to find a particular one. Thanks!
    – Sagar
    Commented Feb 9, 2011 at 18:01
1

We build from the tag. The build job is parameterized (the parameter is the name of the tag) so it only needed to be created once.

4
  • That's quite interesting. I might try that with our next release. What CI system are you using?
    – Sagar
    Commented Feb 9, 2011 at 14:25
  • We are using Hudson for CI with Subversion for source control. Commented Feb 10, 2011 at 3:24
  • Great! We're using Hudson too. I will give it a try today. Thanks!
    – Sagar
    Commented Feb 10, 2011 at 14:32
  • Didn't work. Apparently the CVS SCM plugin does not like parameters.
    – Sagar
    Commented Feb 10, 2011 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.