Публиковал ли Changework для коммитов

Что такое Change Work и почему он не публикуется в коммитах

Change Work — это метаданные, связанные с задачами в системах управления проектами (Jira, Azure DevOps и других). Это не часть исходного кода приложения, а служебная информация для отслеживания связи между коммитами и задачами, которая обычно используется в процессе Continuous Integration / Continuous Deployment (CI/CD).

Короткий ответ: Нет, Change Work не публикуется напрямую в самих коммитах в репозиторий Git. Его публикация обычно является отдельным этапом в CI/CD-пайплайне.

Детали работы с Change Work

Change Work — это, например, информация о Jira-задаче: ее идентификатор (PROJ-123), статус, тип (bug, feature, story). Эта информация связывается с коммитом для автоматического обновления статуса задачи при успешном мердже или деплое.

Как это обычно работает

1. Коммит содержит ссылку: В сообщении коммита разработчик указывает ID задачи.

   git commit -m "PROJ-123: Добавил валидацию email-поля"
   

2. CI/CD-пайплайн обрабатывает ссылку: При пуше в репозиторий запускается пайплайн (например, в Jenkins, GitLab CI, GitHub Actions).

3. Публикация Change Work — отдельный шаг: В пайплайне есть специальный шаг (например, с использованием Jira API), который:

    *   Находит задачу по ID из сообщения коммита.
    *   **Публикует Change Work**, добавляя в задачу информацию: ссылку на коммит, хеш, ветку, результат сборки.
    *   Может автоматически менять статус задачи (например, на "Готово" или "В тестировании").

Пример конфигурации шага в GitLab CI

publish_change_work:
  stage: deploy
  script:
    - |
      # Используем API Jira для добавления информации о сборке к задаче
      TICKET_ID=$(git log --oneline -1 | grep -oP '\b[A-Z]+-\d+\b' | head -1)
      if [ ! -z "$TICKET_ID" ]; then
        curl -X POST \
          -H "Authorization: Bearer $JIRA_TOKEN" \
          -H "Content-Type: application/json" \
          "https://ваша-компания.atlassian.net/rest/api/3/issue/$TICKET_ID/remotelink" \
          -d "{
            \"object\": {
              \"url\": \"$CI_PIPELINE_URL\",
              \"title\": \"Сборка #$CI_PIPELINE_ID успешно задеплоена на staging\"
            }
          }"
      fi
  only:
    - main  # Публикуем Change Work только при мердже в основную ветку

Почему Change Work не публикуется в коммите

• Разделение ответственности: Git — система контроля версий для исходного кода. Jira/Azure DevOps — системы для управления задачами и процессами.
• Безопасность: В коммиты не должны попадать токены доступа к API, которые необходимы для публикации.
• Динамичность: Статус задачи может меняться позже (например, после ревью), и это не должно влиять на историю коммитов.
• Автоматизация: Процесс должен быть автоматическим и управляемым через CI/CD, а не ручными действиями разработчика.

Типичный сценарий работы

1. Разработчик завершает задачу APP-456.
2. Коммит с сообщением APP-456: Fix user login error.
3. Пуш в ветку, создание Merge Request (MR) / Pull Request (PR).
4. После одобрения MR и мерджа в main ветку:

    *   Запускается пайплайн сборки и деплоя.
    *   На этапе `deploy_to_staging` успешный деплой триггерит шаг `publish_to_jira`.
    *   **Этот шаг публикует Change Work**: добавляет в задачу `APP-456` ссылку на пайплайн, помечает задачу как "Развернуто в тестовой среде" (`Deployed to Staging`).

Заключение

Таким образом, публикация Change Work — это операция на стороне CI/CD-системы, выполняемая через API систем управления задачами. Она происходит после коммитов, как часть автоматизированного процесса доставки кода. Разработчик лишь обеспечивает связь через ID задачи в сообщении коммита, а вся дальнейшая "магия" публикации метаданных ложится на правильно настроенный пайплайн. Это ключевая практика в современных DevOps-процессах для обеспечения сквозной трассируемости от кода до бизнес-требования.