Процесс публикации изменений с ИИ в GitHub, Confluence и Jira

Вернуться к курсу по совместной работе с ИИ

Участник фиксирует PROP-042 до одобрения владельцами. Публикатор Confluence обновляет требования, сопровождающий GitHub объединяет реализацию, а операционная команда публикует runbook. Jira регистрирует каждый шаг. Выполняйте эти действия после проверки разрешений, поскольку три системы не образуют одну атомарную транзакцию. Журнал публикаций поможет увидеть незавершённую доставку.

Главное #

• Одобренное намерение отличается от реализованного поведения.
• Фиксированные редакции предложения связывают проверку с конкретной версией.
• Журналы публикаций показывают частичное выполнение.
• Повторное чтение источников защищает от изменения базовых данных.

Перед началом #

Предварительные условия: настройка рабочего места , право публикации, владельцы и сопровождающий репозитория. Оценка времени: два часа. Сложность: продвинутая координация.

Базовый интерфейс: чтение в браузере, при необходимости составление черновика в одобренном чате и публикация человеком. Подписка на коннектор не предполагается. Перед добавлением интеграции проверьте доступность в тенанте, области разрешений, обработку данных поставщиком и сопоставление учетных записей. Никогда не передавайте участнику учетные данные владельца.

Результат для читателя: в конце у вас будут фиксированное предложение, журнал публикаций для каждой системы, доказательства повторного чтения и решение о восстановлении после первого незавершённого шага. Упражнение проверяет процедуру и работу с доказательствами, но не поведение хранения данных в рабочей среде.

Зафиксируйте текущие источники #

1. Прочитайте MAP-01, затем откройте REQ-17 и RUN-04 по сопоставленным идентификаторам страниц.
2. Откройте меню страницы и историю страницы (Page History) и зафиксируйте номера версий, статус, текст, владельца и исключения.
3. Прочитайте задачу Jira и приложите фиксированный экспорт предложения или коммит GitHub. Один только ключ задачи не фиксирует доказательства проверки.
4. Прочитайте утверждённую POL-01 и защищённую базовую конфигурацию.
5. Передавайте в чат только необходимые синтетические фрагменты, помечайте их как снимки и отключайте действия с правом записи.

Task: PROP-042, propose only
Authority: Confluence REQ-17 for intent, GitHub for behavior
Read: mapped current pages, versions, scope, exceptions
Proposal: synthetic export retention from 7 to 30 days
Output: requirement wording, config diff, runbook, ledger
Evidence: source ID and captured revision for each factual claim
Unknowns: missing access and absent runtime observations
Stop: conflict, changed base, or denied access

Офлайн-пакеты остаются снимками. Перед записью публикатор повторно читает актуальные данные. Отказ в доступе блокирует публикацию. Старый экспорт не заменяет действующее разрешение.

Зафиксируйте предложение #

{
  "proposal_id": "PROP-042",
  "proposal_revision": 1,
  "requirement_base_version": 1,
  "runbook_base_version": 1,
  "policy_version": 1,
  "from_days": 7,
  "to_days": 30,
  "status": "awaiting-owner-review",
  "publication_order": ["requirement", "implementation", "runbook", "delivery"]
}

Замените условные версии страниц на фактически зафиксированные. Приложите фиксированный JSON и предлагаемый текст к Jira. Каждый владелец регистрирует роль, решение, редакцию предложения, версии источников и время проверки. Любая существенная правка возвращает пакет на этап Review.

Команда продукта проверяет намерение и область действия. Операционная команда проверяет очистку данных и восстановление. Сопровождающий проверяет diff. Реакции на изменяемые сообщения чата не являются одобрением конкретной редакции.

Опубликуйте и прочитайте результат #

1. Переведите Jira в статус Publishing, когда публикатор подтвердит обе проверки владельцев и отсутствие изменений в базовых источниках.
2. Опубликуйте REQ-17 со сроком тридцать дней и полем о незавершённой доставке. Запишите итоговую версию, область действия и исключения.
3. Откройте PR реализации в GitHub со ссылкой на одобренную версию страницы. Измените конфигурацию на тридцать дней и приложите неавторитетный снимок требования.
4. Выполните слияние после проверки репозитория и повторно прочитайте main. Запишите поведение в коммите отдельно от поведения во время выполнения.
5. Опубликуйте RUN-04, повторно прочитайте его по ID и запишите полученную версию. Публикатор обновляет ссылки на доставку в требовании.
6. Завершите Jira, только когда все записи совпадают и приложены доказательства последнего чтения результата.

Используйте локальный валидатор только для проверки согласованности снимков. Скопируйте требование Confluence до изменения в базовую JSON-схему лаборатории, зафиксируйте его и измените кандидат на тридцать дней. Повышайте локальную редакцию снимка, а фактические версии Confluence сохраняйте отдельно в Jira. Сценарий с GitHub в качестве исходной базы не проверяет актуальный Confluence. Не представляйте зелёный статус как подтверждение внешнего источника.

