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

4 Answers
4

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

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.

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.