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

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

• Розпочинаючи нове завдання, розробники створюють "особливу гілку" від основної гілки розвитку (ми використовуємо git ) і працюємо над цією новою гілкою
• Як тільки розробник закінчив роботу над своїм завданням, вони об'єднують свою функціональну гілку назад у галузь розвитку
• Розробник об'єднує галузь розвитку в гілку якості.
• Побудова запускається з гілки QA. Вихід цієї збірки розміщується в нашому середовищі якості, щоб тестувальники могли розпочати тестування.

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

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

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

Чи є кращий спосіб забезпечити чисту структуру для наших релізів через кожний тиждень?

У цьому виникає кілька проблем, які викликають проблеми, які виникають у вас.

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

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

Далі ви отримаєте ролі, які нападають на них. Це означає, що роль упаковки (детальніше про це пізніше) не стає достатньо ізольованою.

У моделі git-flow гілка випуску відгалужується від розробки ( не розвиток об'єднано в QA), і всі виправлення перевіряються у гілку випуску, а потім об'єднуються назад у гілку розробки.

Деякі з філософії розгалуження можна знайти в розширених стратегіях розгалуження SCM (я вважаю відмінним прочитаним). Це зосереджено на ролях, які може взяти на себе кожна галузь. Гілка випуску приймає на себе роль упаковки.

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

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

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

Мені здається, проблема у тому, що у вас є одна філія QA.

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

Таким чином, «заморожування» цілком очевидно - це в назві гілки. Ви можете використовувати щось на кшталт, я не знаю , release/26/10/2015. Тоді очевидно, що після цього ніхто не повинен зливатися в нових функціях.

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

Немає жодної тривалої гілки QA, це просто благає клопотів. Завантажте від основної гілки розробки для кожного випуску та QA цієї гілки.

Ви дещо відображені на моделі розгалуження Development-MAIN-Production, показаній нижче. Кажуть, що область над МАЙН є областю розвитку. Площа нижче МАЙН - це виробнича площа.

Основні моменти цієї моделі, які я вважаю актуальними для вас:

• Ваші розробники повинні часто (2-3 рази на тиждень) часто (2–3 рази на тиждень) інтегруватись у свої відділення DEV для інтеграції вперед (FI) (FI = зливатися від МАЙН) для того, щоб їх останні зміни завжди враховували останні загальні зміни.
• Ваші розробники повинні повернути інтеграцію (RI) (RI = злиття в напрямку MAIN) у гілці TEST лише тоді, коли вони досягли основної межі завершення функції, яку вони хочуть виставити QA і для якої вони готові надати оперативні виправлення в відповідь на зворотній зв'язок із якістю. Виправлення будуть виконані на TEST-відділенні та негайно FI у їхньому відділенні DEV.
• Ніколи не RI з будь-якого відділення DEV в MAIN
• Завжди RI з відділення TEST перебуває у ГОЛОВНІЙ, виключно тоді, коли ваш QA вважає якість TEST нормальним. Зберігайте високий поріг якості для злиття в MAIN. Принаймні, Ваш менеджер продуктів повинен мати змогу завжди демонструвати робочу версію Вашого продукту з останньої версії в ГОЛОВНІЙ.
• Створюйте філії у виробничій зоні лише за потребою. Ваш сервер збирання завжди повинен тегувати всі гілки, включаючи ті, що знаходяться в області розробки, і джерело будь-якої збірки / випуску має бути ідентифікованим у будь-який час незалежно від гілки, з якої він походить.
• Візьміть випуски на виробництво тільки з ГОЛОВНОГО або виробничого району. Якщо пізніше вам потрібно надати виправлення для точно випущеної версії (тобто ви не можете просто дати останню версію від MAIN), створіть гілку у виробничій області з тегу MAIN несправного випуску, коли потрібне виправлення. Завжди виправляйте проблему у відділенні HotFix, а потім негайно перейдіть на MAIN та FI у TEST.

Я підозрюю, що у вас є проблеми через:

• Ваш RV-розробник в TEST-код, який не є важливим етапом
• Ваші розробники RI в TEST, не отримуючи зеленого світла від QA (тобто QA не контролює те, що потрапляє в TEST)
• Коли QA повідомляє про помилку на TEST, ваші розробники виправляють це на своїй гілці DEV, а потім RI в TEST. Це головна погана практика, оскільки злиття завжди спричинятиме інші неповні лайни. Вони завжди повинні зафіксувати це на TEST, а потім FI у свою відділення DEV. Якщо це не можна виправити на TEST, вони в першу чергу доставляють загальне лайно, і у вас є більші проблеми.
• Ваші дияволи недостатньо часто випробовують TEST, і тому вони дестабілізують TEST кожного разу, коли вони доставляють туди. Це образотворче мистецтво, що врівноважує, як часто FI в DEV. Відкладіть це занадто багато, і це буде дуже дорого та ризиковано безпосередньо перед доставкою, чого ви ніколи не хочете. Робіть це занадто часто, і у вас не буде виконано жодної фактичної роботи, якщо ви занадто багато перетинаєтесь з роботою, яку постачають інші люди в TEST в середній час.

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

Незалежно від вашої моделі розгалуження SCM, я пропоную спробувати одне або обидва з наступного:

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

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

Ви кажете, що команда спритна, але незрозуміло, чи працюєте ви у спринтах (тобто Scrum) або підході більш постійного потоку (тобто Kanban). Якщо припустити, що ви займаєтеся спринтами, мета для команди - мати код, що випускається в кінці кожного спринту, для вашого щотижневого виходу. Немає плутанини в тому, чи одна функція порушить іншу, оскільки всі вони були розроблені разом. Тестери можуть отримати доступ до функцій в менших розмірах, оскільки накладні витрати розробників на їх доставку нижчі. І вам дійсно не потрібна QA-Freeze, натомість всі знають, коли закінчується спринт, і не повинні братись за роботу, яку вони не можуть закінчити, або залишати в розгорнутому (тобто відключеному) стані.

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

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

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

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