Для версії на основі гілок потрібно поговорити про наступну діаграму, яка ідеально ілюструє панораму процесу керування конфігурацією. По-перше, ця діаграма написана на основі моделі Git, але насправді Git і Subversion вже зрозуміли концепцію керування контролем версій, хоча Git робить якісний стрибок уперед у сфері управління гілками та розподіленої продуктивності (хоча це не є основною темою цієї статті).
Перед тим, як ввести принцип цього графа, давайте поговоримо про дві різні стратегії загального контролю версій: одна — «піонерський магістраль, стабільна гілка», а інша — «стабільний магістраль, піонерська гілка». Як випливає з назви, це стабільна версія (виробнича версія) — на стовбурі або на гілці. У випадку традиційних проєктних команд, які використовують VSS, важко сказати, до якого режиму він належить, головним чином тому, що сама VSS не має стратегії управління гілками, тому багато команд створюють відповідно дві (або три) бібліотеки версій, що відповідають виробничому та розробному середовищу; звісно, це також свого роду управління гілками під маскуванням. Однак, якщо переключитися на Subversion або Git як інструмент контролю версій, більшість команд використовують режим stable trunk, тобто trunk (truck або master) відповідає стабільному виробничому середовищу і позначає різні релізи, щоб вказати на production версію. Особисто я вважаю, що стабільний основний патерн коду має стати абсолютним основним рішенням для управління версіями коду на даний момент. Вищенаведене зображення — це стандартна модель управління «стабільним хребтом».
майстер: відповідна Subversion — вантажівка。 Відповідно до виробничої версії, вона позначається один раз у кожному релізі.
Відгалуження випуску (також відоме як інтеграційна гілка): Поки продакшн оновлюється, його потрібно спочатку об'єднати з гілкою релізу (інтеграційна гілка). Це дещо схоже на те, що команда проєкту зараз називає концепціями «препродакшн» і «симульованого середовища».
Розробка гілки (гілка розробки або гілка розробки): Середовище, з яким стикається середовище розвитку.
Feature branch (feature branch): Деякі незалежні функції можна відокремити від окремої гілки розробки. Це головним чином для того, щоб врахувати те, що деякі функції можуть довго оновлюватися, щоб не затягувати реліз і розділяти гілки.
Гілка гарячих виправлень (гілка виправлення багів): Баг тут здебільшого виробничий.
Після знайомства зі стовбуром і гілками мені потрібно ввести напрямок їх генерації та злиття.
Master — це продакшн-версія, і trunk приймає лише дві гілки для об'єднання: одна — це гілка release (інтеграційна гілка), а інша — гілка hotfixes. Жодна інша гілка не може бути об'єднана у виробничу гілку.
Відгалуження випуску спочатку створюється одночасно з продакшном, і це точно те саме, що й продакшн. Він приймає лише dev-гілку, щоб об'єднатися з нею. Іншими словами, він не приймає злиття безпосередньо з гілки feature або з гілки виправлення багів.
Гілка розробки, гілка розробки, як і гілка інтеграції, на певний момент часу — це те саме, що й середовище виробництва. Однак у міру розвитку розробки нові функції продовжуватимуть створюватися на гілці розробників. Dev Theory приймає об'єднання лише двох гілок: одна — хотфікси, а інша — feature branch.
Feature branch, починаючи з певної точки (версії) з гілкою розробки, ця feature branch зрештою об'єднується з гілкою розробки.
Давайте коротко розглянемо метод контролю версій у вигляді сценарію
Припустимо, що продакшн-версія поділена на гілки (розробка, хотфікси, реліз), і на цьому етапі розробник починає розробляти загалом десять функцій. Коли було розроблено 8 із 10 функцій, команда тестування почала втручатися у внутрішньому тестуванні, а адміністратор конфігурації розгорнув гілку розробки в середовище розробки для тестування через інструменти безперервної інтеграції (окрема тема тут). Коли тестова верифікація виявила, що дві функції є абсолютно неприйнятними і потребують переробки, таких як проста страхова страховка та повернення претензій, дві функціональні гілки були відокремлені від розробки, що відповідають простому страховому страхуванню та поверненню претензій, а на гілці розробки відповідний код також потрібно було відкотити (ручна робота тут). Коли тестова команда виявляє, що з тестом гілки розробки немає проблем, він відповідає умовам UAT, тому адміністратор конфігурації об'єднує гілку розробника з гілкою випуску, а потім використовує інструменти безперервної інтеграції, щоб опублікувати цю гілку в передпродакшн-середовищі та передати її користувачу для тестування. Коли верифікація користувача виявляє проблему, розробник змінює гілку розробника, а потім об'єднує її з гілкою релізу (тут, на оригінальному зображенні, вона безпосередньо змінюється у гілці релізу, я вважаю, що це погано, рекомендую розробнику звертатися лише до гілки розробника), коли процес верифікації релізу раптово виявляє серйозний баг у середовищі збірки, який потрібно негайно виправити, його терміново змінюють у гілці гарячих виправлень, і він терміново запускається після перевірки правильності. Водночас гілка хотфіксів об'єднується з dev (тут це переважно ручно, бо на той момент продакшн-версія вже дуже відрізняється від dev-версії, і часто неможливо завершити автоматичне злиття), а потім dev об'єднується у реліз. Через певний час функція повернення претензій може більше не бути потрібна і її потрібно скасувати, тому гілка повернення претензій буде видалена. Ще одна функція легко застрахувана, і вона була розроблена та знову об'єднана з гілкою розробки для запуску наступної онлайн-версії.
Вищезазначений сценарій в основному включає рутинну розробку, розпаковування, екстрені оновлення та інші сценарії у щоденному процесі розробки.
|
Опубліковано 08.04.2018 10:25:39
|
|
|
|
