Короткий ответ
Source audit, build reproducibility, dependencies, database, installer, logs and regression tests. Разбираем практический порядок работ, риски, стоимость и то, как принять результат без новых проблем.
Ниже — конкретные проверки, команды, таблицы и контроль результата. Выполняйте изменения только после резервной копии, если действие затрагивает рабочую систему.
Что принять вместе с исходниками
| Артефакт | Обязательно |
|---|---|
| Repository | да |
| Build instructions | да |
| Dependency lock | да |
| DB schema/migrations | если есть БД |
| Installer project | если распространяется |
| Signing certificate process | если используется |
| API/env config | без секретов в репозитории |
| Release history | желательно |
Инвентаризация .NET-проекта
dotnet --info
dotnet restore
dotnet build --configuration Release
dotnet list package
git status
git log --oneline -n 20Сначала воспроизведите сборку без изменений
Если Release не собирается на чистой машине/CI, нельзя уверенно оценивать новую функцию. Зафиксируйте версию SDK, NuGet sources, native dependencies и installer toolchain.
Как проверить результат
После изменений повторите исходный сценарий, зафиксируйте результат и убедитесь, что соседние функции работают так же, как до правки. Если проблема проявляется не всегда, проведите несколько повторов в одинаковых условиях и сохраните диагностические данные.