Какой инструмент CI/CD вы бы выбрали для нового проекта?

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

Ответ

Мой выбор зависит от стека, инфраструктуры и требований команды. В последних проектах я работал со следующими инструментами:

Для облачных нативных проектов и Kubernetes:

  • GitLab CI/CD — использовал в связке с GitLab Container Registry и Auto DevOps для полного цикла от коммита до продакшена. Его встроенный Docker executor и интеграция с k8s через kubeconfig очень удобны.

    # .gitlab-ci.yml пример для сборки и деплоя
    stages:
      - build
      - test
      - deploy
    
    build:
      stage: build
      script:
        - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
        - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    
    deploy-to-staging:
      stage: deploy
      script:
        - kubectl set image deployment/my-app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -n staging
      only:
        - main
  • GitHub Actions — отлично подходит для open-source и проектов, уже размещённых на GitHub. Использовал его для автоматизации тестов и сборки многоархитектурных Docker-образов (linux/amd64, linux/arm64).

Для сложных enterprise-пайплайнов с гибкостью:

  • Jenkins с декларативными пайплайнами и shared libraries. Например, настраивал параметризованные сборки с выбором среды деплоя и версии. Его главный плюс — огромное сообщество и плагины, минус — необходимость самостоятельно поддерживать мастер и агентов.

Для GitOps-подхода в Kubernetes:

  • Argo CD в паре с GitHub Actions (для CI). Actions собирает образ и обновляет манифесты в Git, а Argo CD автоматически синхронизирует состояние кластера. Это обеспечивает полную наблюдаемость и откат к любому коммиту.

Критерии выбора: интеграция с текущим стеком (Git-хостинг, контейнерный реестр, оркестратор), требования к безопасности (изоляция раннеров), сложность пайплайна и возможности отладки.