Конвейер непрерывной интеграции (CI) должен давать ответ на конкретный вопрос: можно ли включить это изменение в общую кодовую базу, не добавив известных дефектов и не нарушив согласованные требования? Для этого стоит определить повторяемые проверки, упорядочить их выполнение и обеспечить, чтобы каждый сбой давал полезную информацию.
CI не означает автоматическое развёртывание каждого изменения. Это практика частой интеграции изменений и их автоматической проверки. Непрерывная доставка постоянно подготавливает версию, готовую к развёртыванию; непрерывное развёртывание дополнительно автоматически выпускает её в production при выполнении заданных условий. В приложении может использоваться CI без автоматизации доставки либо доставка может быть автоматизирована до тестовой среды с сохранением этапа утверждения перед production.
Определите контракт конвейера
Прежде чем выбирать инструменты, укажите, что получает запуск, что он должен сформировать и при каких условиях завершается ошибкой. Полезная конфигурация как минимум описывает:
- Входные данные: проверяемое изменение, соответствующая конфигурация и зависимости, объявленные проектом.
- Среда: система и требования к запуску, конфигурация PHP и сервисы, необходимые для тестов. Среда должна быть достаточно похожей при разных запусках, чтобы результаты можно было сравнивать.
- Результат: итоговый статус, отчёты о тестах и анализе, а при необходимости — идентифицируемый артефакт, который можно проверить позднее.
- Условия сбоя: какие ошибки блокируют интеграцию, какие приводят к предупреждениям и кто может принять временное исключение.
Установка должна выполняться на основе версионируемой конфигурации зависимостей и с соблюдением lock-файла, а не незаметно разрешать новые версии при каждом запуске. Это позволяет уменьшить один из источников расхождений между разработчиками и CI. Также необходимо объявить требования приложения к платформе и расширениям и проверить, что среда выполнения им соответствует.
Не допускайте зависимости конвейера от локальных файлов, персональных сервисов или незадокументированных ручных шагов. Если для проверки нужны база данных, кэш или другой сервис, укажите, как он запускается, какие данные ему нужны и как выполняется очистка. Контракт не обязан полностью имитировать production, но должен явно описывать различия, способные повлиять на результат.
Расположите проверки с учётом затрат и способности выявлять проблемы
Практическая последовательность начинается с быстрых проверок и заканчивается теми, которым требуется больше времени или инфраструктуры. Цель — не накопить побольше задач, а как можно раньше обнаруживать проблемы, не теряя значимого охвата.
- Воспроизводимая установка: разрешайте зависимости на основе описания и lock-файла проекта. Если установка завершается ошибкой, остальные результаты ненадёжны.
- Форматирование и соглашения: проверяйте согласованные правила форматирования или стиля. Такие проверки выполняются быстро и не позволяют различиям в оформлении попасть на более затратное ревью.
- Статический анализ: ищите несовместимости и ошибки, которые можно обнаружить без выполнения всех сценариев приложения. Настройте правила в соответствии с кодом и реальной конфигурацией проекта.
- Тесты: сначала запускайте модульные тесты, затем добавляйте интеграционные тесты и end-to-end-тесты в зависимости от покрываемых ими рисков и необходимых сервисов.
- Проверка артефакта: убедитесь, что созданный пакет или образ содержит всё необходимое для запуска и не включает файлы для разработки, локальные данные и секреты.
Не всем приложениям нужны одинаковые тесты и одинаковый порядок проверок. Если статический анализ занимает намного больше времени, чем небольшой модульный тест, возможно, стоит выполнять обе проверки параллельно после установки зависимостей. Независимые задачи также можно запускать параллельно, чтобы сократить ожидание, если они используют воспроизводимую основу, а их результаты привязаны к одному и тому же изменению.
Однако не следует бездумно распараллеливать шаги, которые изменяют один и тот же каталог или зависят от результатов предыдущих шагов. Отделите общую подготовку от последующих задач, ограничьте параллельное использование общих сервисов и чётко обозначьте зависимости между этапами. Цель — ускорить обратную связь, не делая конвейер непредсказуемым.
Решите, что блокирует интеграцию, а что выполняется позже
В качестве исходного правила блокируйте интеграцию, если не проходит проверка, значимая для безопасности изменения: установка, согласованный анализ, обязательные тесты или проверка пакета. Информационная задача — например, проверка, которая пока находится на этапе оценки, — может сообщать результаты, не блокируя интеграцию, в течение заданного периода. У неё должны быть ответственный, дата пересмотра и критерий, по которому она станет обязательной. Иначе предупреждения превратятся в постоянный шум и потеряют ценность.
Быстрые проверки должны давать обратную связь на раннем этапе для каждого изменения. Затратные тесты можно выполнять параллельно, на следующем этапе или с другой периодичностью, если это оправдано временем выполнения или инфраструктурой. Однако если отложить все важные проверки до момента после интеграции, появится временное окно, в котором изменения ещё не проверены. Определите, что требуется до интеграции, а что останется дополнительной проверкой, учитывая последствия позднего обнаружения сбоя.
Успешный запуск не означает, что развёртывание одобрено. CI проверяет изменение и может создать артефакт; процесс доставки определяет, как его продвигать, в какую среду и под какими контролями. Явное разграничение не позволяет задаче проверки случайно опубликовать изменение в production. Если настроено автоматическое развёртывание, отдельно определите его условия, утверждения, стратегию постепенного включения и механизм отката.
Защитите конфигурацию и секреты
Секреты нельзя добавлять в репозиторий, примеры конфигурационных файлов или отчёты о выполнении. Используйте механизм управления секретами в среде CI, предоставляйте их только задачам, которым они нужны, и не выдавайте учётные данные production проверкам, которым требуются лишь изолированные сервисы.
Проверяйте также журналы: исключение, упавший тест или диагностическая команда могут вывести чувствительные переменные. Маскирование значений полезно, но не заменяет мер, предотвращающих их запись. Используйте тестовые данные, не раскрывающие реальную информацию, и определите процедуру отзыва учётных данных, если они попадут в журнал или артефакт.
Обеспечьте возможность диагностировать сбои
Красный статус без контекста заставляет повторять работу и превращает CI в чёрный ящик. Сохраняйте отчёты о тестах и анализе, вывод, необходимый для определения сбойного шага, а также идентификаторы версий зависимостей или артефакта. При этом не записывайте персональные данные, секреты и дампы среды без разбора.
Если тест периодически завершается ошибкой, не отмечайте его как успешный после неограниченного числа повторных попыток. Фиксируйте, какие тесты нестабильны, как часто это происходит и при каких условиях; исследуйте такие причины, как параллельное выполнение, внешние зависимости, общее состояние или тайм-ауты. Если нестабильный тест временно изолируется, задокументируйте риск, назначьте ответственного и укажите дату, когда его блокирующий статус должен быть восстановлен.
Также полезно различать ошибку в коде и проблему инфраструктуры. Сообщайте, если не удалось запустить сервисы, получить зависимости или завершить задачу из-за нехватки ресурсов. Повторная попытка может быть оправдана при временном сбое, но её число должно быть ограничено, а сам факт — виден; сокрытие первого сбоя затрудняет обнаружение повторяющихся проблем.
Адаптируйте CI для устаревшего приложения
В старой системе резкое включение строгих правил может заблокировать полезные изменения и привести к бесконтрольным исключениям. Начните с определения исходного состояния: выясните, какие тесты проходят сейчас, какие уже существующие ошибки обнаруживает анализ и сколько занимает каждый этап. Не считайте регрессией проблему, которая существовала раньше, но и не позволяйте исходному состоянию становиться бесконечным оправданием.
- Сначала сделайте обязательными уже стабильные воспроизводимые проверки, например установку и надёжный набор тестов.
- Зафиксируйте существующие замечания и требуйте, чтобы новые изменения не усугубляли проблему, если инструмент и проект позволяют проводить такое сравнение.
- Добавьте тесты для областей с наибольшим риском изменений и постепенно расширяйте их охват.
- Сокращайте количество исключений небольшими изменениями, которые легко проверить; для каждого временного исключения назначайте ответственного и дату пересмотра.
- Измеряйте время выполнения и причины сбоев, чтобы оптимизировать конкретные этапы, а не удалять проверки, не зная, от какого риска они защищали.
Качество непрерывной интеграции в PHP определяется не количеством этапов, а воспроизводимостью и понятностью результатов. Если команда может объяснить, что проверяет каждый шаг, что блокирует интеграцию и как расследовать сбой, конвейер помогает принимать обоснованные решения о готовности изменения к продвижению.
