Вибір правильної стратегії розгалуження випусків

Починаючи з нової команди розробників на новому проекті, і ми повинні визначити нашу стратегію розгалуження для нашого вихідного сховища ( наприклад, Microsoft Team Foundation Server 2010 ). Ми зіткнулися з липкою дискусією щодо того, чи варто чи ні ...

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

АБО

B . Майте нову гілку випусків для кожного нового випуску у виробництво ( версії 1, 2, 3 тощо ) ...

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

Хтось має будь-який досвід в будь-якому випадку, який міг би допомогти нам прийняти рішення? Зокрема, я хочу почути, де больові точки для будь-якого вибору. Не соромтеся надавати конкретний досвід стосовно TFS та / або наслідків управління випусками.

Варіант А. Просто використання основної лінії та тегів для випуску

Плюси:

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

Мінуси:

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

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

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

Варіант Б. Відділення за випуском

Плюси:

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

Мінуси:

• Тони гілок.
• Ще потрібно позначати гілки в точках випуску.
• Ще потрібно мати справу з WIP і об'єднати WIP з попередньої гілки випуску в наступну гілку випуску, якщо вона не збирається це робити і все-таки потрібно вимкнути або витягнути її з гілки випуску та повторно запустити тести прийняття
• Гарячі виправлення потрібно застосувати до більшості гілок (випуск гілки + виправлення + новий тег + об'єднання виправлення у гілку vnext і, можливо, vnextnext залежно від місця виправлення.)

Я не є великим прихильником цього рішення ^ _ ^.

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

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

Варіант C. Божевільний варіант бонусу

Якщо ви хочете пофантазувати, ви також можете розглянути модель розгалуження на історію користувача / за особливістю. ( Страшна ідея в TFS або будь-якому не DVCS, але в той же час неймовірно тривіальна для реалізації, якщо ви використовуєте DVCS, як git або mercurial ).

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

1. Особливості були розроблені розробниками у своїх командах відділення розробників.
2. Коли функція готова до рецензування, пакет пакетів розробити її разом в одне злиття від гілки Dev в гілку CR та включити в заголовок ідентифікатор функції / історію користувача. * Закріплений за допомогою гачка попереднього вчинення *
3. Після передачі CR інструмент адміністратора використовується для просування функції у відділення якості. (Я написав невелику термінальну програму, в якій перераховані історії користувачів, присутні на різних етапах прийняття, і дозволив оператору просувати або знизити його між цими етапами прийняття)
4. QA проводить автоматичні та ручні тести на зручність. Якщо функція хороша, її натискають на гілку випуску (основну лінію). Якщо функцію відхилено, її демотирований / повернутий з гілки QA, поки розробники не зможуть вирішити проблеми, що виникають під час тестування, та додати надіслати патч до гілки CR.
5. Якщо код було повернуто з гілки QA і застосовано виправлення, інструмент терміналу повторно застосує необхідні зміни для повернення функції на гілку QA з гілки CR, щоб QA могла повторно переглянути код і або просувати його, або знову продемонструйте це.
6. У будь-який момент часу гілка випуску повинна перебувати в стабільному звільненому стані.
7. Після випуску нові Dev, QA та CR запускаються з магістралі.

Ми маємо окремі відділення для кожного випуску, який ми випускаємо (прибл. 4 на рік). Це дуже зручно, коли вам потрібно витягнути певний реліз.

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

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

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

Коротше кажучи: полегшити життя розробника / підтримувача / виправлення помилок / мислителя проблем і не турбуватися про кількість гілок чи кількість файлів. Будь-який поважаючий себе ревізор впорається.

Редагувати:

Ми взагалі не зазнаємо ніякої плутанини щодо кількості філій у нас. Наша схема іменування галузей випуску та наша галузева політика 1 випуск 1 щодо розвитку (або роботи) гілок може мати щось спільне з цим.

Гілки випусків названі для випуску, який вони містять, тобто: R2011SP1 для випуску пакета оновлень 2011 року. Наші робочі гілки мають менш розумні назви: sub01, sub02, sub03 і т.д. відділення приймання. Гілка приймання - це та, де збираються всі випуски, які готові випустити.

Наша політика роботи 1-го випуску 1 у поєднанні з тим, що наша система відстеження випуску була налаштована під полем «гілка», що гарантує нам завжди знати, яке питання розробляється в якій галузі. Коли питання інтегрується у гілку прийому, це поле оновлюється. Це означає, що ми завжди знаємо, які проблеми готові до випуску (як тільки буде проведено тестування прийняття). Аналогічно, ми оновлюємо це поле, коли створюється гілка випуску, і таким чином ми завжди можемо відстежити, у якому випущено проблему.

Вся справа в контексті: як часто випускаєте та що є у випуску.

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

Щоб поставити історію в контекст,

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

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

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

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

Тож питання, які ви повинні задати собі:

• Як часто я звільняю?
• Чи будуть мої випуски 100% назад сумісними?
• Чи будуть мої клієнти добре з повністю оновленими, щоб виправити помилки?

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

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

У мене було укладено договір, щоб допомогти команді, яка намагалася вибрати варіант B, повернутися назад.

Кілька речей, які слід розглянути.

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

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

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

Тому я рекомендую щось, що насправді є сумішшю A і B ; в обох є хороші аспекти, але жоден з них не є повним. Використовуйте найкраще з обох світів.

У минулому я використовував TFS, щоб ефективно реалізувати варіант (B).

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

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

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

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