软件配置管理案例分析4： depend build

laofo

作者：xiaoxiang7788 版权所有
出自 配置管理之路 http://bbs.scmroad.com

案例分析：
    话说小菜同学，执着于配置管理和持续集成的精典理论与实践。某日，公司高层心血来潮，单独成立一个项目组专门为公司产品研发一个免费版以提高公司产品知名度，于是项目组被命名为Free Group，免费版产品命名为Free。

    Free Leader在经过一系统的筹备与策划后，把项目分成了8个小项目，每个小项目对应一个jar包。最后进行集成，统一成Free.zip 并发布。在我们强大的小菜同学的配置管理和持续集成的支持下，项目有条不紊的进行着。

    小菜怎么做的呢？通过各种各样的沟通，一套集成环境终于出来了。是这样的，将jar的依赖关系按前后顺序排好，每检测到SVN库有变化便将所有的jar包rebuild一次，最后生成Free.zip。

    两个月后，Free Leader变卦了。说没必要每次都build所有的jar, 只需要哪个有变化build哪个即可，原因呢是因为jar包名字是name+builddate.jar，如果每次所有的都重打，影响他们的update 机制。这种情况下，小菜骂人了，他为什么骂人呢？原因如下：

    8个小项目，树状依赖，哪个节点变化build哪个。那如果上层的节点有变化，我build完了，下层依赖于它的要不要build呢？如果要build，那8个小项目的持续集成怎么做？如果不build，如何能尽早尽快发现问题？还有，持续集成环境怎么入库管理？另外就是本来是一套集成环境，现在要改为8 套，甚至更多，小菜不骂人才怪呢。

这种情况下，小菜来请教大家他应该怎么办？应该如何处理这种情况？