стратегії пакетів та версій у середовищі з декількома сховищами

Ми невелика фірма з кількома командами, які керують власними сховищами git. Це веб-платформа, і артефакти кожної команди розгортаються в кінці дня для проведення нічних тестів. Ми намагаємось формалізувати процес навколо версій та упаковки.

Кожна команда має головну галузь, де вони щодня розробляють. Члени кожної команди із забезпечення якості хочуть, щоб артефакти від змін їх команди були розміщені в тестовому стані, де всі компоненти поєднуються шеф-кухарем. Артефакти - це тарботи, але я хотів би перетворити їх у RPM, щоб ми могли правильно думати і міркувати про версії.

Процес випуску передбачає відрізання гілки випуску з гілки розвитку (майстер у більшості випадків) кожного сховища git. Потім це надається гарантії якості, яка виконує тести та виходить на набір артефактів.

Наприклад, це типовий сховище git із пов'язаними з ним гілками випуску:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

Я застряг, намагаючись розробити схему виконання версій пакетів, що надходять із галузей розвитку. Ми не хочемо надмірно тегувати головну гілку кожного репо і обмежуємо теги випускати лише гілки. Але ми повинні мати можливість запитувати розгорнуті пакети в тестових машинах, використовуючи стандартну семантику yum / rpm. Як виглядатимуть версії розробок, коли в головній гілці немає тегів? Я розумію, що git describeможе дати мені корисне представлення версії збірки, але це добре працює, коли різні точки випуску на гілці позначені тегами.

EDIT1: У відповідь на відповідь @ Urban48

Я подумав, що варто трохи більше пояснити наш процес випуску. Для цілей цієї дискусії припустимо, що masterу всіх сховищах є відділення . masterГалузь вважається гілкою розробки та розгортанням на автоматизований CI-CD включаючи середовище QA. Ось тут виконується підмножина нічних тестів, щоб забезпечити стабільність господаря. Ми розглядаємо цю роботу із робочими місцями, перш ніж вирізати гілку випуску. Наші відділення випуску нетривалі. Скажімо, після вирізання гілки випуску (від стабільного майстра) запускається повна регресія, виробляються виправлення та розгортаються до виробництва. Це займе близько тижня. Ми випускаємо майже кожні два тижні до виробництва.

Наші гілки функцій завжди вирізані з головного і піддаються певній кількості тестувань розробника, перш ніж об'єднатися з мастером, на якому вони проходять перевірку стабільності CI-CD.

Виправлення виробляються на гілках виправлень (вирізані з гілок випуску) та розгортаються з мінімальним тестуванням впливу на виробництво.

Наша стратегія версій для випусків та виправлень гілок слідує semver. Відпустити гілки під час циклу QA через версії , як v2.0.0-rc1, v2.0.0-rc2і , нарешті , після QA знака-офф стала v2.0.0.

Іноді ми робимо пунктирні випуски для невеликих функцій, які об'єднуються, щоб випустити гілки (а потім і освоїти), де стають версії v2.1.0. І виправлення приймають v2.1.1зразок.

Питання, однак, не полягає у версії цих гілок. Я вважаю за краще не змінювати цю схему версій взагалі. Єдина зміна стосується галузі розвитку, тобто. майстер. Як я можу надійно вказати в середовищі CI-CD, яка версія існує з попереднього випуску у виробництво. Це в ідеалі можна зробити за допомогою інтелектуального тегу на git, але бажано те, що не надмірно тегує головну гілку.

Хм, добре, у мене є приклад .net, який може бути агностиком.

Я просто короткий підсумок.

• git repo на компонент із стратегією розгалуження gitflow

• всі зобов’язання розробити тригер для створення міста

• teamcity build виправляє версію з основним мінором + числом збірки в AssemblyInfo.cs, тобто 1.1.hotfix.build

• teamcity запускає упаковку цілей, використовуючи той самий номер версії для логічно опублікованих бібліотек

• восьминога розгортає готову збірку до qa для ручного тестування (якщо припустимо пройти всі тести)

• якщо все добре, вручну розгорніть версію до виробництва через восьминога.

Тепер це означає, що ви отримуєте багато плаваючих пакетів. Ми експериментували з використанням прапора -prerelease, але це вимагало подальшого ручного переходу пакету від попереднього випуску до «нормального» кроку та вимоги відновити компоненти, які залежали від них.

