Devops | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 проходит с 11 по 15 мая 2026 года в Barbican Centre в Лондоне. Основная 3-дневная конференция — со вторника по четверг, с опциональными однодневными воркшопами в понедельник и пятницу.

С 78 сессиями и 14 воркшопами это одна из самых насыщенных конференций для разработчиков в Европе.

Темы

Архитектурное мышление
Функциональный код на C# 13
Serverless-дизайн
Семантический ИИ
Azure Kubernetes Services
Lean DevOps стратегии
Протокол контекста модели (MCP)
Агентный ИИ в .NET
Рефакторинг монолита
Быстрее программировать с LLM
Криптография в постквантовом мире
Local-First разработка

Спикеры

Программу мирового класса представляют Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm и Raju Gandhi.

Билеты и информация

98% участников SDD 2025 оценили общее впечатление как хорошее, очень хорошее или отличное.

Обновления Azure Developer CLI (azd) за апрель 2026

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

Этот пост был переведён автоматически. Для оригинальной версии нажмите здесь.

Azure Developer CLI (azd) выпустил пять релизов в апреле 2026 года (с 1.23.14 по 1.24.2). Главная тема — хуки, которые теперь работают на Python, JavaScript, TypeScript и .NET, а не только на Bash и PowerShell.

Многоязычные хуки в azure.yaml

Хуки теперь могут указывать на файлы .py, .js, .ts или .cs в дополнение к shell-скриптам. Для каждого языка выполняется автоматическое разрешение зависимостей:

Python — обнаруживает requirements.txt или pyproject.toml, создаёт virtualenv и устанавливает зависимости перед запуском. Имя окружения настраивается через virtualEnvName.
JavaScript / TypeScript — обнаруживает package.json и автоматически запускает npm install. TypeScript выполняется через npx tsx без шага компиляции. Менеджер пакетов выбирается в блоке конфигурации packageManager.
.NET — запускает файлы .cs с помощью dotnet run. Однофайловые скрипты поддерживаются на .NET 10+. Целевой фреймворк настраивается через блок configuration/framework.

Это означает, что команды, уже работающие на одном из этих языков, больше не нуждаются в отдельном хуке на Bash или PowerShell только для подключения к событиям жизненного цикла провизионинга.

azd update переходит в публичную предварительную версию

azd update теперь доступен в публичной предварительной версии на всех платформах. Одна команда обновляет azd независимо от способа его первоначальной установки — больше не нужно отслеживать пути Homebrew, WinGet или MSI по отдельности.

Неинтерактивный режим через AZD_NON_INTERACTIVE

Установка AZD_NON_INTERACTIVE=true (или использование --non-interactive / --no-prompt) теперь вызывает последовательные, детерминированные ошибки в пайплайнах CI/CD, когда необходимый ввод не может быть разрешён автоматически. Ранее поведение было непоследовательным для разных команд.

Предварительная проверка квоты моделей ИИ

azd provision проверяет квоту Azure Cognitive Services перед попыткой выделить ресурсы моделей ИИ. Развёртывания, которые завершились бы ошибкой из-за превышения лимитов квоты, теперь показывают ошибку в начале процесса, а не в середине провизионинга.

«Исправить эту ошибку» в устранении неполадок Copilot

Интеграция устранения неполадок Copilot в azd получает возможность напрямую применять предложенное исправление — не только описывать его. Когда агент выявляет исправимую проблему, он может внести изменение на месте.

Пользовательские провайдеры провизионинга и резолвер секретов Key Vault

Авторы расширений теперь могут регистрировать альтернативные инфраструктурные бэкенды с помощью WithProvisioningProvider(). Кроме того, azd автоматически разрешает ссылки @Microsoft.KeyVault(...) перед передачей конфигурации расширениям, устраняя необходимость ручного разрешения секретов в пользовательских провайдерах.

Исключения для шаблонов и режима наблюдения

Два новых файла ignore обеспечивают более точный контроль над обработкой файлов:

.azdignore — исключает файлы только для контрибьюторов (документация, конфигурации CI) из копий шаблонов, чтобы конечные пользователи получали чистый каркас проекта.
.azdxignore — исключает директории из триггера пересборок во время azd x watch, снижая шум при итеративной разработке.

Предварительная проверка зарезервированных имён и опция docker.network

azd теперь предупреждает, когда прогнозируемые имена ресурсов будут содержать зарезервированные слова Azure (MICROSOFT, WINDOWS или префикс LOGIN), до начала провизионинга. Новая опция docker.network передаёт --network в docker build, что полезно в корпоративных прокси-средах, требующих определённой сети Docker.

Исправления безопасности

Пакет Windows MSI теперь включает проверку подписи кода. Отдельное исправление устраняет утечку переменных окружения, которая могла раскрывать значения через границы команд расширений.

Насыщенный месяц — поддержка многоязычных хуков, в частности, устраняет реальную точку трения для команд, не работающих преимущественно на Bash. Полный журнал изменений по всем пяти релизам смотрите в полных примечаниях к выпуску.

