Как настроить CI/CD пайплайн?

Настройка CI/CD пайплайна зависит от выбранного инструмента (Jenkins, GitLab CI/CD, GitHub Actions, CircleCI), но общая структура схожа. Я обычно начинаю с определения этапов и триггеров.

Основные этапы типичного пайплайна:

1. Сборка (Build): Компиляция кода, сборка Docker-образа.
2. Тестирование (Test): Запуск unit-тестов, интеграционных тестов, статического анализа кода (linting).
3. Деплой (Deploy): Развертывание в staging-окружение, а затем, после ручного или автоматического подтверждения, в production.

Пример .gitlab-ci.yml для приложения на Go с деплоем в Kubernetes:

stages:
  - build
  - test
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

build:
  stage: build
  image: golang:1.21
  script:
    - go build -o myapp ./cmd/app
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE
  artifacts:
    paths:
      - myapp

test:
  stage: test
  image: golang:1.21
  script:
    - go test ./... -v
    - go vet ./...

deploy-staging:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/myapp myapp=$DOCKER_IMAGE -n staging
  only:
    - main
  environment:
    name: staging
    url: https://staging.myapp.com

Ключевые практики, которые я применяю:

• Хранение секретов: Использую встроенные секреты инструмента (GitLab CI Variables, GitHub Secrets) для хранения токенов, паролей и kubeconfig.
• Кэширование: Настраиваю кэш для зависимостей (например, ~/.cache/go, node_modules) для ускорения сборок.
• Артефакты: Передаю результаты сборки (бинарники, образы) между джобами.
• Уведомления: Интегрирую пайплайн с Slack или Teams для оповещений об успешных/неудачных сборках.
• Откат (Rollback): Готовлю скрипт или конфигурацию для быстрого отката к предыдущей версии образа в Kubernetes (kubectl rollout undo).