Правильно ли в одном workflow создавать сборку, тестирование, публикацию артефакта и деплой в среды?

Нет, я считаю это антипаттерном. В моей практике я строго разделяю CI (Continuous Integration) и CD (Continuous Deployment) на отдельные конвейеры.

Проблемы монолитного workflow:

• Хрупкость: Падение теста блокирует весь pipeline, включая этапы, которые могли бы работать
• Отсутствие идемпотентности: Невозможно перезапустить только деплой без повторной сборки
• Сложность управления промоушеном: Трудно продвигать один и тот же артефакт через разные среды (dev → staging → prod)

Моя типичная реализация в GitLab CI:

# .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

# CI часть - запускается на каждый push/merge
build-job:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      dotenv: build.env  # Сохраняем метаданные

test-job:
  stage: test
  script:
    - docker run $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA npm test
  needs: ["build-job"]

# CD часть - запускается только для определенных веток/тегов
deploy-to-staging:
  stage: deploy
  script:
    - echo "Deploying $CI_COMMIT_SHA to staging"
    - kubectl set image deployment/myapp app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -n staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual  # Требует ручного подтверждения

# Отдельный pipeline для production
# deploy-to-prod:
#   stage: deploy
#   script: ...
#   rules:
#     - if: $CI_COMMIT_TAG =~ /^vd+.d+.d+$/

Ключевые преимущества разделения:

1. Артефакт создается один раз и промотируется через среды
2. Безопасность: Production деплой требует дополнительных проверок (теги, manual approval)
3. Гибкость: Можно настроить разные стратегии деплоя для разных сред (blue-green для prod, rolling для staging)