Platform Engineering | The .NET Blog

Устранение Рутинной Работы Миграции с Помощью Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — руководство по Git-Ape (инструменту git для агентной инженерии платформ), который мигрирует реальный репозиторий AWS Terraform в Azure, фокусируясь на извлечении намерения вместо построчного преобразования.

Входные данные: contoso-migration

Источником является реальный проект Terraform (contoso-migration), который разворачивает приложение Next.js на AWS — EC2 для вычислений, ALB для балансировки нагрузки, S3 для артефактов и ключи IAM для идентификации. Стоимость: ~34 $/месяц. Цель — не воспроизвести ту же инфраструктуру в Azure; речь идёт о том, чтобы понять, что развёртывание действительно пытается сделать, и воссоздать это с помощью нативных сервисов Azure.

Шаг 1: Валидация и аутентификация

Git-Ape начинает с проверки всех необходимых инструментов CLI — az, aws, gh, jq, git — и подтверждения активных сеансов аутентификации перед тем, как что-либо трогать. Никаких частичных запусков.

Шаг 2: Извлечение намерения

Агент читает весь исходный репозиторий через API GitHub и извлекает намерение развёртывания: среда выполнения (Node.js), тип вычислений, шаблон ingress, обработка артефактов, модель идентификации, сеть и мониторинг. Это ключевой шаг — строится семантическая модель того, что делает развёртывание, а не какие ключевые слова Terraform оно использует.

Шаг 3: Сопоставление сервисов

Сервисы AWS сопоставляются с эквивалентами Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Встроенная балансировка нагрузки App Service
Роли/ключи IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Шаг 4: Агент-критик

Перед генерацией вывода запускается агент-критик, который обнаруживает две блокирующие проблемы:

Антипаттерн сборки при запуске — исходный Terraform запускал npm install && npm run build на EC2 при старте. Исправление: собирать в CI, разворачивать готовый артефакт.
Ненужный Blob Storage — S3 использовался для промежуточного хранения артефактов, что можно устранить при правильном CI/CD. Агент-критик полностью удалил его.

Шаг 5: Сгенерированный вывод

Результатом являются ~80 строк Bicep вместо оригинальных 200+ строк Terraform. Агент создал новый репозиторий GitHub с infra/main.bicep и .github/workflows/deploy.yml и удалил все файлы, специфичные для AWS.

Сравнение уровня безопасности

Миграция также принесла значительное улучшение безопасности:

AWS оригинал	Вывод Azure
Только HTTP	Только HTTPS, TLS 1.2
SSH открыт для 0.0.0.0/0	Нет SSH-экспозиции
Ключи доступа IAM	OIDC + Managed Identity
Нет мониторинга	Application Insights

Стоимость: ~13 $/месяц против первоначальных 34 $/месяц.

Чем это отличается от конвертора синтаксиса

Шаг агента-критика — вот что отличает это от механического перевода. Он обнаружил паттерны, которые работали бы на AWS, но были бы неверны на Azure — и исправил их вместо того, чтобы воспроизводить. Вывод — это не «AWS в синтаксисе Azure»; это нативное для Azure развёртывание, которое достигает той же цели более чисто.

Смотрите полное руководство для полной трассировки агента и сгенерированных файлов.

Агентная платформенная инженерия становится реальностью — 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 и видео-демонстраций.