5) 处理集成版本
当工作在一个团队中或者多个模块时，你需要依赖中间的没有完成的模块版本。这些版本我们称之为集成版本，因为他们主要的目标就是和其他模块集成来构成或者测试一个运用或者框架。
如果你在模块开发过程中欧那个遵循持续集成的规范，这些集成版本可以被持续集成服务器非常频繁的产生。
因此，如何处理这些可能数量繁多的集成版本呢？
主要有两种方法可以处理它们，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文件可以用于表达更复杂的依赖。
另一方面，以下情况使用内联依赖非常有用：
* 你希望在你的ant构建中使用定制任务
没有ivy的情况下，通常或者是复制定制任务的jar到ant的lib目录下，这需要维护你的工作站安装，或用恰当的classpath通过手工复制或者下载任务定义(taskdef)，这个更多。但是如果你有多个定制任务，或者如果他们有自己的依赖，这将变得非常麻烦。通过内联依赖来使用ivy是解决这个问题的一种优雅的方式。
* 你希望容易部署应用
如果你已经构建了你的应用而它的模块使用ivy，那么用你的ivy仓库来下载你的应用和它所有的依赖到本地文件系统来准备执行是非常容易的。如果你同时将你的配置文件作为制品放置在你的仓库(也行打包为zip文件)，整个安装过程可以依赖ivy，简化你的仓库中可以得到的应用的任意版本的自动安装。
7) 雇用专家
在软件开发时间中构建和依赖管理通常被是 。我们经常看到开发人员在他们有时间的时候实现构建管理。即使这种方式看上去短期内可以节约时间和钱，长期看它通常转为一个非常坏的选择。构建软件不是一个简单的任务，当你想保证自动化，被测试过，完全可重现的构建，发布和安装。另一方面，一旦一个好的可以满足你非常特殊的构建系统被安装好，它可以只依赖很少的对此有良好理解的人，就可以做到持续的质量保证。
因此雇用一个构建和依赖的专家来分析和改进你的构建和发布系统在大多数时间是一个非常好的选择。
8) 反馈
这些最佳实践反映的是我们自己的经验，但是我们不会假装我们掌握了依赖管理或者甚至是ivy使用的唯一真理。
因此请不要客气地在这个页面上面评论来增加你自己的经验反馈，建议或者主张。