Ivy 參考文檔：最佳實踐（下）

5. 處理整合版本

團隊或多模組開發時，需依賴尚未完成的模組版本，稱為整合版本，主要目標是與其他模組整合以建構或測試應用/框架。若遵循持續整合規範，這些版本可由 CI 伺服器頻繁產生。

兩種處理方式

1. 命名慣例（特殊後綴）：每次發布新整合版本使用相同名稱（如 Maven 的 1.0-SNAPSHOT）。依賴管理器識別此版本為特殊且不斷變更，不信任本地快取，檢查倉庫資料是否變更。Ivy 透過 dependency 的 changing 屬性或 changing 模式支援。
2. 自動建立新版本：使用建構號或時間戳發布新版本名稱。可用 Ivy 的多種方式進行「明確版本約束」，通常選擇最新版（用 'latest.integration' 作為版本約束）。

建議與考量

通常推薦第二種方式，因為每次發布用新版本名稱更符合版本身份規範，且能使所有建構可重現（甚至整合版本）。在建構系統中引入機制將整合建構提升至更穩定狀態（如里程碑或發布）。

情境：客戶週一要求最新版本測試/演示。若有良好 CI 與變更追蹤，可快速滿足。但若最新版剛好破壞功能，可能需交付幾天前的「穩定」整合建構。若客戶稍後要求該演示版本的修復，若倉庫有建構版本提升功能，將易於處理：客戶要求時不僅交付整合建構，也提升至里程碑狀態，表示長期追蹤並可建立分支。

Ivy 本身不負責可重現建構（它是依賴管理器非建構工具），但若用不同名稱發布唯一版本，並在發布過程使用版本約束替換等特性，將非常有幫助。缺點是會產生大量中間版本，需在倉庫執行清理腳本。

6. 是否將依賴內聯

Ivy 1.4 允許無 ivy 檔案解析依賴，稱為「內聯」。

獨立 ivy 檔案優點

• 分離修訂週期：依賴可能比建構更頻繁變更，分離可獨立管理「如何建構」與「專案依賴」
• 發布可能性：模組可被重用時，需發布到倉庫，只有獨立 ivy 檔案才可能
• 更靈活：內聯僅能表達單一依賴，ivy 檔案可表達複雜依賴

內聯適用情況

• Ant 建構中使用自訂任務：無 Ivy 時需複製 jar 到 ant lib 或手動管理 classpath。多自訂任務或有自身依賴時極麻煩。內聯依賴優雅解決此問題
• 簡化應用部署：模組使用 Ivy 建構後，用 Ivy 倉庫下載應用及所有依賴到本地檔案系統準備執行非常容易。若同時將配置檔作為制品放入倉庫，整個安裝過程可依賴 Ivy，簡化任意版本自動安裝

7. 僱用專家

建構與依賴管理常被忽視。開發人員有空時才處理建構管理，短期或省時省錢，長期通常是極差選擇。建構軟體非簡單任務，尤其要保證自動化、測試過、完全可重現的建構、發布和安裝。一旦良好的建構系統安裝好，僅需極少懂行的人即可持續品質保證。因此僱用建構與依賴專家分析改進系統在大多數情況是極佳選擇。

8. 回饋

最佳實踐反映自身經驗，非唯一真理。請在頁面評論增加經驗回饋、建議或主張。