Azure DevOps Server Патч Апрель 2026 — Исправление Завершения PR и Обновления Безопасности

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальная версия доступна здесь.

Быстрое уведомление для команд, использующих самостоятельно размещённый Azure DevOps Server: Microsoft выпустила Патч 3 за апрель 2026 с тремя целевыми исправлениями.

Что исправлено

Сбои завершения pull request — исключение нулевой ссылки при автоматическом завершении рабочих элементов могло приводить к сбою слияния PR. Если вы сталкивались с случайными ошибками завершения PR, вероятно, это была причина
Валидация перенаправления при выходе — улучшена валидация при выходе из системы для предотвращения потенциально вредоносных перенаправлений. Это исправление безопасности, которое стоит применить как можно скорее
PAT-подключения к GitHub Enterprise Server — создание подключений с помощью Personal Access Token к GitHub Enterprise Server было сломано, теперь восстановлено

Как обновить

Скачайте Патч 3 и запустите установщик. Чтобы проверить, что патч применён:

<patch-installer>.exe CheckInstall

Если вы используете Azure DevOps Server на собственных серверах, Microsoft настоятельно рекомендует поддерживать актуальную версию патчей как для безопасности, так и для надёжности. Ознакомьтесь с примечаниями к выпуску для получения полной информации.

Агентная платформенная инженерия становится реальностью — Git-APE показывает как

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Платформенная инженерия была одним из тех терминов, которые звучат отлично на конференциях, но обычно означают «мы построили внутренний портал и обёртку для Terraform.» Настоящее обещание — самообслуживающаяся инфраструктура, которая действительно безопасна, управляема и быстра — всегда была в нескольких шагах.

Команда Azure только что опубликовала Часть 2 серии об агентной платформенной инженерии, и эта часть целиком о практической реализации. Они называют это Git-APE (да, акроним намеренный), и это open-source проект, который использует агенты GitHub Copilot плюс серверы Azure MCP для превращения запросов на естественном языке в валидированную и развёрнутую инфраструктуру.

Что Git-APE делает на самом деле

Основная идея: вместо того чтобы разработчики изучали модули Terraform, навигировали по UI порталов или создавали тикеты для платформенной команды, они разговаривают с агентом Copilot. Агент интерпретирует намерение, генерирует Infrastructure-as-Code, валидирует его по политикам и разворачивает — всё внутри VS Code.

Вот настройка:

git clone https://github.com/Azure/git-ape
cd git-ape

Откройте workspace в VS Code, и файлы конфигурации агента автоматически обнаруживаются GitHub Copilot. Вы взаимодействуете с агентом напрямую:

@git-ape deploy a function app with storage in West Europe

Агент использует Azure MCP Server под капотом для взаимодействия с сервисами Azure. Конфигурация MCP в настройках VS Code активирует конкретные возможности:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Почему это важно

Для тех из нас, кто строит на Azure, это смещает разговор о платформенной инженерии с «как построить портал» на «как описать наши ограничения как API.» Когда интерфейс вашей платформы — это ИИ-агент, качество ваших ограничений и политик становится продуктом.

Блог Части 1 изложил теорию: хорошо описанные API, схемы контроля и явные ограничения делают платформы agent-ready. Часть 2 доказывает, что это работает, поставляя реальные инструменты. Агент не генерирует ресурсы вслепую — он валидирует по лучшим практикам, соблюдает соглашения об именовании и применяет политики вашей организации.

Очистка так же проста:

@git-ape destroy my-resource-group

Моё мнение

Буду честен — здесь больше о паттерне, чем о конкретном инструменте. Git-APE сам по себе — это демо/референсная архитектура. Но лежащая в основе идея — агенты как интерфейс к вашей платформе, MCP как протокол, GitHub Copilot как хост — вот куда движется experience корпоративного разработчика.

Если вы — платформенная команда, которая ищет, как сделать внутренние инструменты agent-friendly, лучшего стартового пункта не найти. А если вы .NET-разработчик и думаете, как это связано с вашим миром: Azure MCP Server и агенты GitHub Copilot работают с любыми нагрузками Azure. Ваш ASP.NET Core API, ваш стек .NET Aspire, ваши контейнеризированные микросервисы — всё это может быть целью агентного потока деплоя.

Подведём итоги

Git-APE — это ранний, но конкретный взгляд на агентную платформенную инженерию на практике. Клонируйте репозиторий, попробуйте демо и начните думать о том, как API и политики вашей платформы должны выглядеть, чтобы агент мог безопасно их использовать.

Читайте полный пост для walkthrough и видео-демонстраций.

Azure DevOps наконец-то исправил Markdown-редактор, на который все жаловались

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальную версию можно найти здесь.

Если вы используете Azure Boards, вы наверняка сталкивались с этим: читаете описание рабочего элемента, может проверяете критерии приёмки, и случайно делаете двойной клик. Бум — вы в режиме редактирования. Вы ничего не хотели редактировать. Просто читали.

