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使用的唯一真理。
因此請不要客氣地在這個頁面上面評論來增加你自己的經驗反饋，建議或者主張。