Оригинальный источник: Azure Developer CLI (azd) – May and June 2026
Девять релизов за два месяца могут выглядеть шумно, но у этой партии azd есть чёткая сквозная линия: убрать хрупкие края, которые подводят команды в CI и многосервисных развёртываниях.
Главная функция для меня — не просто инструмент azd. Это продуктовое решение относиться к предварительным требованиям (prerequisites) как к полноценному состоянию рабочего процесса. На практике многие неудачные облачные развёртывания — не архитектурные провалы. Это несогласованные локальные и CI-окружения. Когда CLI может обнаруживать, устанавливать и проверять необходимые инструменты прямо в потоке, команды устраняют один из самых трудоёмких источников отказов.
Вторая крупная победа — azd exec. Это важно, потому что скрипты развёртывания часто расходятся с контекстом окружения, особенно при разрешении секретов и распространении переменных. Кросс-платформенный раннер, наследующий полное окружение azd, снижает этот разброс и делает скрипты более достоверными.
Особого внимания заслуживают исправления, связанные с параллелизмом. Кросс-сервисное загрязнение образов при параллельных развёртываниях Container Apps — именно тот дефект, который разрушает доверие к автоматизации. Нельзя проповедовать платформенную инженерию, пока ваш пайплайн время от времени доставляет не тот образ не в тот сервис. То, что эта волна релизов устранила эти состояния гонки, важнее большинства новых функций.
Мои практические рекомендации для платформенных команд:
Внедрите azd tool check как обязательную предварительную проверку в CI.
Проверьте любые кастомные парсеры или regex-проверки, привязанные к старому выводу azd up, потому что унифицированная модель прогресса — это ломающее изменение поведения.
Включите и протестируйте фильтрацию по подпискам для мультитенантных организаций уже сейчас, до следующего масштабного развёртывания окружения.
Проведите контролируемый стресс-тест параллельного развёртывания, если вы используете удалённые сборки с Container Apps.
Мне также нравится сдвиг в сторону предупреждений предварительной проверки, требующих действий, и машиночитаемых идентификаторов развёртывания. Это мост от удобного для разработчика UX к операционной наблюдаемости промышленного уровня.
Моё оценочное мнение: azd взрослеет из лаунчера шаблонов в субстрат доставки. Это хорошо, но накладывает на команды ответственность: перестать относиться к обновлениям azd как к опциональной уборке. Учитывая количество исправлений безопасности и надёжности в этих заметках, отставание больше не нейтрально. Это активное принятие риска.
Если ваша команда использует azd в производственных путях, правильная политика проста: осознанно фиксируйте версии, быстро тестируйте обновления и двигайтесь вперёд. Скорость этого цикла релизов показывает, куда движется облачный инструментарий. Инструменты, которые не укрепляются сами под давлением параллелизма и масштаба, будут заброшены.
Эта череда релизов доказывает, что azd пытается стать инструментом, который выдерживает реальное корпоративное давление.
