Чи неправильно моя компанія, що об'єднує філії?

Нещодавно я натрапив на статтю MSDN про розгалуження та злиття та SCM: Branching and Merging Primer - Chris Birmele .

У статті вони говорять про те, що "велике злиття вибуху" є антипатерном:

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

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

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

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

Для нас не рідкість 10-20 активних гілок, які сидять в останній черзі на огляд, щоб їх об'єднати в стовбур.

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

У мене є декілька прямих питань:

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

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

Будь-яке інше розуміння цієї ситуації було б вдячне.

Деякі пропозиції:

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

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

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

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

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

• Для вашого поточного чисельності команди мати одного воротаря все ще може. Але якщо ваша команда зросте в чисельності, немає іншого шляху мати другого воротаря (або більше). Примітка. Я не пропоную дозволити всім злитися в багажник, але це не означає, що тільки ваш начальник здатний на це. Напевно, є один або два старших диявола, які також можуть бути кандидатами на виконання роботи воротаря. І навіть за розміром вашої команди, другий воротар може полегшити вашу команду частіше та раніше інтегруватися до багажника, або коли вашого боса немає в наявності.

Ми демонструємо той самий антидіапазон, який був описаний як "злиття великого удару"?

Звучить так.

Чи є деякі проблеми, які ми бачимо в результаті цього процесу злиття?

Безумовно

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

У моєї компанії кожен диявол має можливість зливатися. Ми призначаємо Запит на об'єднання іншому розробнику, проходимо цикл перегляду / відгуку / оновлення, поки обидві сторони не будуть задоволені. Потім рецензент об’єднує код.

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

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

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

Я погоджуюся з обом Док Браун, але я бачу ще одного антипатрійна:

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

У моїй скромниці є декілька управлінських моделей:

1. Він / вона є єдиною дросельною точкою, що обмежує швидкість команди. Ваш коефіцієнт шини - 1. Теорія обмежень говорить про те, що ви повинні докласти зусиль для вдосконалення найповільнішої частини ланцюга.
2. Ваш менеджер робить зворотний цикл зворотнього зв'язку і зменшує спритність вашої команди. Ви можете звільнити щотижня?
3. Складність злиття зростає експоненціально з кількістю коду. Краще зробити 10 злиття зі 100 рядками, ніж 1 з 1000 рядків. Це лише одна з причин, чому ви повинні робити це якомога швидше
4. Якщо ви виявите збій у багажнику, ви зробите це останнє вчасно. Яка з кількох галузей була проблематичною
5. Рішення повинні приймати ті, хто більше знає про них. Хто знає більше в цьому випадку? Б'юсь об заклад, що розробники, які зробили код.
6. Ви не можете виправити помилку у виробництві, якщо ваш менеджер є у свята.
7. Ви переробляєте роботу і кидаєте назад гілки. Це марна трата часу. Час, який він чекає, щоб досягти виробництва, також витрачається.

Рекомендації:

• Ваш менеджер повинен делегувати відповідальність команді. Потрібно показати, що колектив зрілий, професійний. Дайте зрозуміти, що вони можуть довіряти команді
• Запровадити деякий метод огляду. Можливо, вам знадобиться схвалення двох інших членів команди.
• Можливо, використання SVN робить його складніше. Спробуйте Git спробувати і побачити, чи допоможе вам. Навіть більше. Якщо ви використовуєте GitHub, ви можете використовувати механізм "Затягнути запит", щоб злиття вимагало певних голосів.
• Читайте та діліться інформацією про гнучку практику, безперервну інтеграцію та DevOps.

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

Отже, у вас 20 відділень. Відділення 1 просто злито. Тоді розробник гілки 2 повинен об'єднати гілку 1 у свою гілку, щоб мати можливість об'єднатись у головну без конфлікту, а потім злитися. Тоді розробник гілки 3 повинен об'єднати гілку 1 і гілку 2 у свою гілку, щоб мати змогу об'єднатися в основну без конфлікту, а потім злитися.

Вправа для читача: Напишіть програму, яка друкує мою повну публікацію :-)

Це безумство. Ви витратите неймовірну кількість часу на злиття.

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

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