Мы разрабатываем административную систему SOA, состоящую из отдельных, но схематически связанных компонентов системы:
- База данных (схема)
- UI
- Веб-сервисы
Схема является общим знаменателем. Пользовательский интерфейс и различные разложенные веб-сервисы взаимодействуют на нем. В хранимых процедурах схемы также присутствует значительное количество бизнес-логики.
Циклы выпуска устанавливаются в согласованные календарные дни с учетом требований бизнеса и финансирования. Новая версия будет содержать предопределенную серию изменений, принятых клиентом. Каждому выпуску присваивается порядковый номер версии в стиле 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. Было бы удобно безоговорочно синхронизировать номера версий компонента с номером версии выпуска. С другой стороны, повторное развертывание компонента в производстве всегда нежелательно. Какова наилучшая стратегия для управления и документирования версий с учетом этих предпосылок?