Migration | 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 развёртывание, которое достигает той же цели более чисто.

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

Оценка модернизации GitHub Copilot — лучший инструмент миграции, который вы ещё не используете

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

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

Миграция устаревшего приложения .NET Framework на современный .NET — одна из тех задач, о которых все знают, что их нужно сделать, но никто не хочет начинать. Это никогда не просто «сменить целевой фреймворк». Это API, которые исчезли, пакеты, которых больше нет, модели хостинга, которые работают совершенно по-другому, и миллион мелких решений о том, что контейнеризировать, что переписать и что оставить как есть.

Джеффри Фриц только что опубликовал глубокий разбор оценки модернизации GitHub Copilot, и честно? Это лучший инструмент миграции для .NET, который я видел. Не из-за генерации кода — это уже стандарт. Из-за документа оценки, который он создаёт.

Это не просто движок предложений кода

Расширение VS Code следует модели Оценить → Спланировать → Выполнить. Фаза оценки анализирует всю кодовую базу и создаёт структурированный документ, фиксирующий всё: что нужно изменить, какие ресурсы Azure предоставить, какую модель развёртывания использовать. Всё последующее — инфраструктура как код, контейнеризация, манифесты развёртывания — вытекает из результатов оценки.

Оценка хранится в .github/modernize/assessment/ вашего проекта. Каждый запуск создаёт независимый отчёт, поэтому вы накапливаете историю и можете отслеживать, как меняется ваша позиция по миграции по мере исправления проблем.

Два способа начать

Рекомендованная оценка — быстрый путь. Выберите из курируемых доменов (Обновление Java/.NET, облачная готовность, безопасность) и получите значимые результаты без настройки конфигурации. Идеально для первого взгляда на состояние вашего приложения.

Пользовательская оценка — прицельный путь. Настройте точно, что анализировать: целевой compute (App Service, AKS, Container Apps), целевую ОС, анализ контейнеризации. Выберите несколько целей Azure для сравнения подходов к миграции бок о бок.

Это представление сравнения действительно полезно. Приложение с 3 обязательными проблемами для App Service может иметь 7 для AKS. Видеть оба варианта помогает принять решение по хостингу до того, как вы привяжетесь к пути миграции.

Разбивка проблем действенна

Каждая проблема сопровождается уровнем критичности:

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

И каждая проблема ссылается на затронутые файлы и номера строк, предоставляет подробное описание того, что не так и почему это важно для вашей целевой платформы, даёт конкретные шаги по устранению (не просто «исправьте это») и включает ссылки на официальную документацию.

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

Охваченные пути обновления

Для .NET конкретно:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Каждый путь обновления имеет правила обнаружения, которые знают, какие API были удалены, какие паттерны не имеют прямого эквивалента и какие проблемы безопасности требуют внимания.

Для команд, управляющих несколькими приложениями, есть также CLI, поддерживающий пакетные оценки нескольких репозиториев — клонируйте все репо, оцените их все, получите отчёты по каждому приложению плюс агрегированное представление портфолио.

Моё мнение

Если вы сидите на устаревших приложениях .NET Framework (а давайте будем честны, большинство корпоративных команд именно так и делает), это тот самый инструмент, с которого стоит начать. Только документ оценки стоит потраченного времени — он превращает расплывчатое «нам бы модернизировать» в конкретный, приоритизированный список рабочих элементов с чёткими путями вперёд.

Коллаборативный рабочий процесс тоже продуман: экспортируйте оценки, поделитесь с командой, импортируйте без повторного запуска. Архитектурные ревью, где решения принимают не те, кто запускает инструменты? Учтено.

Подводя итоги

Оценка модернизации GitHub Copilot превращает миграцию .NET из пугающего, неопределённого проекта в структурированный, отслеживаемый процесс. Начните с рекомендованной оценки, чтобы увидеть текущее состояние, затем используйте пользовательские оценки для сравнения целей Azure и построения плана миграции.

Прочитайте полное руководство и установите расширение VS Code, чтобы попробовать на своей кодовой базе.