Как это работает / 05 из 05
Понимать границы — значит управлять переносом
План помогает увидеть изменения заранее. Но он не заменяет резервную копию, проверку доработки и понимание того, что произойдёт при ошибке.
Кто за что отвечает
Три точки контроля
Вы задаёте границы
Решаете, что переносить и в какую базу.
- Выбрать объекты
- Проверить план
- Сделать резервную копию
Holkas выполняет команды
Учитывает выбор и зависимости, фиксирует результаты.
- Порядок команд
- Учёт исключений
- Журнал выполнения
Вы проверяете результат
Журнал показывает исход команд. Работу доработки проверяют в Парусе.
- Посмотреть ошибки
- Проверить приложение
- При необходимости повторить сравнение
Перед важным переносом проверьте состав и план, сделайте резервную копию приёмника. После — проверьте журнал и работу доработки.
Состав переноса не расширяется сам
Holkas не добавляет новые объекты только потому, что они похожи на выбранные или оказались их зависимостями. О недостающих известных зависимостях он предупреждает; решение о добавлении остаётся за вами.
Объекты вне выбранного набора не удаляются из-за отсутствия в источнике. Но внутри выбранного объекта возможны удаления частей — если их разрешают правила типа. Поэтому команды Delete требуют такого же внимания, как другие изменения структуры.
Просмотренный план и изменившаяся база
Пока вы изучаете план, приёмник может измениться. При запуске всего плана без исключений новые необходимые команды могут выполниться с пометкой «вне плана» в журнале.
При запуске части плана или плана с исключениями появление команд сверх сохранённого плана останавливает применение до первой записи. Нужно построить новый план. Подробнее — как устроено сравнение.
Ошибка не откатывает весь перенос
Если в состав входит пользовательский скрипт, он выполняет свой SQL-код при каждом применении. Такой код может менять и удалять рабочие данные; обычные ограничения Delete для объектов не ограничивают содержимое скрипта.
При обычном отказе команды Holkas отмечает ошибку, пропускает оставшиеся команды этого объекта и продолжает работу с другими объектами. Операция в целом завершается неуспехом, но успешно выполненные изменения уже могут находиться в приёмнике.
Потеря соединения или другой инфраструктурный сбой может оборвать весь запуск. Общего автоматического отката всех изменений нет. Сначала разберите журнал, затем решайте, нужно ли исправить причину и повторить сравнение либо восстановить базу из копии.
Отдельно отмечаются известные отказы Паруса, которые повторный запуск не исправит, — например, запрет менять запись стандартной технологии. Такие команды получают особый исход; сами по себе они не делают всю операцию неуспешной. Их тоже нужно просмотреть в журнале.
ИИ-агент тоже действует от имени человека
При работе через MCP применение к базе требует подтверждения человека. Журнал сохраняет, какой агент действовал и от чьего имени. Автоматизация не отменяет ответственности за выбранный приёмник и состав переноса.
Три проверки для важной базы
- До запуска: убедитесь, что выбрана нужная база, изучите команды и подготовьте резервную копию.
- После запуска: проверьте журнал, включая ошибки, пропуски и команды «вне плана».
- В приложении: проверьте, что перенесённая доработка выполняет свою задачу.
Готовы попробовать? Начните с переноса доработки с тестовой базы на рабочую.