Кейси в галузі ІТ мають проблему з достовірністю: клієнт зазвичай не дозволяє показувати код чи історію комітів, тому залишаються лише цифри, дані на слово. У нас є один проект, при якому цього робити не потрібно: власний сайт eskom.ai. Ціла його історія знаходиться в репозиторії, кожна цифра нижче можна перевірити в CHANGELOG-u чи в документах щодо впровадження. Кейс-стаді клієнта нуль, тобто нас самих.
Чому саме це
Сайт eskom.ai створений тим самим процесом, який описано в статті «Як ESKOM AI створює програмне забезпечення»: агенти AI під наглядом інженера, автоматичні тести на кожному етапі. Той текст описує процес. Цей показує, що цей процес залишається після себе в конкретному, перевірному проекті: 27 мовних версій, понад 8 500 сторінок, адміністративна панель, бекенд з зовнішніми інтеграціями.
Впровадження на виробництво: завжди та сама послідовність
Послідовність впровадження задокументована і не змінюється: бекап і тег перед зміною, пул, білд, димові тести, функціональні тести, рішення про перехід GO/NO-GO, тільки після цього перемикання трафіку. Перший запит на зміну виробництва з березня 2026 (CR-001) описував цю послідовність близько 18 хвилин від бекапу до рішення GO/NO-GO. Це був план, не таймер. План відкачу готовий до початку, не написаний у паніці, якщо щось піде не так.
Учеста історія: пробіл, який ми самі знайшли
Найлегше було б сказати, що у нас є тести end-to-end у 32 файлах (станом на 13 серпня 2026 року) і закінчити на цьому. Це правда, але не вся. Через деякий час ці тести існували у репозиторії та не запускались через CI. Конфігурація пайплайну мала нуль посилань до e2e, хоча код тестів чекав готовий. Іншими словами: у нас було забезпечення, яке нікого не захищало, бо ніхто його не вмикал при кожній зміні.
Ми знайшли це самі, у рамках рутинного огляду, не після інциденту. Виправлення: перший запущений підмножина тестів e2e у CI, перевірений рядок за рядком перед увімкненням, з планом розширення на решту. Ми пишемо про це прямо, бо це краще показує, як виглядає наш процес контролю якості, ніж сама кінцева кількість. Ловлення власних прогалин, перш ніж це зробить хтось інший, є частиною того самого процесу тестування, що й написання нових тестів.
Що ще пильнує якості на кожен день
Сканування секретів: брамка assert_gitleaks_coverage.sh з 11 тестами, всі зелені. Пильнує, щоб жоден ключ API чи пароль не потрапили до репозиторію.
Згодність змісту з GDPR перевіряє окрема, автоматична брамка. Розрослася з 15 до 19 тестів у міру виявлення нових випадків.
Свіжість даних у панелі адміністратора, окремий приклад з багатьох: тест lighthouseFreshness.test.ts має 20 окремих асерцій, що перевіряють, що результати аудиту продуктивності, показані адміністраторам, не є застарілими.
Продуктивність: результат Lighthouse 100/100/100/100 (продуктивність, доступність, найкращі практики, SEO) як ціль, прийнята і досягнута після етапу hardeningу безпеки.
Що це показує, а чого не
Ці цифри не доводять, що ніколи нічого не ламається — ламається, як у будь-якому живому проєкті. Доводять чогось вужчого і більш перевіреного: що процес виробництва, який ми пропонуємо клієнтам, є тим самим процесом, яким ми тестируємо і впроваджуємо власну сторінку, на очах кожного, хто загляне до репозиторію. Не існує окремої, кращої версії процесу, зарезервованої для клієнтів, які платять за проєкт. Є одна, яку також використовують у нас.
FAQ
Чи ці цифри актуальні, чи це знімок одного дня?
Це знімок з конкретного моменту розвитку проєкту (стан репозиторію і CHANGELOG на 13 серпня 2026). Проєкт продовжує розвиватися, тому деякі цифри сьогодні вже вищі. Ми не оновлюємо цей текст при кожній зміні. Якщо вам потрібно актуальний стан конкретної області, ми просимо і перевіряємо наживо.
Чому ви показуєте власну пробіл у місці тільки успіхів?
Бо це більш достовірно, ніж просто список цифр. Будь-хто може написати "у нас є тести e2e". Менше фірм пише прямо, що протягом певного часу ці тести не запускались, і показує, як це було виправлено. Це друга половина того самого процесу, який ми описуємо клієнтам: тести плюс перевірка того, чи тести фактично працюють.
Чи мій проєкт отримає той самий рівень тестів?
Обсяг тестів ми підбираємо до масштабу і ризику конкретного проєкту. Менша інтеграція не потребує ідентичного набору бранок, як публічна сторінка компанії. Принцип такий самий: жодна зміна не потрапляє на виробництво без проходження тестів, адекватних до того, що може піти не так.
Подивімося, як це виглядає для вашого проєкту
Якщо Вас цікавить, як виглядає процес тестування та впровадження на практиці, то найпростіше обговорити це на конкретному випадку. Заплануйте безкоштовну консультацію через контактну форму →