构建快照与本地编译代码的争论?

时间:2011-01-27 15:55:50

标签: java maven-2 ant continuous-integration compilation

我们有一大批项目。它是使用ant目标构建的,它可以调用一堆独立的maven项目。

问题是,每当开发人员将代码提交给我正在处理的单独项目时,我必须更新代码并在本地重新构建,以确保我正在编译最新版本。这包括每次等待30-60分钟,以测试代码更改。

我们希望关闭'快照'罐子中的所有项目,因此每次发生代码更改时,我们的本地版本应该只下载最新的快照。

有人担心,由于持续集成服务器需要一个多小时来构建项目,因此我们的快照可能比最新代码落后一小时,并且建立它们不会是我们的代码编译的保证。最新。

这是一个共同的问题,如果是这样,它如何减轻?在转换为使用快照时,我可以向团队提出任何好的论据吗?

2 个答案:

答案 0 :(得分:1)

如何让任何更改组件界面的人也负责确保依赖它的所有组件仍然有效,即单个提交包含API更改,实现更改以及使所有其他组件构建所需的更改新版本。

这鼓励对不兼容的API更改进行长时间的思考,并在提交不再编译的组件时导致版本控制中的显式冲突。

根据您的内部策略,您还可以接受引入新API,同时将旧版本标记为已弃用,同时保持功能不变;但是我发现这对你的开发人员来说有些不礼貌。

答案 1 :(得分:0)

在确保代码是最新的时,小时代码真的会成为交易破坏者吗?除非有重大变化或重写,否则我无法看到一个变化会破坏其他一切。

我还看到你目前的情况是编译每个构建的所有依赖项,大约需要30-60分钟。根据最近可用的构建编译你的项目不是很好吗,这需要我假设5-10分钟,然后继续编程?

我也看不出一个重大变化如何不会成为破碎的东西。当您针对一小时的依赖项构建检查代码,然后该依赖项更改为它破坏代码的位置时,您的代码仍然被破坏。你现在只是在修复发生时转移。