Маєш виробничу галузь або використовуєш майстра?

Я працюю над невеликою командою з іншими віддаленими розробниками над Railsдодатком. Ми починаємо змінювати наш gitробочий процес. Ми думали про розгалужену структуру, як нижче:

(dev) -> (qa) -> (stag) -> (master)

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

(master) -> (qa) -> (stag) -> (prod)

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

Які б були недоліки використання структури розгалуження, коли майстер активно використовується для розробки, а окрема гілка prod - це те, що ви використовуєте для розгортання?

У цього підходу немає ні переваг, ні недоліків. Причина, по якій я кажу, це проста: для Git це не має ніякого значення, якщо ви розвиваєтеся з майстра або звільняєтесь від майстра. Вам навіть не потрібно випускати гілки; ви можете позначити довільну комісію та замість цього звільнити.

Реальна біда ось один з процесу і процедури. Більш старші розробники, які занепокоєні тим, що робити це одним способом, заплутають новіші диски, повинні бути готові вкласти час, щоб пояснити, що таке модель випуску, і чому це саме так.

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

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

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

З документації / книги Git - Гіт розгалуження

«Головний» відділення в Git - це не особлива галузь. Це точно як і будь-яка інша галузь. Єдиною причиною майже кожного сховища є те, що команда git init створює її за замовчуванням, і більшість людей не намагаються її змінити.

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

(dev) -> (qa) -> (stag) -> (prod)

Ось як ви змінюєте ім'я ведучої гілки .

Я НЕ кажу, що ви повинні змінити назву masterфілії. Але якщо у вас є бажаний робочий процес, і це допомагає змінити назву masterгілки, зробіть це будь-якими способами :-)

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

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

Ось чому ми налаштовуємо наше репортаж Git (ми використовуємо Gitlab), що лише певні люди можуть об'єднати запити на витягування, і кожен розробник отримує власну приватну вилку головного репо.

Це вирішує дві проблеми:

1. Нові розробники не можуть змінити неправильну гілку (оскільки вони не можуть підштовхнути свою роботу безпосередньо до основного репо). Вони можуть натиснути masterна власне репо, але це буде виправлено, коли надійде запит на витяг.

2. Конвенції про кодекси швидко поширюються по команді, оскільки кожне зобов'язання перевіряється принаймні іншою людиною, яка передає їх погляд та знання.

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

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

Вони вважають, що (master) -> (release), можливо, організація 1,2 проміжних кроків може бути корисною.

Тоді з'являється більш "класична" фракція, яка має процес, керований плануванням та плановими кроками інтеграції в бік етапів, де випуск "одиниці роботи" - це запланована діяльність з такими вимогами, як "випуск тільки тоді, коли він (блок) перевірений" і повинен підходити до наступної запланованої віхи ". Там планування включає в себе версію "одиниць роботи", і зазвичай вони розглядаються, щоб визначити, як повинен виглядати наступний плановий випуск продукту з точки зору функцій та виправлень. Для планування вони хочуть знати, що те, що розробник випускає, є «належним» та свідомим актом вчинення одиниці роботи.

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

Отже, "класичним" робочим процесом було б: (dev) -> (unit) -> (інтеграція) -> (test / qa) -> (виробництво).

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

Зі сторони, також можна змішати ці два основні підходи у підходящий спосіб.

З мого досвіду (який здебільшого стосувався сфери використання «класичного» підходу), «класичний» підхід працював гідно в проектах приблизно від 4-50 осіб у команді.