У кейсов в IT-отрасли есть проблема с достоверностью: клиент обычно не разрешает показать код или историю коммитов, поэтому остаются цифры, которые нужно принимать на веру. У нас есть один проект, с которым нам не нужно этого делать: собственный сайт eskom.ai. Вся его история — в репозитории, каждую цифру ниже можно проверить в CHANGELOG или в документах о развёртывании. Кейс клиента номер ноль, то есть нас самих.
Почему именно это
Сайт eskom.ai создаётся тем же процессом, который мы описали в статье «Как ESKOM AI создаёт программное обеспечение»: AI-агенты под надзором инженера, автоматические тесты на каждом этапе. Тот текст описывает процесс. Этот показывает, что этот процесс оставляет после себя в конкретном, проверяемом проекте: 27 языковых версий, более 8 500 страниц, административная панель, бэкенд с внешними интеграциями.
Развёртывание в продакшн: всегда одна и та же последовательность
Последовательность развёртывания задокументирована и не меняется: резервная копия и тег перед изменением, pull, сборка, дымовые тесты, функциональные тесты, шлюз принятия решения 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) как цель, принятая и достигнутая после этапа усиления безопасности.
Что это показывает, а что нет
Эти цифры не доказывают, что у нас никогда ничего не ломается – ломается, как в любом живом проекте. Они доказывают нечто более узкое и более проверяемое: что процесс разработки, который мы предлагаем клиентам, – это тот же самый процесс, которым мы тестируем и развёртываем собственный сайт, на глазах у каждого, кто заглянет в репозиторий. Нет отдельной, лучшей версии процесса, зарезервированной для клиентов, платящих за проект. Есть один, используемый и у нас.
FAQ
Эти цифры актуальны, или это снимок за один день?
Это снимок конкретного момента развития проекта (состояние репозитория и CHANGELOG на 13 августа 2026 года). Проект развивается дальше, поэтому некоторые цифры сегодня уже выше. Мы не обновляем этот текст при каждом изменении. Если вам нужно актуальное состояние конкретной области, мы спрашиваем и проверяем в реальном времени.
Почему вы показываете собственную брешь, а не только успехи?
Потому что это более достоверно, чем просто список цифр. Каждый может написать «у нас есть e2e-тесты». Меньше компаний пишут прямо, что какое-то время эти тесты не запускались, и показывают, как это было исправлено. Это вторая половина того же процесса, который мы описываем клиентам: тесты плюс проверка того, действительно ли тесты работают.
Получит ли мой проект такой же уровень тестирования?
Объём тестов мы подбираем под масштаб и риски конкретного проекта. Меньшая интеграция не нуждается в том же наборе шлюзов, что и публичный сайт компании. Правило одно и то же: ни одно изменение не попадает в продакшн без прохождения тестов, адекватных тому, что может пойти не так.
Посмотрим, как это выглядит для вашего проекта
Если вам интересно, как на практике выглядит процесс тестирования и развёртываний, проще всего обсудить это на конкретном примере. Запишитесь на бесплатную консультацию через контактную форму →