The advantages and disadvantages of each
标签: 云计算
Chris Phillips
发布: 2018-05-22
要管理和维护任何运行时系统，需要一个全面的版本控制策略。没有明确的策略，如何知道哪些服务和 API 已部署，以及要使用哪个版本？本文将重点介绍帮助您管理 API、服务接口和实现的 4 种策略。还将展示每种策略的优缺点。
在定义版本控制策略时，需要关注以下两个关键区域的需求：
- 服务或 API 接口： 当您更改接口时，您的用户需要更改他们的代码。因此，您必须能够跟踪并告知 API 和服务用户，他们必须更改其 API 或服务接口的版本。
- 服务或 API 实现： 您每次更改实现时您的用户都应得知，但可能无需更改其代码。但是，您的运营团队需要跟踪某个服务或 API 采用了何种实现。
版本控制策略通常有一个明确的系统来将新版本部署到生产中，但很少（甚至没有）涉及如何退役一个服务。考虑一个运行了多年的平台的示例。该平台可能有 30 个服务，每个服务有 20 个不同版本。如果没有退役服务的计划，单单 1 个服务，平台最终可能会有该服务的总计 600 个实例。
对于一个 API 或服务，应在生产中最多保留 3 个最详细的版本……
通过将合理的版本控制策略与管理系统（比如 IBM® API Connect）相结合，可以减少服务数量。对于某个 API 或服务的更高级版本的每个组合，应 在生产中 最多保留 3 个最详细的版本。例如，如果版本控制模式为 vX.Y，每个 X 版本仅能在生产中拥有 3 个 Y 值。对于模式 vX.X.Y，每个 X.X 版本仅能在生产中拥有 3 个 Y 值。
每个级别上的 3 个生产版本都与以下状态相关：
- Live： 新用户必须使用此版本。
- Superseded： 新用户在情有可原的情况下可以订阅此版本。
- Deprecated： 新用户不得使用此版本。
下表给出了一个列表示例，其中包含采用一点策略部署的版本的最大数量。
版本****状态V1.4LiveV1.5SupersededV1.6DeprecatedV2.3LiveV2.4SupersededV2.5DeprecatedV3.1LiveV3.2SupersededV3.3Deprecated
在这个示例中，最大部署数量为 3 的 N 次方，N 等于点数加 1。
版本系统****最大实例数量VX.Y9VX.X.Y27VX.X.X.Y81
当一个新版本准备好发布时，该版本仅在满足以下要求后生效。
- 现有的 Deprecated 版本已退役。
- Superseded 版本变成 Deprecated 。
- Live 版本变成 Superseded 。
通过使用出色的 API 管理工具，比如 API Connect，可以快速确定哪些用户在使用每个版本。在服务变为 Deprecated 或 Superseded 时，必须通知用户。如果用户没有迁移到最新版本，他们必须理解他们的应用程序将会面临破坏风险。
在以下策略中，每个版本在源代码存储库中都有自己的分支。这些分支称为 代码流 。
一点策略表示为主要版本后加一个点，然后是次要版本。此策略的语法如下：
<主要版本>.<次要版本>
级别与一个早期版本兼容该实现或接口的新版本描述主要否是接口更改与一个早期版本不兼容次要是是非破坏性接口或实现更改
此策略有以下特征：
- 非常简单。
- 紧密结合了接口与实现。
- 有两个代码流需要您管理和支持。
- 可能部署了 9 个实例。
- 没有突出重大的重新设计。
- 不清楚某个次要更改何时会影响接口或实现更改。
两点策略表示为主要版本、一个点、次要版本、一个点、修复版本编号。此策略的语法如下：
<主要版本>.<次要版本>.<修复编号>
级别与一个早期版本兼容新实现版本新接口版本描述****主要否是是接口更改与一个早期版本不兼容次要是是是非破坏性接口更改修复是是否没有接口更改
此策略有以下特征：
- 在修复级别上，您可以更改服务的版本，而不更改接口的版本。实现的所有新部署都会让版本递增，即使接口未发生更改。
- 结合了接口和实现版本，而没有将它们紧紧捆绑在一起。
- 有 3 个代码流需要您管理和支持。
- 如果每个版本级别都部署了 3 个版本，可能部署了 27 个实例。
- 它没有突出重大重新设计是何时发生的，比如何时重新设计许多现有接口。是否需要大量返工并不明显。
三点策略类似于 IBM 产品版本中使用的 版本、发行版、修订和修复包 (VRMF) 策略 。此策略表示为发行版本、一个点、主要版本、一个点、次要版本、一个点，然后是修复版本。此策略的语法如下：
<发行版本>.<主要版本>.<次要版本>.<修复版本>
级别与一个早期版本兼容新实现版本新接口版本描述****发行版本否是是发行版的重大重新设计主要否是是接口更改与一个早期版本不兼容次要是是是非破坏性接口更改修复是是否没有接口更改
此策略有以下特征：
- 在版本间提供了更高的精确度。
- 可以更改服务的版本而不更改接口的版本，这意味着您不需要更新任何目录或开发人员门户。
- 可以结合接口和实现版本，而没有将它们紧紧捆绑在一起。
- 有 4 个代码流要管理和支持。
- 如果每个版本级别部署了 3 个版本，可能部署了 81 个实例。
- 突出了重大重新设计是何时发生的，比如何时重新设计许多现有接口。是否需要大量返工并不明显。
接口和实现独立进行版本控制。在这种策略中，接口和实现都遵循一点策略。但是，它们可以遵循更复杂的策略，比如两点或三点策略。
此策略有以下特征：
- 有两个代码存储库，每个存储库中都有两个流。
- 对用户隐藏了实现版本。
- 实现和接口完全分离。
- 开发人员和设计人员必须采用相同的策略，但无需采用相同的版本号变化规则。
- 开发人员和设计人员必须就接口和实现版本号如何变化的准则达成一致。例如，他们可以进行以下协商：实现必须始终拥有与它们的接口相同的主要版本号，但次要版本可以不同。
- 如果在每个版本级别上部署了 3 个版本，可能部署了 9 个接口实例和 9 个实现实例。
- 由于有两个不同的编号，所以跟踪变得更困难。
- 难以快速确定某个特定接口正在使用哪个实现。
下表比较了 4 种策略，以帮助您为您的服务和 API 做出最佳选择。
特征一点 V0.0两点 V0.0.0三点 V0.0.0.0解耦（一点） V0.0 + V0.0简单、清晰、明显是否否否将接口与实现结合紧密松散松散无要管理的流数量2342 + 2用户可以通过版本号获知对接口和实现的所有更改是是是否（仅限接口）允许自动迁移与早期版本兼容的更改是是是是突出显示了重大重新设计何时发生否否是否在以下情况下，一个服务在所有版本级别上部署在生产中的最大版本数量： 每个级别有 3 个实例。 与早期版本兼容的更改没有自动迁移。927819 + 9在以下情况下，一个服务在所有版本级别上部署在生产中的最大版本数量： 每个级别有 3 个实例。 与早期版本兼容的所有更改已自动迁移。3393 + 3
在本文中，您了解了版本控制的重要性和 4 种帮助您管理版本的策略。除了本文中介绍的策略外，还可以实施其他许多策略。请记住，没有哪个策略是完美的。