The problem with using an IDE as the sole means to build your software (i.e. on your integration build machine) is that it’s unlikely your IDE will be deployed into production (or at least it shouldn’t be). One of the themes I visit in chapter 2 of the book is that of reducing assumptions (risks or whatever you want to call them). Many of the IDEs wrap everything but the kitchen sink into them (I won’t name any names), so if you assume that the particular files and configuration provided by the IDE are there, you are setting yourself up for problems. If you can’t script your build, be ready to debug problems right before you’re ready to release into production…or worse, when your users are using the software. As a developer, use your IDE to execute your automated build. However, your automated build should have no dependencies with your IDE.

This entry was posted on Wednesday, June 13th, 2007 at 12:34 pm and is filed under Practices, /Paul, Continuous Integration. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.