5) 處理集成版本
當(dāng)工作在一個(gè)團(tuán)隊(duì)中或者多個(gè)模塊時(shí)，你需要依賴中間的沒有完成的模塊版本。這些版本我們稱之為集成版本，因?yàn)樗麄冎饕哪繕?biāo)就是和其他模塊集成來構(gòu)成或者測(cè)試一個(gè)運(yùn)用或者框架。
如果你在模塊開發(fā)過程中歐那個(gè)遵循持續(xù)集成的規(guī)范，這些集成版本可以被持續(xù)集成服務(wù)器非常頻繁的產(chǎn)生。
因此，如何處理這些可能數(shù)量繁多的集成版本呢？
主要有兩種方法可以處理它們，ivy目前都支持：
1. 使用命名約定如一個(gè)特殊的后綴
這個(gè)主意非常簡(jiǎn)單，每次你發(fā)布你的模塊的一個(gè)新的集成你使用相同的名字給這個(gè)版本(例如在maven世界中的 1.0-SNAPSHOT)。然后依賴管理器意識(shí)到這個(gè)版本是特殊的因?yàn)樗冀K在改動(dòng)，因此它將不信任本地緩存，如果它已經(jīng)有了這個(gè)版本。而是去檢查倉庫中這個(gè)版本的數(shù)據(jù)看它是否有改動(dòng)。在ivy中對(duì)這個(gè)的支持是通過在依賴上使用changing 屬性或者配置changing模式來使用所有的模塊的方式來實(shí)現(xiàn)的。
2. 每次自動(dòng)創(chuàng)建一個(gè)新版本
這種情況下使用build number或者時(shí)間戳來使用新的版本名稱發(fā)布每個(gè)新的版本。然后你可以使用ivy提供的多個(gè)方式中的一個(gè)來"明確版本約束"。通常選擇最新的一個(gè)(使用'latest.integration'作為版本約束)就足夠了。
哪個(gè)方法最好？通常，這取決于你的上下文，如果這兩個(gè)方法中的任何一個(gè)實(shí)際上不好用那么ivy不會(huì)去支持它:-)
但是通常我們推薦使用第二個(gè)方法，因?yàn)槊看文惆l(fā)布一個(gè)新的版本時(shí)使用一個(gè)新的版本名稱更符合版本身份規(guī)范，并且可以使你的所有的構(gòu)建可重現(xiàn)，即使是集成版本。有趣的是，在你的構(gòu)建系統(tǒng)中進(jìn)行一些工作后，它可以引入一種機(jī)制來提升集成構(gòu)建到更穩(wěn)定的狀態(tài)，類似里程碑或者發(fā)布。
想象你有一個(gè)客戶周一過來并要求拿到你的軟件的最新版本，用于測(cè)試或者示范。很明顯他下午就需要它:-) 現(xiàn)在如果你有持續(xù)集成過程并有很好的更變和制品跟蹤，實(shí)際上你并不需要更多的時(shí)間來滿足他的要求:-) 但是可能會(huì)發(fā)生這樣的情況，你的最后的一個(gè)足夠穩(wěn)定可以用于客戶的版本實(shí)際上市幾天前構(gòu)建的，因?yàn)樽钚碌陌姹緞偤闷茐牧艘粋€(gè)特性或者引入了一個(gè)新的不想交付的特性。在這種情況下，如果你需要你可以交付這個(gè)'穩(wěn)定'的集成構(gòu)建，但是請(qǐng)確認(rèn)，幾天或者幾個(gè)星期甚至幾個(gè)月后，你的客戶將要求在這個(gè)僅僅用于示范的版本上的一個(gè)bug修訂。為什么？因?yàn)樗强蛻簦覀兌贾浪麄儠?huì)如何:-)
因此，在你的倉庫中為每個(gè)構(gòu)建使用構(gòu)建版本提升特性，這個(gè)解決方案將非常容易：例如，當(dāng)客戶要求版本時(shí)，你不僅僅交付集成構(gòu)建，而且你也提升構(gòu)建到一個(gè)里程碑狀態(tài)。這個(gè)提升顯示你將在長(zhǎng)時(shí)間內(nèi)保持對(duì)這個(gè)版本的追蹤，以便可以返回到這個(gè)版本并且在需要時(shí)創(chuàng)建分支。
不幸的是ivy自身不考慮持有這樣的可重現(xiàn)的構(gòu)建，很簡(jiǎn)單，ivy是依賴管理器，不是構(gòu)建工具。但是如果你使用不同的名字發(fā)布唯一版本，并在發(fā)布或模塊遞歸發(fā)布的過程中使用ivy特性比如版本約束替換，將十分有幫助。
另一方面，這個(gè)解決方案的主要缺點(diǎn)就是它將產(chǎn)生大量的中間版本，而你將不得不在你的倉庫中運(yùn)行很多清理腳本，非常你的公司名以G 開頭以oogle結(jié)尾 :-)
6)是否將依賴內(nèi)聯(lián)(inlining)
在ivy1.4中，你可以解析一個(gè)依賴而不需要寫ivy文件。這被成為"內(nèi)聯(lián)(inlining)"。但是它對(duì)什么有利，而什么時(shí)候應(yīng)該避免呢？
將ivy依賴放置到一個(gè)單獨(dú)文件有以下的優(yōu)點(diǎn)：
* 分割修訂版本周期
如果你的依賴可能比你的構(gòu)建更頻繁的改動(dòng)，那么將這兩個(gè)分隔是一個(gè)好主意，可以獨(dú)立出兩個(gè)概念：描述如何構(gòu)建和描述你的項(xiàng)目依賴。
* 發(fā)布的可能性
如果你描述一個(gè)自身可以被復(fù)用的模塊的依賴，你希望將它發(fā)布到倉庫。在這種情況下只有你有單獨(dú)的ivy文件發(fā)布才有可能。
* 更靈活
內(nèi)聯(lián)依賴僅僅能用于表達(dá)一個(gè)依賴并且只能一個(gè)。ivy文件可以用于表達(dá)更復(fù)雜的依賴。
另一方面，以下情況使用內(nèi)聯(lián)依賴非常有用：
* 你希望在你的ant構(gòu)建中使用定制任務(wù)
沒有ivy的情況下，通常或者是復(fù)制定制任務(wù)的jar到ant的lib目錄下，這需要維護(hù)你的工作站安裝，或用恰當(dāng)?shù)腸lasspath通過手工復(fù)制或者下載任務(wù)定義(taskdef)，這個(gè)更多。但是如果你有多個(gè)定制任務(wù)，或者如果他們有自己的依賴，這將變得非常麻煩。通過內(nèi)聯(lián)依賴來使用ivy是解決這個(gè)問題的一種優(yōu)雅的方式。
* 你希望容易部署應(yīng)用
如果你已經(jīng)構(gòu)建了你的應(yīng)用而它的模塊使用ivy，那么用你的ivy倉庫來下載你的應(yīng)用和它所有的依賴到本地文件系統(tǒng)來準(zhǔn)備執(zhí)行是非常容易的。如果你同時(shí)將你的配置文件作為制品放置在你的倉庫(也行打包為zip文件)，整個(gè)安裝過程可以依賴ivy，簡(jiǎn)化你的倉庫中可以得到的應(yīng)用的任意版本的自動(dòng)安裝。
7) 雇用專家
在軟件開發(fā)時(shí)間中構(gòu)建和依賴管理通常被是 。我們經(jīng)常看到開發(fā)人員在他們有時(shí)間的時(shí)候?qū)崿F(xiàn)構(gòu)建管理。即使這種方式看上去短期內(nèi)可以節(jié)約時(shí)間和錢，長(zhǎng)期看它通常轉(zhuǎn)為一個(gè)非常壞的選擇。構(gòu)建軟件不是一個(gè)簡(jiǎn)單的任務(wù)，當(dāng)你想保證自動(dòng)化，被測(cè)試過，完全可重現(xiàn)的構(gòu)建，發(fā)布和安裝。另一方面，一旦一個(gè)好的可以滿足你非常特殊的構(gòu)建系統(tǒng)被安裝好，它可以只依賴很少的對(duì)此有良好理解的人，就可以做到持續(xù)的質(zhì)量保證。
因此雇用一個(gè)構(gòu)建和依賴的專家來分析和改進(jìn)你的構(gòu)建和發(fā)布系統(tǒng)在大多數(shù)時(shí)間是一個(gè)非常好的選擇。
8) 反饋
這些最佳實(shí)踐反映的是我們自己的經(jīng)驗(yàn)，但是我們不會(huì)假裝我們掌握了依賴管理或者甚至是ivy使用的唯一真理。
因此請(qǐng)不要客氣地在這個(gè)頁面上面評(píng)論來增加你自己的經(jīng)驗(yàn)反饋，建議或者主張。