Як перейти від складної розгалуженої реальності до одногалузевої моделі?

У великих організаціях використання методології водоспаду, як правило, призводить до дуже складних гіллястих структур (ака гілки спагетті ).

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

Оновлення:

Для уточнення, питання стосується самої міграції / переходу , а не про методології до та після, які є досить чіткими.

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

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

У цій установці я також припускаю, що ці гілки створюються відповідно до плану водоспаду, який намагається мінімізувати конфлікти. Це означає, що метою розробки є виробництво декількох різних продуктів. Використовуючи модель розвитку однієї галузі, важливо також працювати над одним продуктом. Якщо декілька продуктів одночасно розробляються в моделі розробки з однією галуззю, вона ефективно "склеює" версії цих тез, так що ми могли б мати у версії a сховища здоровий продукт X та баггітний продукт Y , тоді як у версії b продукт X має регресію та Y виправлення помилок, але у нас немає версії, де і X, і XY здорові. Така ситуація змусить нас розглядати X і Y як розроблені у різних сховищах, що є натяком на те, що вони повинні бути.

Тому на перших кроках слід виконати розділення сховища :

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

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

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

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

4. Ввести методи програмування, що допомагають розвивати недовговічні галузі. Галузі, які є короткочасними, є вирішальним аспектом усіх методів одно галузей. Одна з їх цілей - скоротити час, витрачений на злиття та налагодження довгоживучих гілок. Популярна методика - це введення "функціональних прапорів", коли "фабрика" використовує прапор конфігурації або для створення історичної версії об'єкта, або нової, спочатку частково розробленої, версії цього об'єкта.

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

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

Коли ви переходите з чогось іншого на щось інше, вам потрібно визначити лише дві речі:

1. Яка ваша мета
2. Як дістатися (план міграції)

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

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

Наприклад, ваша мета повинна бути визначена так само чітко, як Вінсент Дріссен визначив свою "успішну модель розгалуження Гіта" . Якщо ви подивитеся на цю модель, вона дуже точна: вона говорить про те, де повинен бути стабільний код, і де слід розробити нестабільні функції. Він також говорить про те, як - і коли - розгалужувати, оновлювати та об'єднувати назад. Ви знаєте, для чого кожна галузь, і що з ними робити. Ми використовуємо варіацію того, що висунув Вінсент, і наша варіація визначена у нашій вікі.

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

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

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

DevOps - це все про спілкування, відкритість та ефективність. Ці поняття потрібно пам’ятати та повідомляти протягом усього процесу.

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

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

Перетворити багаторозгалужене сховище гідри в єдину розгалужену модель насправді дуже просто.

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

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

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

1. Створіть копію вашого головного / магістрального відділення та зателефонуйте temp_master
2. Знайдіть гілку з найбільшою відмінністю від майстра / стовбура.
3. Визначте, чи потрібно гілку зберігати, архівувати чи видаляти.
   1. Якщо це потрібно зберегти, перейдіть до кроку 4.
   2. Якщо її потрібно видалити або заархівувати, видаліть і заархівуйте її, а потім поверніться до кроку 2.
4. Повторіть крок 2, щоб знайти наступну гілку з найменшим розбіжністю.
5. Об’єднайте дві гілки, знайдені на кроці 2 та 3, вирішуючи всі конфлікти.
6. Об’єднайте ці дві гілки у свою temp_masterгілку.
7. Перевірте код у коді temp_master, щоб побачити, чи він компілює та будує та запускає будь-які інші автоматизовані тести, які ви маєте на розум.
   1. Якщо якісь тести не вдалися, поверніться, з’ясуйте, чому, і виправте їх, і повторіть процес.
   2. Якщо тести все-таки не спрацьовують, виберіть дві різні галузі для роботи.
8. Повторіть кроки 2 - 7, поки у вас є лише дві гілки, ваш господар / стовбур і temp_master.
9. Нарешті, об'єднайтеся temp_masterв головний / стовбуровий і створіть свою нову модель з однією гілкою.

Для великих організацій з типовою 4 тижні Спринту цикл Гіт-Flow кращий підхід , тому що Ви отримуєте перевагу Feature філія Майстри виробництва готової галузі завжди розгортається Крім того , майстер філія залишається чистим від небажаних фіксацій на наступних два здійснює цикл (від функції до Developі Developгілкам освоїти).

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