2009-01-29 52 views
4

我在我以前的工作中遇到過這個問題,現在再次出現在我現在的問題上,這意味着我要麼運氣非常差,要麼沒有意識到可以解決這個問題的一些工具或組織系統。管理不同組件版本之間的依賴關係的最佳方式是什麼?

在這兩種情況下,最終產品都由幾個獨立的組件組成,每個組件都通過與其鄰居之間商定的接口進行通信。問題是,隨着時間的推移,界面將發生變化,然後各個組件也必須更新,以便所有內容都可以繼續工作。

這本身並不是問題。問題在於,當試圖回溯到SCM歷史記錄時,這使得錯誤跟蹤非常困難,因爲在某些時候,您嘗試調試的組件將不再與系統的其他部分兼容,並且無法針對它們進行測試也沒有將它們回滾。

看看下面的例子:

  1. 說我們有一個客戶機/服務器產品,併爲簡單起見,無論是在完全工作狀態下開始了。我們將稱這些版本爲client-1.0和server-1.0。
  2. 經過一段時間後,對兩者都進行了錯誤修正和功能。現在我們處於client-1.7和server-1.2。
  3. 現在接口在服務器中發生變化,所以客戶端也必須更改:server-2.0和client-1.8。
  4. 現在,客戶端版本爲1.9,發現了一個錯誤,我們想要測試以前的版本以查看它停止在服務器上的工作。但是,如果我們回到1.8以上,那麼服務器也必須恢復。

我給出的示例場景非常簡化,但問題歸結爲:執行哪個版本的客戶端和服務器相互兼容的最佳方式是什麼?

我已經考慮通過文檔來做到這一點,但不可避免的是,人性會勝利,有人忘記更新他們或他們的其他組件。我也想過通過匹配版本來實現它(即,當服務器命中2.0時,客戶端也得到提升),但問題是客戶端可能有其他組件依賴關係,這與服務器無關,所以它沒有意義全面更新他們的版本。

要解決這個問題必須有一些解決方案。有沒有人對我的研究有任何建議或起點?

回答

1

你不得不安裝一個作爲歷史元標籤(標籤引用其他標籤)

這既可以做:

  • 通過你的供應鏈管理中的元數據(SVN比如做保留其元數據及其數據的歷史記錄)
  • 或通過外部數據庫註冊當前測試和驗證爲「一起工作」的所有標籤的列表(如果該列表已被歷史記錄)

該元標籤的歷史性確保您能夠恢復到之前連貫的一組標籤以調試系統。

無論您選擇哪種解決方案,不要忘了,一旦在生產環境中提供:

  • 你沒有你的供應鏈管理在生產環境中
  • 因此你必須依賴於一個文本文件,提醒你部署的確切標籤。

該文本文件應該當你建立(文件集,你會部署到生產)的交付包

1

你似乎沒有有問題管理依賴自動生成,你有問題迴歸。

接口負責依賴抽象,單元測試和夜間構建,負責變更控制。

如果您需要測試歷史版本,則需要能夠從源存儲庫中獲取該標籤的版本,並將其部署在複製但相當獨立的環境中。因此,這是一個在SCM中定義發佈標籤元數據並具有備用/專用硬件的問題。

1

我不知道你使用的是什麼語言平臺,例如Java,C等等。但是這裏有一些相關的信息讓我的生活在java中變得簡單。

有一個名爲Maven的構建工具,用於我的Java應用程序。 Maven有明確的依賴配置。例如

客戶1.0依賴於服務器1.0 - 當你將看到客戶端1.0的配置,你會發現它需要服務器1.0 客戶端1.7依賴於服務器1.2 客戶端1.8依賴於服務器2.0 客戶端1.9依賴於服務器2.0

您發佈的每個版本都將在您的Maven存儲庫中提供。如果我想測試client-1.7,我會簡單地從存儲庫和配置中獲取它,我知道它需要server-1.2,它也可以在存儲庫中使用。我將開始我的申請和測試。

1

使用RESTful界面。在真正的REST中,客戶端學習如何通過服務器返回的響應中的元數據進行導航。通過保持元數據靜態,舊客戶端可以導航較新的服務器版本。

相關問題