В этом упражнении не разворачивайте удаление данных. Реальному сервису нужны доказательства развертывания, контролируемые тестовые данные, механизм приостановки и тесты границ во время выполнения. Слияние подтверждает состояние репозитория, а не поведение хранения данных в рабочей среде.

Отслеживайте частичную публикацию #

Запишите результат каждого шага до следующей попытки. PROP-042 связывает события в отдельных системах. Одна завершённая строка не означает, что вся работа окончена.

Пример сбоя: Confluence публикует срок в тридцать дней, но GitHub отклоняет слияние. Оставьте Jira в статусе Blocked, а требование отметьте как ожидающее доставки. Команда продукта выбирает завершение публикации или проверенное восстановление срока в семь дней. Не превращайте аварийную копию README в источник требований.

Обрабатывайте одновременные изменения #

Базовый процесс в браузере: назначьте одного публикатора на время пилотного окна. Откройте историю страницы непосредственно перед редактированием и после публикации. Если другой автор изменил источник, остановитесь, сравните и согласуйте изменения, затем запросите новое одобрение. Последовательная публикация — это процедура, а не гарантия атомарной транзакции.

Расширение API: документация Confluence v2 описывает GET /wiki/api/v2/pages/{id}?body-format=storage и PUT /wiki/api/v2/pages/{id} с объектом версии. Проверенная интеграция публикации сравнивает текущую версию с одобренной базовой, отправляет следующую версию и повторно читает результат. Не обновляйте автоматически неудачную версию, чтобы повторить запись со старым содержимым.

Успех API сам по себе недостаточен. Проверьте итоговое содержимое, ID источника, область действия и версию. В этом курсе нет API-клиента с правом записи. Публикация через браузер человеком — исполнимый базовый процесс для тех, кто не программирует.

Проверьте отрицательные сценарии #

Записывайте фактические результаты в песочнице с ролью исполнителя и редакциями до и после. Не включайте защищённое содержимое страниц в доказательства для пользователя, которому отказали в доступе. Ожидаемые результаты не являются измеренными.

Соберите пакет для проверки #

Зафиксируйте содержимое, а не только метку предложения. PROP-042 появляется в каждой системе, но метка не указывает, какой текст рассмотрел владелец. Включите точную формулировку требования, diff реализации, текст runbook, версии источников и последовательность публикации в один фиксированный пакет.

Package: PROP-042 revision 1, illustrative
Intent: synthetic export retention changes from 7 to 30 days
Exclusions: production data, backups, legal holds
Requirement amendment: fixed proposed REQ-17 wording
Implementation: fixed candidate diff and protected base reference
Runbook amendment: fixed RUN-04 wording and recovery limits
Review: product and operations decisions for this package
Delivery: requirement -> implementation -> runbook -> closure
Stop: changed source, missing review, denied write, failed read-back

Сделайте пакет понятным обоим владельцам. Команде продукта нужны намерение и исключения. Операционной команде нужны изменение процесса и границы восстановления. Обе стороны должны понимать период, когда одобренное намерение отличается от доставленной конфигурации. Одного diff кода недостаточно владельцу, который не знаком с файлами репозитория.

Заполненное содержимое пакета для этого синтетического примера:

REQ-17 proposed v5: "Synthetic export files are retained for 30 days from creation. This pilot excludes production data, backups, and legal holds. Delivery remains pending until the GitHub configuration and RUN-04 read-backs match this approved wording."

GitHub config.json, proposed change against base-001:
-  "retention_days": 7
+  "retention_days": 30

RUN-04 proposed v3: "Retention days: 30. Synthetic exports only. No deletion job runs in this lab. If publication fails, keep delivery pending, read back each source, and obtain owner approval before restoring the seven-day configuration or completing the thirty-day publication."

Эти строки — пример текста предложения, а не записи реального тенанта. Перед проверкой приложите фактический базовый коммит и версии страниц. Фиксированный пакет должен содержать полные предлагаемые тексты, а не краткое изложение, по которому владельцу придётся восстанавливать детали.

Отделяйте офлайн-снимок от публикации в реальной среде. Проверка согласованности показывает совпадение зафиксированных записей. Непосредственно перед первой записью публикатор повторно проверяет сопоставленные страницы, а сопровождающий — защищённую базу. Если что-то изменилось, старый пакет останавливается на этапе Review.

Пройдите по журналу #

Примерная последовательность состояний: в таблице указаны учебные версии, а не наблюдения. После каждой записи в песочнице укажите фактические итоговые версии и коммиты.

Ожидающая доставка — значимое состояние. Оно не позволяет назвать старую реализацию соответствующей новому намерению, пока публикация не завершена. В этот период читателям нужны оба значения, а не краткое утверждение «срок хранения — тридцать дней».

