Quality Gate в CI/CD: як налаштувати мінімальні вимоги до коду

Quality Gate: де конвеєр збірки пропускає дефекти

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

Друге місце — обійдені правила. Права адміністратора дозволяють проштовхнути коміт в обхід черги, а термінова правка вирушає в основну гілку без рев’ю. Крок перевірки, вимкнений «на час», повертається через місяці — і весь цей час поріг якості коду фактично не діє.

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

Нарешті, сам поріг. Quality Gate, зведений до загальних слів, пропускає все: збірка падає пізно — артефакт уже зібрано, тести пройдено, і лише на фінальному кроці з’ясовується, що версія не проходить за вразливостями. Зупинка на цьому етапі дорожча за відмову на перших секундах у рази.

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

Ефект від єдиних вимог до коду: що вимірюємо

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

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

• Частка відкатів релізу. Скільки викочувань відкотили протягом доби після випуску. Критичні зміни відсікаються до злиття в основну гілку, і показник падає.
• Час перевірки змін. Від відкриття запиту на злиття до вердикту. Повний прогін має вкладатися в хвилини, інакше розробники почнуть обходити правила.
• Частка повернень завдання на доопрацювання. Скільки змін іде на друге коло не через зауваження рев’юера, а через червоні перевірки. Показує, де правила надто строгі, а де заважають самі тести.
• Класи пропущених дефектів. Секрети в репозиторії, уразливі залежності версій, падіння покриття нижче порога — після ввімкнення перевірок вони перестають доходити до основної гілки.
• Покриття нових рядків тестами. Поріг на зміни, а не на весь проєкт: вимагати високе покриття від старого коду безглуздо й призводить до формальних тестів.
• Стабільність релізу. Число інцидентів на реліз і час до виявлення проблеми. Порогові перевірки не прибирають збої, але зсувають їх виявлення в бік конвеєра, де ціна виправлення на порядок нижча.

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

Варіанти Quality Gate: порівняння підходів

Quality Gate можна поставити на трьох рівнях: на машині розробника, на сервері збірки й у ручному контурі приймання.

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

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

Робочий режим на практиці — гібрид: перевірки до коміту, обов’язковий мінімум на сервері збірки, ручне рев’ю для критичних ділянок. Правила при цьому не дублюються: кожен рівень відповідає за свій клас помилок, інакше Quality Gate починають обходити.

Порядок впровадження: від аудиту до передачі

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

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

2. Схема перевірок. Розкладаємо дефекти за етапами: синтаксис і стиль — перед комітом, модульні тести — на збірці, регрес і перевірки безпеки — перед злиттям в основну гілку. Для кожної перевірки вирішуємо, блокує вона злиття чи лише сигналізує.

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

4. Перевірка на пілотному контурі. Вмикаємо правила в режимі попередження на одній команді або сервісі й дивимося тиждень: скільки хибних спрацювань, де перевірки гальмують збірку без користі. Пороги калібруємо за фактом.

5. Переведення в блокуючий режим. Коли шуму майже немає, правила починають зупиняти злиття. Для критичних шляхів залишаємо усвідомлений обхід із фіксацією причини — інакше правило вимкнуть цілком.

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

Ознака готовності — правила живуть без нас: пороги змінюються через рев’ю, а нові сервіси підключаються за описаним шаблоном.

Комплект документів і налаштувань для підтримки конвеєра

Результат налаштування — не усні домовленості, а комплект артефактів, який лежить поруч із кодом у репозиторії й продовжує працювати після зміни складу команди. Нижче — що саме залишається у замовника після впровадження.

• Файл налаштувань контролю якості: пороги за покриттям змінених рядків, допустимим дублюванням, довжиною методів, наявністю незакритих задач; окремо позначено, що блокує злиття, а що лише попереджає.
• Схема конвеєра: які перевірки йдуть на кожен коміт, які — під час злиття в основну гілку, де стоїть ручне підтвердження і за якої умови воно знімається.
• Перелік правил — єдиний документ із формулюванням кожної вимоги та посиланням на налаштування, яке його застосовує. Правило без налаштування вважається неробочим і до переліку не потрапляє.
• Перелік винятків: успадковані модулі, автогенерований код, скрипти міграцій — із причиною, відповідальним і датою перегляду. Виняток без дати автоматично спливає.
• Інструкції для команди: як відтворити перевірки на робочій машині до надсилання змін, як читати звіт про порушення й як легально оскаржити хибне спрацювання.
• Регламент змін: пороги правляться окремою зміною з обґрунтуванням і перевіркою другим інженером; ослаблення вимоги фіксується в історії, а не тоне в листуванні.
• Звіт про спрацювання: накопичена статистика щодо заблокованих злиттів і хибних відмов — за нею раз на квартал переглядають пороги.

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

Кейс: як скоротили частку дефектів на реліз

З чим прийшли

Продукт із частими релізами: кілька десятків змін на тиждень, три команди в одному репозиторії. Перевірки в конвеєрі формально були, але необов’язкові — збірка падала не завжди, звіт аналізатора ніхто не відкривав, а перевірка коду зводилася до «виглядає нормально».

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

Що змінили

Quality Gate зробили обов’язковою умовою просування гілками: покриття нового коду тестами, відсутність критичних зауважень аналізатора, успішний прогін тестів і перевірка другим інженером.

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

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

Що стало

Частка дефектів, що доходили до користувачів, скоротилася приблизно втричі, критичних — до нуля. Час перевірки змін упав із кількох годин до 20 хвилин, підготовка релізу — з дня до пари годин, число відкатів зменшилося вдвічі: падіння ловляться на етапі перевірки, а не в проді.

Інженери перестали вручну перепроверяти те, що вже закрито конвеєром, — довіра до перевірок стала вимірюваною, а не декларативною.

Чим перевірка в спільній збірці відрізняється від локальної?

Локальна перевірка йде на машині розробника до надсилання змін: вона бачить змінений файл і спрацьовує за секунди. Спільна збірка бачить проєкт цілком — із залежностями й чужими правками. Звідси й різна ціна помилки: локальна затримка дратує, а зупинена спільна збірка зупиняє всіх.

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

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

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

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

Технічні сумніви під час впровадження перевірок якості

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

Скільки займає впровадження і хто супроводжує правила?

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

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

Чи не зросте навантаження на розробників?

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

Обговоримо ваше завдання і повернемося з планом

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

На виході ви отримуєте робочий контур Quality Gate і зрозумілий склад робіт за етапами:

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

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

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