Зараз моя команда використовує досить простий процес розгалуження / розгортання, який виглядає приблизно так:
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Builds: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Branches: │ master │ │ qa │ │ prod │
└────────┘ └────┘ └──────┘
Кожне середовище має власну гілку (ми використовуємо git ) та власну збірку, яка використовує цю гілку. Коли ми хочемо просуватись із одного середовища в інше, наприклад, від DEV до QA, ми об'єднуємо masterгілку в qaта починаємо нову збірку QA (яка автоматично розгортається у середовищі QA).
Ми розглядаємо можливість перейти до нового процесу, який би усунув необхідність створення спеціалізованої гілки та побудови для кожного середовища. Натомість, складання одного випуску створило б "пакет розгортання", який можна було б потім розгорнути в будь-яке середовище. Ми уявляємо, що типовий робочий процес буде виглядати приблизно так:
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ ──► │ QA │ ──► │ PROD │
└────────┘ └────┘ └──────┘
▲
\
┌───────────────┐
Builds: │ release build │
└───────────────┘
▲
│
┌────────┐ ┌─────────┐
Branches: │ master │ │ release │
└────────┘ └─────────┘
Просування з одного середовища в інше більше не оброблятиметься в контролі джерел; швидше, ми б просто взяти вже вбудовані бінарні файли ("пакет розгортання") і перенести це на нове середовище.
Ця нова система дозволила б нам розгорнути будь-яку збірку в будь-яке середовище, що має ряд переваг. Наприклад, тривіально тестувати виправлення помилок PROD у DEV та QA. Наша нинішня система не пропонує простий спосіб зробити це без відкочування гілки, чого ми, очевидно, хотіли б уникнути.
Найбільшим недоліком цієї нової системи є те, що у нас більше немає автоматичного способу відстеження того, який код знаходиться в якому середовищі. Якщо нам потрібно виправити PROD, у нас більше немає спеціалізованої гілки синхронізації з поточною кодовою базою даних. Те ж саме стосується і QA - якщо ми хочемо швидко змінити QA, не драгуючи незавершені роботи master, ми більше не матимемо відділення, яке відображає поточний стан середовища QA.
Як ми можемо відслідковувати, який код є у кожному середовищі?
Деякі варіанти, які ми розглядаємо:
- використання тегів git для відстеження того, яка фіксація знаходиться в якому середовищі
- вбудовування git-комітету, використовуваного build, у кожен пакет розгортання