Добавляйте неудачные попытки отдельными событиями. Если запись runbook не удалась, сохраните успешные результаты для требования и конфигурации. Запишите попытку обновления runbook, ошибку, неизменившуюся версию, назначенную роль и следующее действие. Не возвращайте завершённые строки в Pending и не удаляйте наблюдаемую последовательность.

Пример отказа из-за устаревшей версии: публикатор читает REQ-17 v4, другой авторизованный редактор публикует v5, после чего публикатор пытается применить PROP-042 r1 к v4. Платформа сообщает о конфликте версии или проверка перед записью обнаруживает v5. Запишите исполнителя publisher, исходную v4, попытку PROP-042 r1, обнаруженный конфликт или изменившуюся текущую версию, итоговую v5, не изменённую этой попыткой, и назначенного владельца product owner. Оставьте Jira в Review. Повторно прочитайте v5, согласуйте формулировку и запросите проверку нового фиксированного пакета до следующей записи. В реальном тесте используйте фактический ответ платформы и историю страницы. Эта строка — учебный пример.

Завершённый учебный пример, только синтетические значения:

Указанные метки приведены для примера и не являются данными тенанта. В журнале нужны ссылки на исходные версии страниц и ID коммитов. Перед переводом Jira в Done приложите зафиксированное предложение, проверки обеих ролей, запись об исходных версиях, результаты каждого чтения опубликованного содержимого, результат отрицательного теста и оставшиеся ограничения среды выполнения. Если чего-то не хватает, оставьте доставку открытой или установите Blocked.

Контроль пакета: отметьте каждый из пяти пунктов как Supported или Blocked: версии источников актуальны, оба владельца одобрили одну фиксированную редакцию, все необходимые публикации совпадают с результатами чтения, ограничения среды выполнения остаются явными, а состояние восстановления согласовано. Для Done нужны пять отметок Supported и ни одной несанкционированной записи.

Обработайте запись с неизвестным результатом #

После тайм-аута результат неизвестен. Он не доказывает ни успех, ни неудачу. В базовом процессе через браузер снова откройте сопоставленный источник и проверьте его текущее содержимое и историю, прежде чем решать, повторять ли попытку.

1. Приостановите следующий шаг: оставьте доставку незавершённой.
2. Прочитайте целевой объект: сравните текущий текст, версию и область действия с фиксированным пакетом.
3. Запишите наблюдение: завершено, без изменений, конфликт или недоступно.
4. Выберите следующее действие: продолжите после проверенного завершения, повторите разрешённый шаг без изменений или передайте конфликт на эскалацию.
5. Сохраните неопределённость: оставьте неудачную или неизвестную попытку рядом с последующим чтением результата.

Не запускайте всю последовательность повторно вслепую. Повтор уже выполненного шага создаёт дополнительные версии и может перезаписать посторонние изменения. Возобновляйте работу с проверенного состояния. Если источник недоступен, выберите Hold, а не делайте предположения по старому журналу.

Сравните решения по восстановлению #

Принимайте решение по текущему состоянию и решению владельца. Для продолжения нужны актуальные одобрения и рабочие средства контроля. Компенсация требует проверки восстановления с учётом промежуточных изменений. Восстановительная запись — это ещё одна публикация, а не привилегированное исключение из процесса.

Проверьте завершение публикации #

Подготовьте пакет, который независимый проверяющий сможет сверить. В нём должны быть точное проверенное предложение, исходные версии, проверки обеих ролей, результат каждой записи, итоговые значения и оставшиеся ограничения среды выполнения. Попросите указать первый незавершённый шаг после остановки.

Ожидаемое рассуждение: следующий шаг определяется текущими источниками и журналом, а не уверенностью предыдущего ассистента. Добавьте итоговые сопоставленные ссылки в тесты поиска, где система должна сохранить то же различие между авторитетными источниками.

Устранение неполадок и восстановление #

Версия изменилась: сравните историю и запросите повторную проверку. Снимок согласован, но wiki отличается: снова получите актуальные источники Confluence. Jira закрыли слишком рано: переоткройте задачу разрешённым способом и запишите пропущенные шаги.

Восстановление: сравните историю страниц и выполните восстановление или компенсирующее изменение, одобренное владельцем. Запишите итоговую версию и не предполагайте, что восстановление сбросит нумерацию. Если Product выберет откат, верните конфигурацию через защищённый PR. Гарантия отката не распространяется на удалённые файлы.

Упражнение и самопроверка #

Прервитесь после публикации REQ-17 и передайте другому публикатору только карту и журнал.

Ожидаемое рассуждение: публикатор получает текущие источники, подтверждает фиксированное одобрение и продолжает только разрешённый незавершённый шаг. При отсутствии доказательств работа возвращается к Review.

Основные источники #

• История и восстановление: техническая документация Confluence .
• Версионируемые операции API: страницы Confluence REST API v2 .
• Контроль рабочих процессов: расширенные рабочие процессы Jira .
• Безопасность интеграции: рекомендации по безопасности MCP .

Следующие шаги #

После проверенного цикла публикации переходите к поиску по карте .