Ответ
Я использовал GitLab CI/CD для автоматизации сборки и деплоя различных проектов в рамках DevOps-практик:
1. Микросервисы на Go/Python/Java: Стандартный пайплайн включал этапы lint, test, build, security scan (SAST/DAST с GitLab SAST или Trivy) и публикацию Docker-образа в GitLab Container Registry. Для Java-проектов использовался кэш Maven/Gradle.
build:docker:
stage: build
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
only:
- merge_requests
- main
2. Инфраструктура как код (Terraform):
Пайплайн для управления инфраструктурой с этапами terraform fmt/validate, terraform plan с выводом артефакта для ручного review, и terraform apply только для merge в main-ветку.
3. Helm-чарты для Kubernetes:
Автоматическая сборка пакетов .tgz, линтинг с helm lint, тестирование установки в изолированном namespace (например, с помощью kind) и публикация в Helm-репозиторий (например, ChartMuseum).
4. Сборка и тестирование Ansible-ролей:
Использовал Docker-раннеры для запуска тестов с molecule в различных сценариях (converge, idempotence, verify).
Ключевые практики, которые я применял:
- Динамические окружения: Создание preview-окружений для каждой feature-ветки.
- Многоступенчатые деплои: Использование manual-джобов с
when: manualдля approval перед продом. - Кэширование: Кэш зависимостей (
node_modules,vendor) и Docker-слоев для ускорения сборок. - Интеграция с мониторингом: Автоматический rollback деплоя при срабатывании алертов в Prometheus через webhook.