blabs, однозначного ответа, скорее всего нет. Я бы предположил, что документация должна идти к коду при разработке и от кода - при поддержке. Т.е. в конечном итоге сначала у вас есть ТЗ на которое ссылается Confluence (оставаясь точкой отправления), а потом у вас есть код с должным набором комментариев и документов в самой кодовой базе, на которые Confluence ссылается как на результат работы, а код ссылается на некоторые паблики (например, статьи дополнительных описаний).
Автоматизировать в этом месте можно до потери пульса. Тут главное не стараться ради стараний. Поэтому, если бы я выбирал, то
остался с Документами Гугл на уровне вводного описания и абстракции.
Пример проблемной автоматизации. Вот эта страница
https://oshliaer.github.io/qna?target=labs/apps-sc... генерируется из Документа Гугл. И все бы ничего, но только вначале это был небольшой скрипт на 5 строк в Apps Script, а теперь это приложение на Go, которое еще и контрибьютить иногда хочется. Как вообще такое получилось!? я уже сказать не могу, но то, что это были большие переоцененные надежды на Документы Гугл - факт. Т.е. вы рискуете нарваться на автоматизацию того, что вам вообще не нужно.
Я бы Jire ничего не предпочел, но добавил бы документацию REST в OpenAPI с предложениями на изменения через git с реверс ссылками на паблик, генерируемый в Confluence. Плюс такого подхода в полнейшей и тотальной уже готовой автоматизации (подкрутить пару Docker конфигов) вплоть до тестов, проверки типов и кросс-ссылок. Обратите внимание, что ссылки должны иметь общий характер. Или же необходимо просто встроить файлы репозитория в нужный контекст статьи.
Применимо ли это к вашим задачам миграции - это отдельный вопрос. Возможно, там какие-то невероятные многоходовки, которые просто невозможно указать в комментариях в коде OpenAPI. Тогда тут нужен более системный подход. Возможно, хранение и связывание большого количества параметров через Гугл Таблицы (используя их как первоисточник) будет как-то оправдано.
Простой
