Sunday, September 20, 2009

Continuous Integration Patterns (and Anti-Patterns)

I have these nagging questions about the way I've setup a few of my CI builds. (Blog-In-progress)



  1. I have a very granular Hudson build where each of the major build steps are individual jobs rather than have one job that calls each of the steps.  There are pros and cons to this. One of the reasons I chose this is to get better feedback I know what part of the build broke. The other reason was that it was easier to re-order the tasks in a build. I wish Hudson allowed a) build steps to be commeted out, b) build steps to be described c) build steps to be inserted or d) build steps to be re-ordered.  The cons are that there is more to maintain and more to have to replicate when I want to add another branch to CI.
  1. Is it an anti-pattern to use a task (such as a special clean) that is not part of the developer's normal workflow?  I have a groovy task just for the CI that is two lines in a groovy script.  Less code, but it sits outside of the normal use of developers so I forget about it being there and it wouldn't get changed if the main developer's clean got changed (violates DRY).

Burgers are burning.. gotta run.

No comments:

Post a Comment

Followers