13

A typical solution is to have a CI (Continuous Integration) build running on a build server: It will analyze the source code, make build (in debug) and run tests, measure test coverage, etc.

Now, another build type usually known is "Nightly build": do slow stuff like create code documents, make a setup package, deploy to test environment, and run automatic (smoke or acceptance) tests against the test environment, etc.

Now, the question:

  • Is it better to have a third separate "Release build" as release build?
  • Or do "Nightly build" in release mode and use it as a release?

What are you using in your company?

(The release build should also add some kind of tag to source control of potential product version.)

Improve this question

4 Answers 4

Reset to default
13

A case for having the release build equal to the nightly build is: you want to test exactly the same stuff what you release. You don't want to discover bugs in production which could have been detected in dev testing already.

The difference between release and nightly builds:

  • nightly build is run automatically, well, every night, while release build should be run by hand at certain points in time
  • release build should ideally tag / branch the source code, and possibly deploy the build artifact(s) in a central repo (e.g. when using Maven)

These differences are in practice a few extra options in most build management systems I know. To minimize the chance of human errors, these could be saved e.g. in a batch/script file which takes only the necessary parameters (and validates them).

Improve this answer
7

Well I would want the release build to be as close in process to the nightly as possible! Ideally exactly the same but with a tag.

The thing is if your release build and nightly are not the same there is a chance that whatever is different could mask a problem (or make tracking one down that much harder).

Improve this answer
3

I would have one single build process, that would build everything every check-in run by the CI service. That would be both debug and release builds.

Having two or three separate processes is just asking for them to start changing randomly without being documented, and it won't be long before someone finds themselves having to do 15 steps for every potential release to get it ready to go out the door.

Improve this answer
1
  • My company is a lot like this with 4 different build processes. We need to change that.
    – Brandon
    Aug 27, 2013 at 23:30
2

One thing I'm keen on doing is putting the nightly build in release mode rather than debug mode. With logging frameworks such as log4net replacing System.Diagnostics.Debug the main differences between Release and Debug modes are object lifetimes and code optimisations.

Unless you are actually going to be attaching a debugger to your nightly build then I'd suggest doing this as well.

The process we follow is that the nightly build runs every night and if that works then we can deploy the same build to our other servers (no rebuilding, just take the packaged installers and run them). If we have a problem with the nightly build then we check in the changes to it on a branch, and run a 'nightly' build off that branch during the day. The tests can then be re-run.

Improve this answer

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.