Применимость: Data Center. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Что именно нужно версионировать
В большой Jira скрипт может использоваться одновременно в listener, workflow и scheduled job. Сохранение файла в Git полезно, но недостаточно: нужно знать, какая версия подключена к какой конфигурации, с какими параметрами и от чьего имени выполняется. Начните с инвентаризации одного критичного сценария. Запишите путь скрипта, назначение, вызывающие конфигурации, зависимые поля, проекты и владельца. Такой список выявляет повторное использование, которое иначе становится неожиданностью при выпуске.
Не переносите в репозиторий секреты, дампы пользовательских данных и реальные токены. Параметры окружения отделите от логики и храните через согласованный механизм конфигурации. Идентификатор поля тоже является параметром среды: на тестовом экземпляре он может отличаться от production. Прямое копирование файла без проверки соответствий приводит к технически успешному изменению другого поля.
Маленькая ветка и понятный review
Создавайте отдельную ветку под конкретное изменение поведения. В описании PR укажите исходный сценарий, новое поведение, проверенные случаи и способ отката. Для listener важно показать, какие события обрабатываются и какие поля изменяются; для job — область выборки и повторный запуск; для workflow — момент проверки и сообщение пользователю. Ревью должно оценивать бизнес-результат, а не только синтаксис Groovy.
Избегайте одновременного большого форматирования и изменения логики: это затрудняет поиск существенной разницы. Если общий скрипт используется несколькими конфигурациями, перечислите их явно и проверьте каждую. Изменение функции с тем же именем может нарушить другого потребителя, даже когда основной сценарий проходит тест. Для рискованного изменения разумно сначала ввести новую версию функции и затем адресно переключить конфигурации.
Тестовая среда и данные
Разворачивайте на тестовой среде именно проверяемую версию из Git и зафиксируйте её идентификатор. Подготовьте минимальные данные для положительных, отрицательных и повторных сценариев. Копия production без обезличивания не является обязательным условием хорошего теста. Для проверки маршрутизации достаточно ограниченного набора полей, пользователей и связей. Внешние уведомления направляйте в согласованный тестовый канал или заменяйте безопасной заглушкой.
Проверяйте не только возвращаемое значение, но и историю задачи, поиск после изменения и взаимодействие с соседними правилами. Для долгих выборок используйте режим планирования, показывающий предполагаемые изменения. Этот режим должен выполнять тот же отбор и расчёт, что рабочий, иначе он даёт ложную уверенность. Сохраните результаты проверки рядом с PR, чтобы следующий сопровождающий понимал основания выпуска.
Выпуск в production
Определите поддерживаемый способ доставки файлов в Script Roots и учтите топологию Data Center. Не считайте обновление файла на одном узле достаточным без проверки фактического расположения скриптов и политики вашей установки. Доступ на чтение репозитория для доставки предпочтительнее учётной записи с правом изменять код. Сам факт попадания коммита в основную ветку не должен обходить согласованные проверки выпуска.
Зафиксируйте версию файлов и изменения конфигурации в одном выпуске. Сначала ограничьте область действия пилотным проектом или небольшой выборкой. Проверьте первые реальные выполнения, затем расширяйте область по согласованному плану. Если доставка автоматическая, включите проверку результата и возможность остановки. Не оставляйте постоянный процесс обновления, который молча применяет любую новую версию без понимания зависимостей и готовности конфигурации.
Откат кода и данных
Возврат файла к прежнему коммиту восстанавливает логику, но не отменяет уже отправленные письма, созданные задачи и изменения полей. Поэтому план отката содержит две части: остановить новую обработку и оценить побочные результаты. Перед массовой записью сохраняйте ключи задач и прежние значения в согласованном защищённом месте. Это даёт возможность адресного восстановления без слепого повторения истории.
При инциденте отключите вызывающую конфигурацию, верните проверенную версию и восстановите совместимые параметры. Затем проверьте одну контрольную задачу. Данные исправляйте только там, где автоматическое изменение не было уже осознанно заменено человеком. В карточке инцидента запишите точную версию, причину и проверку исправления. Цель Git-процесса — понятная связь между требованием, кодом, конфигурацией и результатом, а не просто наличие папки со скриптами.
Минимальный комплект выпуска
Для каждого выпуска храните идентификатор версии, список изменённых файлов, перечень подключений, параметры среды без секретов и результаты проверки. Добавьте короткую последовательность включения и отключения. Новый сопровождающий должен суметь определить рабочую версию без догадок по времени изменения файла. Если кто-то вынужден сделать срочную правку через интерфейс, верните её в репозиторий и зафиксируйте причину до следующего выпуска. Иначе Git перестанет отражать реальную систему, а формально правильный откат затрёт важное исправление. Регулярно сверяйте конфигурацию с принятой версией, особенно после аварийных работ.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу