Розробники заблоковані, чекаючи коду для злиття з іншої гілки за допомогою GitFlow

Наша команда щойно перейшла з FogBugz & Kiln / Mercurial на Jira & Stash / Git. Ми використовуємо модель Git Flow для розгалуження, додаючи відгалуження підзадач від функціональних гілок (що стосуються підзадач Jira з особливостей Jira). Ми використовуємо Stash для того, щоб призначити рецензента, коли ми створюємо запит на витяг, щоб об'єднатися назад у батьківську гілку (зазвичай розробляється, але для підзадач назад у гілку функцій).

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

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

Я знаю, що це не обов'язково проблема Git - це стосується роботи над взаємозалежним кодом у кількох галузях, що поєднується з нашим власним робочим процесом та культурою. Якби у нас не було суворої політики перегляду коду для розробки (справжня галузь інтеграції), тоді розробник 1 міг би об'єднатися з розробником для виходу з програми 2. Ще одне ускладнення полягає в тому, що нам також потрібно пройти попереднє тестування в рамках процесу перегляду коду, перш ніж передавати функцію QA. Це означає, що навіть якщо розробник 1, що перебуває на передньому кінці, витягується безпосередньо з гілки розробника 2, оскільки вони перейдіть, якщо бек-енд розробник 2 закінчується і його / її запит на витяг сидить в огляді коду протягом тижня, тоді передній розробник 2 технічно не може створити його запит на виклик / перегляд коду, оскільки його / її рецензент на коди не може тест, оскільки бек-енд-розробник 2 '

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

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

Проблема також може полягати в занадто жорсткому розділенні завдань між бек-ендом і передньою розробкою.

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

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

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

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

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

Однак це не означає, що розробник 2 утримується! Розробник 2 може почати працювати над функцією C і повернутися до циклу огляду та виправлення функції B, коли функція A буде завершена. Я знаю , що перемикання контексту не є оптимальним, але з того часу , він буде приймати до повного ознакою А, ймовірно , вимірюються в дні , це не що погано (ви не витягати їх з «Зони» на 15 хвилин бічній завдання)

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

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

Чи є способи розбити функції на більш дрібні одиниці роботи, щоб продовжувати цикл інтеграції?

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