Новости и разборы
Одобрение изменения: версия, конфликт и сохранённое решение
Pulumi ESC допускает параллельные запросы, Durable Task разбирает длительное ожидание. Что это меняет в согласовании инфраструктуры.
Две команды меняют одно окружение: первая обновляет параметр подключения, вторая готовит новую функцию. Пока владелец согласует оба запроса, исходная конфигурация уже успела измениться. Если процесс хранит только сообщение «одобрено», непонятно, к какой версии оно относится. Октябрьские публикации Pulumi и Microsoft рассматривают разные стороны этой ситуации.
Одновременно открытые запросы требуют сравнения версий
Pulumi 7 октября добавил параллельные change requests в ESC. После изменения базовой ревизии черновик можно обновить через трёхстороннее слияние; конфликт показывается для ручного разрешения. Функция относится к окружениям с approvals в редакциях Pro и Enterprise.
Для владельца системы здесь важен не только выигрыш от параллельной работы. Изменение, которое проверяли вчера, может сегодня опираться на другую основу. Следовательно, согласование должно сохранять идентичность предложения и показывать, что изменилось после проверки. Если команды затронули один параметр, автоматическое продолжение без понятного решения может скрыть смысловой конфликт.
Ожидание человека должно переживать остановку процесса
Microsoft 12 октября разобрал практические сценарии Durable Task, включая согласование и подготовку окружения. Durable execution помогает сохранять ход ожидания, но права согласующего, окончательное решение и результат внешнего действия остаются ответственностью приложения. Примеры в статье иллюстрируют архитектуру, а не составляют полностью проверенный готовый проект.
Связь двух материалов даёт условный проектный вывод: процессу нужны и версия изменения, и сохранённое решение по этой версии. Одна лишь история выполнения не гарантирует, что внешнее действие произойдёт ровно один раз. А механизм сравнения конфигураций не определяет, кто имеет право одобрять изменение.
Проверить путь от запроса до применения
На тестовом окружении создайте два предложения с общей базой. Примените одно, затем откройте второе и проверьте, видит ли согласующий новую основу. Для конфликтующего параметра заранее определите, кто принимает решение и требует ли исправленный вариант повторной проверки.
Отдельно остановите исполнитель во время ожидания одобрения. После запуска система должна восстановить запрос, его срок и сохранённое решение. Проверьте случай, когда одобрение записано, а уведомление о нём задержалось. Важнее авторитетная запись решения, а не момент доставки сообщения.
Итог приёмки стоит сформулировать предметно: можно установить автора, проверенную версию, решение и фактический результат применения. Не обязательно добавлять новый runtime, если существующий процесс уже обеспечивает эти свойства.
Фоновые задачи и повторы раскрывают соседнюю границу ответственности. В архивном инфраструктурном описании перечислены задачи эксплуатации без подтверждения всех запущенных компонентов. Для сопровождения инфраструктуры обсудите, какие изменения сейчас требуют согласования и где теряется их состояние.