Answers inline prefaced with MG: On Tue, Jun 19, 2012 at 3:48 PM, Joel Dice <joel.d...@gmail.com> wrote:
> Hi Mitch, > > Thanks for your response. Please see my comments below. > > > > Yes, that's what happens on the CI server. Are you suggesting that each > developer run a CI server on his or her development machine and let it take > care of cascading changes? > MG: No, what I'm suggesting is that, whatever modules a developer is actively working on, they publish them to a local Ivy repository. The more modules you're actively developing, the more it behooves you to automate a multimodule build. > > Also, I don't necessarily want to rebuild every module that depends > directly or indirectly on the one I just changed. Instead, I normally want > to rebuild the minimum amount of code needed to test a specific top-level > (i.e. most-dependent) project. Once I'm happy with my change as far as it > concerns that project, I can kick off builds of other projects that depend > on the module(s) I've changed and run their respective tests, but it make > take several iterations of debugging the initial project before I get to > that point. > > MG: If you're actively integrating the changes in your component project against some dependent projects but not others, then the latter projects should not be depending on integration versions. They should be waiting for milestone or release versions to come out. Also, there's something curious about the following language: "Once I'm happy with my change as far as it concerns that project, I can kick off builds of other projects..." There should be no manual steps in the process, at least on the CI server. Once you check in changes to one project, you should let them bubble up automatically to everything that depends on their integration versions. Cascading builds on a CI server is a cost-free exercise, and if something is good enough to check in, it's good enough to check about its downstream effects. There's always revert. > >> > I don't think that will give me reentrant builds, though. If I kick off > two builds at around the same time (say the build takes a while and I want > to build and test two separate changes in parallel), it's non-deterministic > as to what I'll end up with when the most-dependent module is built. > MG: Take the example of Jenkins/Hudson. You're never going to have Jenkins jobs for B running simultaneously. Plus, for each build, you're always going to know which commit on which project manually kicked off each build stream. Plus, you know exactly which version of each project has been built and published along with the precise versions of the things it depends on. All the things you should care about are deterministic. The build you care the most about is the latest one. You want to get the latest green. You want to keep it green. And if you do see a red, you want to be able to reproduce it in some way in case you can't readily explain what went wrong. It sounds like at this point we're digressing away from the particulars of Ivy usage and into a broader discussion of continuous integration philosophy, so I'm probably going to have to let this be my last word on this mailing list thread. > >
