Какие проекты собирали с помощью GitLab CI?

«Какие проекты собирали с помощью GitLab CI?» — вопрос из категории CI/CD, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Я использовал 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.