我们正在开发由不同但示意性耦合的系统组件组成的管理SOA系统:
模式是公分母。 UI和各种分解的Web服务在其上进行协作。模式存储过程中还存在大量的业务逻辑。
发布周期固定在商定的日历日中,该日历日由业务需求和资金决定。新版本将包含客户认可的预定批次的更改。每个发行版均以 major.minor.patch 的方式提供顺序的版本号。从某种意义上说,版本号是特定系统组件的实际版本号的抽象。考虑下面的图表,其中显示了一些发行版:
Version 8.2 changes:
----------------------
Schema: 8.0 → 8.2 (change)
UI: 8.1 → 8.1 (no change)
Web Service: 8.1 → 8.1 (no change)
Version 8.2.1 changes:
----------------------
Schema: 8.2 → 8.2 (no change)
UI: 8.1 → 8.2.1 (change)
Web Service: 8.1 → 8.1 (no change)
Version 8.3 changes:
----------------------
Schema: 8.2 → 8.3 (change)
UI: 8.2.1 → 8.3 (change)
Web Service: 8.1 → 8.1 (no change)
Version 8.4 changes:
----------------------
Schema: 8.3 → 8.3 (no change)
UI: 8.3 → 8.4 (change)
Web Service: 8.1 → 8.4 (change)
用外行的话来说,发行版可能影响任何数量的系统组件,但至少会影响其中的一个。这导致在版本控制下各个系统组件的版本号不同且不连续。要在各种环境中维护出色的安装及其版本表,需要付出巨大的努力。我们为当前和早期版本托管并行开发环境,以涵盖保修事务。这是简化的“环境表”的示例:
--------------------------------------------------------
| Version | Schema | UI | WS |
--------------------------------------------------------
| 8.4 | 8.3/build# | 8.4/build# | 8.4/build# |
--------------------------------------------------------
| 8.3 | 8.3/build# | 8.3/build# | 8.1/build# |
--------------------------------------------------------
| 8.2.1 | 8.2/build# | 8.2.1/build# | 8.1/build# |
--------------------------------------------------------
| 8.2 | 8.2/build# | 8.1/build# | 8.1/build# |
--------------------------------------------------------
在进行并行开发和执行合并时,很难对版本进行推理,因此是excel。无条件地将组件版本号与发行版本号同步会很方便。另一方面,总是不希望将组件重新部署到生产中。在这些前提下,管理和记录版本控制的最佳策略是什么?