Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
programmers.stackexchange.com/questions/55946/… is a similar question that may be worth reviewing those answers. –  JB King Apr 2 '12 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 '12 at 10:13
    
I'd assume Release build as the only one to build. Question is to also build the Debug. –  Darian Miller Apr 3 '12 at 14:16
add comment

5 Answers

up vote 7 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
3  
and when your realize that the release is broken just before deploying, you have two hours to unfuck the situation –  Simon Apr 3 '12 at 20:55
add comment

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!

share|improve this answer
1  
+1 for doing what I do :) –  Ian Apr 3 '12 at 20:53
    
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 '12 at 6:31
    
@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? –  Martin Beckett Apr 4 '12 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 '12 at 12:17
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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