Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Integration build process

I agree with everyone's thought's on the need for more testing .... but not sure we're "closed" in the process part of Tim's original post. (If I missed that, let me know, but assuming we're not ....)

I think a formal process of reporting results and "go/no-go" results for I-builds is probably too much bureaucracy for a weekly I-build (though definitively needed for M-builds). [But, I'm sure,  component leads that repeatedly allow bad I-builds (that either fail, or do not run well) will not go unnoticed].

For I-builds, since, in my view, one of their main purposes is to serve as a PDE target for other developers I think its fine to simply assume everyone's done some testing before the I-build, (and eventually we'll have better JUnit testing to catch obvious errors) so if it builds, it should be assumed "good" to use as PDE target. If someone quickly (say, same day) notices a problem that really interferes with using it as a target, then they could "request a rebuild" (and, if they do that on wtp-dev list, everyone would know another was coming soon). If the bad-bug isn't noticed until a day or two later, I think its fair to simply document "use such and such version of xyz plugin with latest I-build to work-around such and such bad bug". (again, on wtp-dev, with reference to bugzilla bug number).

Does this sound like a workable process for "I-builds"? Maybe the answer to this depends on next issue (see point '2').

There's another, related "process" issue I'd like to get some common ground on. I've noticed some teams like to version and release frequently, but others wait until "just before" I-build before versioning and releasing plugins. I prefer the frequent version and release approach -- often once a day, if not more -- basically, when ever changes are made that are intended for the next I-build, that is the time to go ahead and release that project, even if build won't take place for days, and even if more changes are expected. I think there's two advantages for this:

1. Within a team, it allows more "roll-back" and "compare" points if someone accidentally introduces some bad bug in a component.

2. It allows people across teams to "load released projects" (for all map files) to get an early look at how the I-build will behave, just using the development environment, and possibly even PDE tools. This is especially important the day or two before the I-build. Its really not very useful to assume what ever is in head on Tuesday or Wednesday will be in the Thursday I-build -- since some teams may want to "stabilize" on a particular version a day or two before the I-build, but might commit some changes to HEAD, for the following weeks I-build (this has already happened at least once that I'm aware of). In other words, I think each week should see an incremental movement to next I-build, not all at once at end. This allows some testing to take place before the actual I-build.

So, does "frequently release projects" sound like an ok principle?

Thanks all,

Back to the top