ivy中文参考文档(7)-最佳实践(下)

核心提示： 想象你有一个客户周一过来并要求拿到你的软件的最新版本，用于测试或者示范，ivy中文参考文档(7)-最佳实践(下)(2)，很明显他下午就需要它:-) 现在如果你有持续集成过程并有很好的更变和制品跟踪，实际上你并不需要更多的时间来满足他的要求:-) 但是可能会发生这样的情况，而什么时候应该避免呢？将

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

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

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

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

6)是否将依赖内联(inlining)

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

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

* 分割修订版本周期

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