Ключовим моментом є створення кожної збірки однозначно за допомогою центрального процесу.

Тоді ви опинилися в "hmm, які версії я хочу", а не "omg, яку версію я отримав ??"

Редагувати: повторні коментарі.

Просто щоб підкреслити цю ключову річ насправді. Вирішіть, яка галузь становить завершене програмне забезпечення, а версія ВСЕ зобов'язується їй. розгортати тільки програмне забезпечення з цією галуззю.

Я вважаю, що вам потрібно вирішити свою стратегію розгалуження.

• не мають версій (або будь-яких розробників) гілок.
• зробити майстер версій
• використовувати тільки пакети від головного

Дозвольте запропонувати альтернативний робочий процес, який може вирішити вашу проблему з версією або просто допоможе вам придумати більше шляхів до вирішення.

Спочатку трохи філософії ..
(Я висловлюю кілька припущень щодо вашого робочого процесу, будь ласка, виправте мене, якщо я помиляюся)

1. Тести проводяться заднім числом :

   Відділіться, maserщоб представити гілку, а потім перетворіть її в артефакт для тестування з допомогою QA.
   проблема полягає в тому, що якщо тести не вдасться, то вони masterможуть бути порушені!

   побічні ефекти:

   • Це змушує розробників не довіряти master

   • Оскільки ви відгалужуєтесь від майстра, щоб випустити гілки, що буде, якщо попередній випуск буде порушений? він зупиняє вашу інтеграцію нової функції, поки знову не буде встановлено майстер.

   • коли помилка виправлена ​​у гілці випуску, злиття назад masterможе створити конфлікти злиття. (і нам не подобаються конфлікти)

2. невеликий код злиття та виправлення :

   Важко відслідковувати весь код, який об’єднаний master, як невеликі виправлення чи зміни, які не є частиною певної функції.

   побічні ефекти:

   • розробник не впевнений, чи повинен він замінити цей невеликий виправлення зараз чи пізніше.

   • Чи варто мені версію цього нового невеликого виправлення?

   • У будь-який момент часу не зрозуміло, який стан masterфілії, і який код там плаває

   • щось зламало збірку, що не є частиною нової функції. і його справді важко відстежити, звідки він прийшов

Моя ідея для роботи git - така:

відділення masterдля розробки нових функцій, як ви вже робите. але тепер замість того, щоб звільнитись із цієї новоствореної гілки, майте цю функцію вишневого та об’єднаного у releaseгілку.

Тепер у вас є кращий контроль над тим, що відбувається в певному випуску.
Тепер його справді просто ізолювати розроблювальні версії та стабільні версії.

Ви можете продовжувати створювати артефакти з цих галузей для забезпечення якості.
Якщо все в порядку, об'єднайте цю функцію назад masterі виберіть цю функцію / виправлення помилок / гаряче виправлення у гілці випуску.

версійності
Функція гілок версії можуть використовувати деякі назви конвенції , як1.2.3-rc.12345

Версії у releaseгілці використовуватимуть лише 1.2.3 ( 1.2.3> 1.2.3-rc.12345і ще одна менша річ, яку потрібно турбувати)

Цей робочий процес вирішує вказані вище проблеми тощо.
Він також пропонує стратегію розумної версії, і більшість цього циклу випуску може бути автоматизована.

Я сподіваюся, що це допоможе тобі в чомусь, я з радістю обговорюю будь-які крайні випадки, які ти можеш придумати.

ps:
Прошу вибачення за свою англійську, це не моя основна мова.

Ваш процес здається дуже складним, а отримання невеликої кількості тегів видається неминучим.

На думку приходять дві ідеї:

1. Ви розглядаєте гілку "майстер" як те, що ми зазвичай маємо в гілці "розвивати". Це сильно забруднює гілку повідомлень.

2. Коли QA закінчить свою роботу, ви можете мати сервер build / CI для створення звіту (наприклад, текстовий файл) з тегами всіх використовуваних репостів. Тепер у вас буде файл з версіями, який можна опублікувати в репо. Потім ви позначаєте гілку лише версією випуску, і якщо ви хочете перевірити версії окремих компонентів, ви можете перевірити звіт.