| 1 | ## .NET playbooks (upgrade, targeting, diagnostics) |
| 2 | |
| 3 | **Назначение:** набор компактных сценариев‑playbook’ов для практических шагов вокруг .NET: выбор целевой версии, миграция с .NET Framework, базовая диагностика. |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | ### Playbook DOTNET‑01 — выбрать целевой .NET / TFM для нового приложения |
| 8 | |
| 9 | - **Context:** нужно создать новый сервис/утилиту/приложение и решить, на какую версию .NET его таргетить. |
| 10 | - **Steps:** |
| 11 | 1. Определи класс приложения: API/worker/desktop/tool; требования по поддерживаемым ОС (Windows‑only vs кроссплатформа). |
| 12 | 2. Проверяй текущую матрицу LTS/STS (.NET 8/9/10) и сроки поддержки. |
| 13 | 3. Если нет жёстких ограничений — выбирай последнюю LTS (сейчас .NET 8/10) как дефолт для production‑сервисов. |
| 14 | 4. Для экспериментальных R&D‑утилит допустим STS (например, .NET 9) с осознанным горизонтом жизни. |
| 15 | 5. Зафиксируй выбор в ADR/README: TFM (`net8.0`/`net10.0`), аргументы выбора, политика обновления. |
| 16 | - **Exit criteria:** выбран конкретный TFM, задокументирован тип релиза (LTS/STS) и нет «скрытого» использования устаревших версий. |
| 17 | |
| 18 | --- |
| 19 | |
| 20 | ### Playbook DOTNET‑02 — оценить и спланировать миграцию .NET Framework → .NET |
| 21 | |
| 22 | - **Context:** есть работающее приложение на .NET Framework (3.5/4.x), нужно понять, стоит ли и как его мигрировать на современный .NET. |
| 23 | - **Steps:** |
| 24 | 1. Составь инвентаризацию: целевая версия Framework (например, `4.0`, `4.5.2`, `4.8`), тип приложения (ASP.NET, WPF, WinForms, service), ключевые зависимости (WCF, WebForms, COM, third‑party). |
| 25 | 2. Проверь статус поддержки версии по официальной матрице (.NET Framework lifecycle); пометь EOL/скоро EOL. |
| 26 | 3. Раздели систему на слоя: UI, доменная логика, инфраструктура; оцени, какие части можно вынести в кроссплатформенные библиотеки/сервисы на .NET 8/10 без немедленного переписывания всего UI. |
| 27 | 4. Выбери стратегию: (а) lift‑and‑shift (пересборка на .NET 8/10 при минимальных изменениях, если возможно), (б) стратификация (новые сервисы и библиотеки на .NET 8/10, UI остаётся на Framework), (в) зелёное поле с постепенной миграцией данных/функций. |
| 28 | 5. Для выбранной стратегии сформируй минимальный пилот (одно сервисное направление/подсистему) с чёткими критериями успеха (производительность, надёжность, стоимость сопровождения). |
| 29 | - **Exit criteria:** есть документированный migration‑план и пилот; риски и выгоды описаны, нет «туманных» ожиданий типа «перепишем всё и станет лучше». |
| 30 | |
| 31 | --- |
| 32 | |
| 33 | ### Playbook DOTNET‑03 — базовый диагностический цикл для .NET сервиса |
| 34 | |
| 35 | - **Context:** есть подозрение на проблемы производительности/стабильности .NET сервиса (включая ASP.NET Core/worker). |
| 36 | - **Steps:** |
| 37 | 1. Подтверди симптом через метрики/логи (CPU/память/latency/ошибки) и health‑пробы, не полагаясь только на субъективное ощущение «тормозит». |
| 38 | 2. Используй `dotnet-counters` или встроенные метрики (через OpenTelemetry/Prometheus) для первичной картины: CPU, GC (Gen0/1/2, LOH), thread pool, запросы/сек. |
| 39 | 3. При подтверждённой проблеме собирай короткий trace (`dotnet-trace`, профайлер) в контролируемом окне времени. |
| 40 | 4. Анализируй горячие пути и типы: где саме «горит» CPU, какие объекты доминируют в allocation profile, есть ли очевидные блокировки/ThreadPool starvation. |
| 41 | 5. Оформляй находки в маленькие change‑set’ы (изменение алгоритма, уменьшение аллокаций, исправление sync‑over‑async) и обязательно повторяй измерения до/после. |
| 42 | - **Exit criteria:** есть одно или несколько чётко задокументированных улучшений с измеримым эффектом, а не бесконечная настройка флагов «на глазок». |
| 43 | |
| 44 | |
| 45 | |