如何進行 Stubs 版本控制？

版本控制到底意味著什麼？如果您指的是 API 版本，有幾種不同的方法

我們不試圖回答哪種方法更好的問題。您應該選擇最適合您的需求並能為您帶來商業價值的方法。

假設您確實對 API 進行了版本控制。在這種情況下，您應該為您支援的每個版本提供相應的契約。您可以為每個版本建立一個子資料夾，或者將其附加到契約名稱中——選擇最適合您的方法。

如果版本控制指的是包含 Stub 的 JAR 的版本，那麼主要有兩種方法。

假設您進行持續交付和部署，這意味著每次透過管道時都會生成一個新的 JAR 版本，並且該 JAR 可以隨時投入生產。例如，您的 JAR 版本可能看起來像下面這樣（因為它是在 2016 年 10 月 20 日 20:15:21 構建的）

在這種情況下，您生成的 Stub JAR 應該看起來像下面這樣

在這種情況下，在您的 application.yml 或 @AutoConfigureStubRunner 中引用 Stub 時，您應該提供 Stub 的最新版本。您可以透過傳遞 + 符號來實現。以下示例展示瞭如何操作

然而，如果版本控制是固定的（例如，1.0.4.RELEASE 或 2.1.1），您必須設定 JAR 版本的具體值。以下示例展示瞭如何為版本 2.1.1 執行此操作

您可以操作 classifier 以針對其他服務的當前開發版本 Stub 或已部署到生產環境的 Stub 執行測試。如果您修改構建過程，在達到生產部署階段時使用 prod-stubs classifier 部署 Stub，那麼您可以在一種情況下使用開發環境 Stub 執行測試，在另一種情況下使用生產環境 Stub 執行測試。

以下示例適用於使用開發版本 Stub 的測試

以下示例適用於使用生產版本 Stub 的測試

您也可以從部署管道透過屬性傳遞這些值。