Is it standard practice when setting up a Continuous Integration server to build a Debug and Release version of each project? Most of the time developers code with a Debug mode project configuration set enabled and there could be different library path configurations, compiler defines, or other items configured differently between Debug/Release that would cause them to act differently.

I configured my CI server to build both Debug & Release of each project and I'm wondering if I'm just overthinking it. My assumption is that I'll do this as long as I can get quick feedback and once that happens, then push the Release off to a nightly build perhaps. Is there a 'standard' way of approaching this?

  • programmers.stackexchange.com/questions/55946/… is a similar question that may be worth reviewing those answers.
    – JB King
    Apr 2, 2012 at 18:06
  • 3
    If anything I'd go the other way - if you want to drop one then you need to be building the release version every time not the debug version - since that's the version more likely to be broken...
    – Murph
    Apr 3, 2012 at 10:13
  • I'd assume Release build as the only one to build. Question is to also build the Debug. Apr 3, 2012 at 14:16

5 Answers 5


Building both configurations won't hurt, but if you have to choose (especially due to build time constraints) then build the Release configuration.

You ultimately want to build, test, package and deploy the configuration that your customers will be using and find any issues with it before they do.


Release only.

Assume the developers are doing debug builds anyway and the worst bugs are the 'it works in debug' ones. The quicker you can spot those and narrow down the changes that may have caused them the happier everyone will be!

  • If you have just one component, yes. If you have multiple components, there is a risk that nobody will try a particular component for some time and it breaks, so than you need at least nightly build of everything in all configurations.
    – Jan Hudec
    Apr 4, 2012 at 6:31
  • 1
    @JanHudec - what's the value of a test of a debug build? If the release works but the debug doesn't is that a bug or just a consequence of debug-ness? Apr 4, 2012 at 14:45
  • @MartinBeckett: It's a big nuisance to the next person who will need to debug a real problem on the debug version. Especially when that's few weeks later, which is quite possible if you have multiple components.
    – Jan Hudec
    Apr 5, 2012 at 12:17

I would strongly recommand to build and test both if it can be done in one night.

  • you may detect some heisenbugs
  • you make sure that your client will get the behavior you have tested and validated

You should build everything for which there is any chance that it won't be tried by anybody for some time. Which means, that if you have just one build target, you don't need to do Debug in continuous integration, because the developers will notice quickly. But more often than not there are multiple components and than components not currently being worked on won't be built by developers, but may still be broken by changes in common code. In such cases you need to build all configurations so you won't find the build broken when you need to touch such components.

Now often building everything in every configuration takes a lot of time, so you can't build everything after each commit. In such case, do the release configurations of the most important components every time and add a nightly build of everything.

I currently work on project, where we have continuous build, which polls version control every 10 minutes and even though it's just selected configurations can still take over 1 hour after larger commits. Than we have nightly build, which builds all components in all configurations and always does a clean build, which takes about 5 hours. And than we have a weekly build, that builds releases in all customized variants and that takes more than whole day.


It depends on your project. In my current project we only build debug (and run unit tests) on every commit while we do build release version as part of the "deployment build".

At the last company I worked we had a few issues with release version working a bit differently so we did build debug and release on every commit and run unit tests on both.

  • 4
    and when your realize that the release is broken just before deploying, you have two hours to unfuck the situation Apr 3, 2012 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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