Dan Hellem объявил об исправлении, и это одно из тех изменений, которые звучат мелко, но реально убирают трение из повседневного рабочего процесса.

Что изменилось

Markdown-редактор для текстовых полей рабочих элементов теперь открывается в режиме просмотра по умолчанию. Можно читать контент и взаимодействовать с ним — переходить по ссылкам, проверять форматирование — не беспокоясь о случайном входе в режим редактирования.

Когда действительно хотите редактировать, нажмите на иконку редактирования вверху поля. Закончили — явно вернитесь в режим просмотра. Просто, намеренно, предсказуемо.

Почему это важнее, чем кажется

Тред обратной связи от сообщества был длинным. Поведение двойного клика для редактирования было введено с Markdown-редактором в июле 2025, и жалобы начались почти сразу.

Для команд, которые делают планирование спринтов, уточнение бэклога или код-ревью в Azure Boards, такое микро-трение накапливается.

Статус развёртывания

Уже раскатывается для части пользователей и расширится на всех в ближайшие две-три недели.

Подведём итоги

Не каждое улучшение должно быть заголовочной фичей. Иногда лучшее обновление — просто убрать что-то раздражающее. Это именно такой случай — маленький UX-фикс, который делает Azure Boards менее враждебным для людей, которые просто хотят спокойно прочитать свои рабочие элементы.

Azure DevOps MCP Server появился в Microsoft Foundry: что это значит для ваших ИИ-агентов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) переживает свой момент. Если вы следите за экосистемой ИИ-агентов, вы наверняка заметили, что MCP-серверы появляются повсюду — давая агентам возможность взаимодействовать с внешними инструментами и сервисами через стандартизированный протокол.

Теперь Azure DevOps MCP Server доступен в Microsoft Foundry, и это одна из тех интеграций, которая заставляет задуматься о практических возможностях.

Что здесь на самом деле происходит

Microsoft уже выпустила Azure DevOps MCP Server в публичном превью — это сам MCP-сервер. Новое — это интеграция с Foundry. Теперь вы можете добавить Azure DevOps MCP Server к своим агентам в Foundry прямо из каталога инструментов.

Для тех, кто ещё не знаком с Foundry: это унифицированная платформа Microsoft для создания и управления ИИ-приложениями и агентами в масштабе. Доступ к моделям, оркестрация, оценка, развёртывание — всё в одном месте.

Настройка

Настройка удивительно проста:

В вашем агенте Foundry перейдите в Add Tools > Catalog
Найдите “Azure DevOps”
Выберите Azure DevOps MCP Server (preview) и нажмите Create
Введите имя вашей организации и подключитесь

Вот и всё. Ваш агент теперь имеет доступ к инструментам Azure DevOps.

Контроль доступа агента

Вот что мне нравится: вы не ограничены подходом «всё или ничего». Вы можете указать, какие инструменты доступны вашему агенту. Если вы хотите, чтобы он только читал work items, но не трогал пайплайны, это можно настроить. Принцип наименьших привилегий, применённый к вашим ИИ-агентам.

Это важно для корпоративных сценариев, где вы не хотите, чтобы агент случайно запустил пайплайн развёртывания, потому что кто-то попросил его «помочь с релизом».

Почему это интересно для .NET-команд

Подумайте о том, что это позволяет на практике:

Помощники планирования спринтов — агенты, которые могут извлекать work items, анализировать данные о скорости работы и предлагать ёмкость спринта
Боты для код-ревью — агенты, которые понимают контекст вашего PR, потому что могут реально читать ваши репозитории и связанные work items
Реагирование на инциденты — агенты, которые могут создавать work items, запрашивать последние развёртывания и сопоставлять баги с недавними изменениями
Онбординг разработчиков — “Над чем мне работать?” получает реальный ответ, основанный на фактических данных проекта

Для .NET-команд, уже использующих Azure DevOps для CI/CD-пайплайнов и управления проектами, наличие ИИ-агента, который может напрямую взаимодействовать с этими системами, — это значительный шаг к полезной автоматизации (а не просто чат-бот как сервис).

Более широкая картина MCP

Это часть более крупного тренда: MCP-серверы становятся стандартным способом взаимодействия ИИ-агентов с внешним миром. Мы видим их для GitHub, Azure DevOps, баз данных, SaaS API — и Foundry становится хабом, где все эти соединения объединяются.

Если вы создаёте агентов в экосистеме .NET, на MCP стоит обратить внимание. Протокол стандартизирован, инструментарий развивается, а интеграция с Foundry делает его доступным без необходимости вручную настраивать серверные подключения.

Итог

Azure DevOps MCP Server в Foundry находится в превью, так что ожидайте его развития. Но основной рабочий процесс надёжен: подключите, настройте доступ к инструментам и позвольте вашим агентам работать с данными DevOps. Если вы уже в экосистеме Foundry, это в нескольких кликах. Попробуйте и посмотрите, какие рабочие процессы вы сможете построить.

Ознакомьтесь с полным анонсом для пошаговых инструкций по настройке и дополнительных деталей.