Тенденція «розвиваючої» галузі відходить

82

Останнім часом я щось помічав, дивлячись на якісь популярні проекти на GitHub, що немає developфілії. А насправді посібник GitHub Flow також не згадує про це. З мого розуміння, masterзавжди має бути повністю стабільним і відображати виробництво. Якщо розробники працюють над функціональними гілками, а потім об'єднують їх у ті, masterколи вони закінчені, це означає, що настає певний період часу, коли функції / виправлення об’єднуються, masterа masterгілка насправді новіша, ніж виробнича.

Чи не було б більше сенсу команда створювати функції / виправляти гілки develop, зливатися назад у це, і тоді, коли наступна версія буде повністю готова до випуску, developоб'єднується в masterі створюється тег? Уявіть, якби люди злилися прямо master, і повідомляється про помилку у виробництві, яку важко виправити, оскільки masterбаза коду філії значно змінилася. Тоді розробники повинні просто сказати користувачеві зачекати до наступного випуску, щоб побачити проблему.

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

git github

— ffxsam
джерело

11

Існує багато можливих робочих процесів, які дозволяє git. Не слід очікувати, що gitflow або github flow будуть використовуватися для всіх проектів.

Дуже цікаве запитання. Я працював роки з nvie.com/posts/a-successful-git-branching-model, і я повинен сказати, що мені це подобається. Що мені найбільше подобається в тому, що а) master - це те, що є у виробництві, і це стосується також версій, і b) існує чітка різниця між виправленням та функцією, вони ініціюються та об'єднуються відповідно до master та розвиваються. Однак після цього обговорення у мене починають виникати сумніви, чи це надмірно ускладнення речей. Будь-які думки з цього приводу?

— Аспасія

1

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

— Джим V

52

Воно походить від CI мислення , де є інтеграція кілька разів в день.

Є плюси і мінуси обох.

У нашій команді ми покинули галузь розвитку, оскільки вважали, що це не дає додаткової вигоди, а лише декілька недоліків. Ми настроїли наше програмне забезпечення CI (Teamcity) для компенсації недоліків:

Увімкнути розгортання конкретного комітету. Іншими словами: ми не розгортаємо відділення. Ми розгортаємо коміт.
Ми можемо розгорнути майстер або гілки, починаючи з виправлення / префіксу.

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

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

— Есбен Сков Педерсен
джерело

10

Пропрацювавши з розвитковою галуззю рік-два, просто щоб вона час від часу об'єднувалась у майстра, я можу просто сказати: амінь, відмовляйся від цього:]

— stijn

Цікаво. Отже, я припускаю, що, наприклад, випускаєте версію 1.3, ви помічаєте певну комісію master, тож якщо помилка виникає пізніше, masterперебуваючи в стані потоку, ви можете легко відключити виправлення з тега 1.3?

— ffxsam

5

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

— axl

1

@ffxsam нам навіть не потрібно тегування, оскільки ми відстежуємо, який ідентифікатор git зараз розгорнуто. Це реєструється як в TeamCity, так і розгалужується на розгорнуті dll та на порталі керування Azur. Таким чином, ми не відчували потреби в подальшому тегуванні, крім автоматичного тегування, здійсненого TeamCity. Якщо ви відчуваєте, що тег підходить, ви працюєте надто краще, це також добре вирішить. Але так, в принципі від'єднуються безпосередньо від поточно розгорнутої зміни, щоб зробити гілку виправлення.

— Есбен Сков Педерсен

25

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

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

У такому випадку може бути більше сенсу ізолювати "кандидата на звільнення" у немайстерній галузі (наприклад, "розвивати"). Це дозволяє вашій команді, яка виконує ці тести, мати відділення для об'єднання функцій.

Webapps або інше легко оновлене програмне забезпечення не мають цього обмеження.

Однак зауважте, що:

Багато (більшість?) Проектів на Github не мають такого роду обмеження
Основний «господар» виконує ту саму мету
Робочий процес "зробити PR проти майстра" набагато універсальніший, ніж "зробити PR проти гілки, яку ви не знаєте одразу на цьому репо"

— Ендерленд
джерело

18

Є дві філософії, які я бачив у проектах, і я вважаю, що вибір є лише питанням смаку:

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

Обидва є загальними підходами і мають свої плюси і мінуси.

— Ларрі Гріц
джерело

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

— Джонні

Саме так. Що повинен зробити «майстер» - це здебільшого семантика. Принципова справа - це уникати необхідності утримувати кілька вічно живих гілок двосторонньо синхронізовано, якщо у вас немає справді вагомих причин для цього. Гілка 'master' у Git Flow - це лише відстала репліка "розвиватися", тому вона насправді не рахується. Антидіаграма дозволяє головній гілці розробки проводити зміни, які ніколи не переходять у випуск, що є шокуючою поширеною практикою, яку я бачив. Обидві вищевказані моделі запобігають цьому, саме тому вони працюють.

— Джон Мікелау

7

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

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

Більшу частину часу у наших веб-додатках майстер змінився з моменту останнього випуску, але не дуже суттєво, тому ми можемо просто зробити новий реліз від master, який має виправлення. Це допомагає робити дуже часті випуски в будь-якому випадку.

— РемкоГерліх
джерело

5

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

...

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

Це не Github Flow.

Це процес розгортання / злиття Github Flow відповідно до вашого посилання:

Розгортання

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

Злиття

Тепер, коли ваші зміни були підтверджені у виробництві, настав час об’єднати ваш код у головну гілку.

(Наголос мій)

Іншими словами, masterніколи не випередить виробництво. Так само masterзавжди буде у стабільному, звільненому стані (окрім нерозкритих помилок), оскільки все перевіряється, тестується та передається у виробництво до об'єднання master.

— 8bittree
джерело

Приємно! Це має чуйний інтуїтивний сенс - masterце завжди ваша позиція відкату, якщо функціональна галузь, яку ви запускаєте у виробництво, не вдається. Якщо цього не відбувається, він об'єднується masterі стає новим резервним. Мені це подобається.

— Білл Хорват

1

Я бачу проблему в тому, що розгортання / злиття потоку Git / Hub передбачає, що одна особливість розробляється / тестується / об'єднується / розгортається одночасно - і часто, на мій досвід, це не так. Якщо ми об’єднали функцію за один раз, є більший шанс виникнути проблеми з регресією - лише після того, як функції об’єднаються в майстер і, можливо, у виробництво.

Потрібен спосіб перевірити кілька функцій, об'єднати кілька функцій і розгорнути одне і те ж. Я використовував «гілку зв’язку» (гілку, створену з майстра з гілками тестових готових функцій, об'єднаних у неї), яка розгортається в qa / uat. Виправлення під час uat трапляються лише на гілці функцій, і вони знову об'єднуються у гілку зв’язку. Після того, як підрозділ гілки пакета буде затверджений, лише ті затверджені функції в комплекті отримують запит на виведення, і цикл є безперервним.

Я використовую це з Gitflow, але розмірковую, щоб використовувати його для потоку GitHub. Багато характеристик QA / UAT, що виникають за один раз, видаються важливими. Інша проблема потоку GitHub - це те, що він передбачає всіх розробників сер, і це не завжди так.

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

Інша проблема - процес запиту на витяг відбувається в кінці перед об'єднанням у головний; однак, іноді потрібно перевірити код перед тестуванням ділової якості - значить, задовго до злиття

— Девід Летті
джерело