Де слід проводити тестування з контролю якості в моделі розгалуження Gitflow

Ми велика команда (10-12 розробників і 4 qa), яка працює над декількома проектами з одним і тим же сховищем git. Веб-сервіс на базі весняного завантаження. Ми шукаємо гарну стратегію розгалуження та розгортання git. У нас також є команда qa, яка забезпечує, щоб наші функції працювали як очікували (помилка вільна до певної міри).

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

Де наша команда з QA повинна перевірити наші можливості?

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

Мені цікаво почути, який підхід спрацював добре для інших.

QA, ймовірно, повинен тестуватися двічі.

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

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

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

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

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

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

Але очевидно, що це трохи пізно в день, щоб ви вперше перевірили код взагалі!

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

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

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

Зі свого досвіду я рекомендую:

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

Щоденне тестування / автоматичне тестування у відділенні розробників, розгорнутих на сервери qa. Дозволяє випробувати всі функції разом і сказати, коли ви готові до випуску.

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

(Прихильники scrum скажуть, що ви повинні вводити лише виправлення помилок у спринт 2, але дозволяти бути практичним)

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

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

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

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

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