Стратегія розгалуження Git інтегрована з процесом тестування / забезпечення якості

Наша команда розробників використовує стратегію розгалуження GitFlow, і це було чудово!

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

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

На якій гілці тестер повинен перевірити нові функції?

Очевидно, є два варіанти:

• на галузь індивідуальних особливостей
• на developгілці

Тестування на розвиток галузі

Спочатку ми вважали, що це вірний шлях, оскільки:

• Ця функція тестується з усіма іншими функціями, об'єднаними у developгалузь з моменту початку її розробки.
• Будь-які конфлікти можуть бути виявлені раніше, ніж пізніше
• Це полегшує роботу тестера, він завжди має справу з однією гілкою ( develop). Йому не потрібно запитувати розробника про те, яка галузь є для якої функції (гілки функцій - це особисті гілки, якими керуються виключно та вільно відповідні розробники)

Найбільші проблеми з цим:

• developФілія забруднюється з помилками.

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

Тестування на функціональній галузі

Тому ми подумали ще раз і вирішили слід перевірити особливості на гілках функцій. Перш ніж тестувати, ми зливаємо зміни від developгілки до функції функції (наздоганяємо developгілку). Це добре:

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

Однак є і деякі недоліки

• Тестувальник повинен здійснити злиття коду, і якщо є конфлікт (дуже ймовірно), він повинен звернутися до розробника про допомогу. Наші тестери спеціалізуються на тесті та не здатні кодувати.
• функцію можна перевірити без існування іншої нової функції. наприклад, функції A і B обидва тестуються одночасно, ці дві особливості не знають одна про одну, оскільки жодна з них не була об'єднана у developгілку. Це означає, що вам доведеться знову протестувати проти developгілки, коли обидві функції так чи інакше об'єднаються з гілкою, що розвивається. І ви повинні пам'ятати, щоб перевірити це в майбутньому.
• Якщо Feature A і B перевірені та затверджені, але при об'єднанні виявлено конфлікт, обидва розробники для обох функцій вважають, що це не його вина / робота, оскільки його функціональна галузь минула тест. У спілкуванні є додаткові витрати, і іноді той, хто вирішує конфлікт, засмучується.

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

Ми робимо наступне:

Ми перевіряємо гілки функцій після об'єднання останнього коду розробки гілки на них. Основна причина полягає в тому, що ми не хочемо "забруднювати" розроблений галузевий код до того, як функція буде прийнята. У випадку, якщо функція не буде прийнята після тестування, але ми хотіли б випустити інші функції, вже об'єднані в розробку, що було б пеклом. Develop - це галузь, з якої зроблено звільнення, і тому краще бути у звільненому стані. Довга версія полягає в тому, що ми тестуємось на багатьох етапах. Більш аналітично:

1. Розробник створює гілку функцій для кожної нової функції.
2. Гілка функцій (автоматично) розгортається в нашому TEST-середовищі з кожним зобов’язанням розробника для тестування.
3. Коли розробник закінчується розгортанням, і функція готова до тестування, він об'єднує гілку розвитку на гілку функції та розгортає гілку функції, яка містить усі останні зміни в розробці на TEST.
4. Тестові випробування на TEST. Коли він закінчиться, він "приймає" історію і об'єднує галузь функції у розробці. Оскільки розробник раніше об'єднав галузь розробки за функцією, ми зазвичай не очікуємо занадто багато конфліктів. Однак у цьому випадку розробник може допомогти. Це складний крок, я вважаю, що найкращий спосіб уникнути цього - зберегти функції максимально дрібними / конкретними. Різні функції повинні бути з часом об'єднані, так чи інакше. Звичайно, чисельність команди відіграє певну роль у складності цього кроку.
5. Гілка розробки також (автоматично) розгорнута в TEST. У нас є політика, яка, навіть не дивлячись на те, що функції, які створює галузь, може бути невдалою, галузь, яка розвивається, ніколи не може провалюватися.
6. Як тільки ми досягли заморожування функції, ми створюємо реліз від development. Це автоматично розгортається в режимі STAGING. Там перед початком розгортання проводяться широкі випробування на кінці. (добре, можливо, я трохи перебільшую, вони не дуже великі, але я думаю, що вони повинні бути). В ідеалі бета-тестери / колеги, тобто реальні користувачі повинні там перевірити.

Що ви думаєте про цей підхід?

Перед тестом ми об'єднуємо зміни від гілки розвитку до гілки функцій

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

Змусьте розробника робити репаузацію своєї featureгілки на вершиніdevel та натиснути цю featureгілку (яка розробником була підтверджена як збирання та робота над останньою develдержавою філії).
Це дозволяє:

• дуже проста інтеграція в гілці функцій (тривіальне швидке злиття вперед).
• або, як рекомендує Aspasia нижче в коментарях , запит на витяг (GitHub) або запит на злиття (GitLab) : сервіс, що здійснює злиття між функцією PR / MR гілки та develop, але лише якщо конфлікт не виявлено GitHub / GitLab.

Кожен раз, коли тестер виявляє помилку, він / вона повідомляє про це розробнику та видаляє поточну гілку функції.
Розробник може:

• виправити помилку
• відновити поверх нещодавно отриманої гілки розробки (знову ж таки, щоб бути впевненим, що його / її код працює в інтеграції з іншими перевіреними функціями)
• штовхнути featureгілку.

Загальна ідея: переконайтеся, що частина злиття / інтеграції виконана розробником, залишивши тестування на QA.

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

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

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

Для отримання додаткової інформації перегляньте це посилання .

Ми використовуємо те, що ми називаємо «золото», «срібло» та «бронза». Це можна назвати prod, staging та qa.

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

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

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

Після того, як функція передає QA, ми переносимо її на "срібло" чи інсценізацію. Будується збірка і тести запускаються знову. Щотижня ми переносимо ці зміни на наше «золото» або дерево прода, а потім розгортаємо їх у нашу виробничу систему.

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

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

Після нашого випуску ми переносимо зміни на золото (prod) на бронзу (тестування) лише для того, щоб все синхронізувати.

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

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

«Випічка» - також приємний побічний ефект. Якщо у вас є якась фундаментальна зміна, яку ви хочете трохи посидіти, там є приємне місце.

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

Я б не покладався тільки на ручне тестування. Я б автоматизував тестування кожної гілки функцій з Дженкінсом. Я налаштовую лабораторію VMWare для запуску тестів Дженкінса в Linux та Windows для всіх браузерів. Це справді дивовижний крос-браузер, рішення для тестування крос-платформ. Я перевіряю функціональність / інтеграцію з Selenium Webdriver. Мої тести на селен працюють під Rspec. І я написав їх спеціально для завантаження jRuby на Windows. Я запускаю традиційні одиничні тести під Rspec та Javascript тести під Жасмином. Я налаштовую тестування без голови без використання Phantom JS.

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

Наш підхід до роботи з GIT такий;

Ми впровадили "Git Flow" у нашій компанії. Ми використовуємо JIRA і тільки затверджені квитки JIRA повинні бути запущені у виробництво. Для затвердження тесту ми вийшли з нього зі створеним окремим тест-відділенням.

Етапи для обробки квитків JIRA є:

1. Створіть нову філію від Develo-Branch
2. Зробіть код Зміни на Feature-Branch
3. Потягніть з Feature the Changes на відділення Тест / QA
4. Після схвалення бізнесу ми перетягуємо зміни з галузевої функції в розробку
5. Розвиток часто випускається у випуску, а потім нарешті освоює галузь

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

Повний процес виглядає приблизно так: