这里有一些我们从我们的经验和一些客户的顾问工作中收集到的建议和最佳实践。
1) 为所有的模块添加模块描述符
在ivy的世界种，模块描述符是ivy文件的一种，基本上是简单的xml文件，用来描述模块生产什么作为制品和它的依赖。
为你的开发涉及到的所有模块编写或者下载模块描述符是一个好习惯，甚至是为你的第三方依赖，哪怕他们不提供他们自己的模块描述 符。
开始这将看上去像是一个额外的工作，并且需要时间。但是当你拥有多个模块同时使用相同的第三方类库，你仅仅需要在你的ivy文件 中添加一行就可以得到这个类库和它特有的你真正需要的依赖(如果你的仓库中有正确的模块描述符，尤其是和模块配置一起使用)。当你 想更新一个依赖时它将非常有帮助。在你的模块的 ivy文件中一个简单的修改就可以得到更新过的版本和它更新(或者没有)过的依赖。
因此我们推荐在你的仓库中为所有的模块添加ivy文件，你甚至可以通过设置你的解析器上的allownomd 属性为false来强制执行这个规 则。你不需要使用依赖制品的包含/排除/specification这些ivy特性，这些仅仅可以用于非常特殊的情况。
2) 使用自己的企业仓库
对于开源项目而言这通常不是一个正确的建议，但是对于企业世界我们强烈建议遮掩做来避免依赖一个公共的仓库类似mave ibiblio 或者ivyrep.为什么? 好，这里有一堆理由:
1.控制
对于公共仓库最主要的问题在于你没有仓库的控制权。这意味着如果一个模块描述符损坏，你不能轻易的修复它。当然你可以使用一个 由共享仓库和公共仓库组成的链，并且将你修复后的模块描述符放置到共享仓库以便它能隐藏公共仓库，但是这会导致仓库浏览和维护的 麻烦。
更多的问题在于仓库可能的更新。我们知道在仓库中发布的版本应该保持稳定并且不要更新，但是我们也频繁的看到模块描述符有很多 bug，或者制品被损坏。甚至某些时候我们看到一个新的版本使用和之前版本相同的名字发布，因为前一个版本只不过是被错误打包。这种 情况设置发生在最好的东西上，比如我们的 ivy1.2 :-)。 后来我们决定发布一个新的使用不同名字1.2a的版本。但是如果仓库管理员容 许类似的更新，这意味着以前的工作可以被打破。这将破坏你的构建的可再现性。
2.可靠性
mave仓库的可靠性并不是很好(我们经常体验到非常慢的速度，甚至完全无法访问)，同时ivyrep仅仅被一个小公司支持(是的，我们仅 仅是一个小公司).因为速度慢和网站挂起的情况会同样发生。并且如果你依赖的仓库倒下，这将导致你的开发或者发布过程严重减缓。
3.准确性
公共的仓库通常包含远比你实际需要多的东西。这是一个问题吗？我们是这样想的。我们认为在一个企业环境中你使用的类库在被你的 公司的每个项目使用前需要有一些验证过程。而做这个事情做好的方式是什么？建立一个仅仅包含你实际需要使用的类库的企业仓库。这 将不仅仅可以保证你的运用依赖有更好的质量,而且帮助你在每个地方使用相同的版本，甚至可以再申明你的模块依赖时得到帮助。如果你 使用类似ivyde的工具，代码自动完成会紧紧显示你仓库的恰当信息，和你实际需要使用的类库。
4.安全
从模块仓库瞎子啊的制品通常是可执行的，这将牵扯到安全问题。想象一个黑客用一个包含病毒的版本替换commons-lang？如果你依赖 公共仓库来构建你的软件，它将有安全方面的风险。你在这里看到可以看到更多的相关信息 Forrester article。
注意，不是说因为要使用企业仓库就不得不彻底的通过手工来构建。ivy有一个安装任务可以被用来从一个仓库安装模块到另外一个， 因此它可以用来有选择的从公共仓库安装模块到你的企业仓库，这里你将有能力确保控制，可靠性和准确性。
3) 至少在组织和模块上使用模式
ivy非常灵活并且通过使用模式的概念可以适应很多现存的仓库。但是如果你的仓库现在还不存在，我们强烈建议总是在你的模式中使 用组织和模块名，甚至是你仅仅放置你自己的模块的私有仓库(这里所有的组织都是相同的)。为什么？因为ivy listing feature(清单特 性?)依赖在模式中找到的标记。如果你的模式中没有组织标记，ivy将不能列出你仓库中的组织。举例说对于在ivyde中的代码自动完成这 将是一个问题，同样对于仓库范围的任务如安装和仓库报告也是如此。
4) 为公共仓库发布ivysettings.xml
如果你创建了一个公共仓库，请提供一个ivysettings.xml对应的URL地址。这很容易做到，如果有人想leverage你的仓库，他仅仅需要 设置这个你的ivysettings.xml的URL就可以装载它，或者在它自己的配置文件中包含它，这使得联合多个公共仓库变得十分容易。