這里有一些我們從我們的經驗和一些客戶的顧問工作中收集到的建議和最佳實踐。
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就可以裝載它，或者在它自己的配置文件中包含它，這使得聯合多個公共倉庫變得十分容易。