Ответ
Мы тестируем пайплайн как продукт, чтобы избежать сбоев в продакшене. Вот наш подход:
1. Тестирование в изолированной среде:
- Поднимаем полный стенд в отдельном Kubernetes-неймспейсе (
pipeline-test) с помощью Terraform и Helm. - Используем тестовый артефактный репозиторий и Docker registry.
2. Уровни тестирования:
- Юнит-тесты для скриптов: Пишем тесты на Shell/Bash с использованием
bats(Bash Automated Testing System) для всех наших вспомогательных скриптов деплоя.# Пример теста bats для скрипта проверки конфига @test "config validator exits with 0 on valid yaml" { run ./scripts/validate-config.sh "staging/config.yaml" [ "$status" -eq 0 ] } - Интеграционные тесты пайплайна: Запускаем полный пайплайн от сборки до деплоя на тестовый кластер, используя фиктивный теговый коммит. Проверяем, что артефакты создались, конфиги применились, а health-чек Pod-а проходит.
- Тестирование отката (Rollback): Имитируем сбой на стадии деплоя (например, неверный образ) и проверяем, что механизм автоматического отката срабатывает и возвращает систему в стабильное состояние.
3. Практические метрики для мониторинга пайплайна:
- Success Rate: Отслеживаем в Prometheus процент успешных прогонов.
- Lead Time: Время от коммита до деплоя в прод. Цель — меньше 20 минут.
- Mean Time To Recovery (MTTR): Как быстро пайплайн восстанавливается после сбоя.
4. Используемые инструменты: Для сложных пайплайнов мы пишем интеграционные тесты на Go/Python, которые через API GitLab CI/CD запускают job-ы и проверяют их артефакты и статусы.