ivy中文参考文档（7）-最佳实践（下）

ivy中文参考文档（7）-最佳实践（下）2012-07-30 BlogJava sky5）处理集成版本

当工作在一个团队中或者多个模块时，你需要依赖中间的没有完成的模块版本。这些版本我们称之为集成版本，因为他们主要的目标就是和其他模块集成来构成或者测试一个运用或者框架。

如果你在模块开发过程中欧那个遵循持续集成的规范，这些集成版本可以被持续集成服务器非常频繁的产生。

因此，如何处理这些可能数量繁多的集成版本呢？

主要有两种方法可以处理它们，ivy目前都支持：

1. 使用命名约定如一个特殊的后缀

这个主意非常简单，每次你发布你的模块的一个新的集成你使用相同的名字给这个版本（例如在maven世界中的 1.0-SNAPSHOT）。然后依赖管理器意识到这个版本是特殊的因为它始终在改动，因此它将不信任本地缓存，如果它已经有了这个版本。而是去检查仓库中这个版本的数据看它是否有改动。在ivy中对这个的支持是通过在依赖上使用changing 属性或者配置changing模式来使用所有的模块的方式来实现的。

2. 每次自动创建一个新版本

这种情况下使用build number或者时间戳来使用新的版本名称发布每个新的版本。然后你可以使用ivy提供的多个方式中的一个来"明确版本约束"。通常选择最新的一个（使用"latest.integration"作为版本约束）就足够了。

哪个方法最好？通常，这取决于你的上下文，如果这两个方法中的任何一个实际上不好用那么ivy不会去支持它:-）

但是通常我们推荐使用第二个方法，因为每次你发布一个新的版本时使用一个新的版本名称更符合版本身份规范，并且可以使你的所有的构建可重现，即使是集成版本。有趣的是，在你的构建系统中进行一些工作后，它可以引入一种机制来提升集成构建到更稳定的状态，类似里程碑或者发布。

想象你有一个客户周一过来并要求拿到你的软件的最新版本，用于测试或者示范。很明显他下午就需要它:-）现在如果你有持续集成过程并有很好的更变和制品跟踪，实际上你并不需要更多的时间来满足他的要求:-）但是可能会发生这样的情况，你的最后的一个足够稳定可以用于客户的版本实际上市几天前构建的，因为最新的版本刚好破坏了一个特性或者引入了一个新的不想交付的特性。在这种情况下，如果你需要你可以交付这个"稳定"的集成构建，但是请确认，几天或者几个星期甚至几个月后，你的客户将要求在这个仅仅用于示范的版本上的一个bug修订。为什么？因为他是客户，而我们都知道他们会如何:-）

因此，在你的仓库中为每个构建使用构建版本提升特性，这个解决方案将非常容易：例如，当客户要求版本时，你不仅仅交付集成构建，而且你也提升构建到一个里程碑状态。这个提升显示你将在长时间内保持对这个版本的追踪，以便可以返回到这个版本并且在需要时创建分支。

不幸的是ivy自身不考虑持有这样的可重现的构建，很简单，ivy是依赖管理器，不是构建工具。但是如果你使用不同的名字发布唯一版本，并在发布或模块递归发布的过程中使用ivy特性比如版本约束替换，将十分有帮助。

另一方面，这个解决方案的主要缺点就是它将产生大量的中间版本，而你将不得不在你的仓库中运行很多清理脚本，非常你的公司名以 G 开头以oogle结尾 :-）

6）是否将依赖内联（inlining）

在ivy1.4中，你可以解析一个依赖而不需要写ivy文件。这被成为"内联（inlining）"。但是它对什么有利，而什么时候应该避免呢？

将ivy依赖放置到一个单独文件有以下的优点：

* 分割修订版本周期

如果你的依赖可能比你的构建更频繁的改动，那么将这两个分隔是一个好主意，可以独立出两个概念：描述如何构建和描述你的项目依赖。

* 发布的可能性

如果你描述一个自身可以被复用的模块的依赖，你希望将它发布到仓库。在这种情况下只有你有单独的ivy文件发布才有可能。

* 更灵活

内联依赖仅仅能用于表达一个依赖并且只能一个。ivy文件可以用于表达更复杂的依赖。

另一方面，以下情况使用内联依赖非常有用：