پاسخ کوتاه
برای بهروزرسانی امن، موجودی دقیق نسخهها و وضعیت پشتیبانی را ثبت کنید، Release Note و تغییرات امنیتی را بخوانید، Backup و بازیابی را آزمایش کنید، نسخه را در Staging مشابه Production با تست خودکار و سناریوهای حیاتی بررسی کنید، انتشار مرحلهای و مانیتورینگ داشته باشید و قبل از تغییر، Rollback قابل اجرا تعریف کنید. Patch جاری، ارتقای وابستگی و مهاجرت Major سه پروژه با دامنه متفاوتاند.
قبل از هر تغییر، نقشه نسخهها و وابستگیها را بسازید
- نسخه Runtime و SDK مورد استفاده در Build و اجرا
- نوع پروژه: .NET، .NET Framework، ASP.NET Core یا سرویس Windows
- نسخه سیستمعامل، IIS، Hosting Bundle و Container Image
- پکیجهای NuGet، درایور دیتابیس و SDK سرویسهای بیرونی
- محل تنظیمات، Certificateها، Secretها و حسابهای سرویس
- مالک فنی، پنجره نگهداری و مسیرهای حیاتی کسبوکار
نوع تغییر را درست نامگذاری کنید
Servicing یا Patch
- دامنه معمول
- اصلاح امنیتی و پایداری در خط پشتیبانیشده
- خروجی لازم
- تست رگرسیون و برنامه انتشار
بهروزرسانی وابستگی
- دامنه معمول
- NuGet، Driver یا ابزار Build
- خروجی لازم
- بررسی Breaking Change و Lockfile
ارتقای Major یا LTS/STS
- دامنه معمول
- Target Framework و ابزارهای ساخت
- خروجی لازم
- برنامه سازگاری، اصلاح کد و Benchmark
نوسازی .NET Framework
- دامنه معمول
- معماری، کتابخانه قدیمی و Windows
- خروجی لازم
- ارزیابی Refactor، Migration یا نگهداری کنترلشده
نکته: برچسب «آپدیت» نباید تفاوت میان Patch کمدامنه و مهاجرت معماری را پنهان کند؛ زمان، هزینه و ریسک آنها یکسان نیست.
تست قبل از Production را به محیط واقعی نزدیک کنید
- Release Note، Known Issue و سیاست پشتیبانی نسخه هدف را بررسی کنید.
- نسخه پشتیبان بگیرید و Restore را در محیط امن آزمایش کنید.
- Build تکرارپذیر و قفل نسخه وابستگیها را تأیید کنید.
- تستهای خودکار، Migration دیتابیس و سناریوهای حیاتی را اجرا کنید.
- اتصال به دیتابیس، صف، فایل، ایمیل، API و احراز هویت را بررسی کنید.
- مصرف CPU و RAM، زمان پاسخ، Error Rate و Logهای جدید را با خط پایه مقایسه کنید.
- مسیر بازگشت نسخه برنامه و تغییرات دیتابیس را جداگانه تمرین کنید.
انتشار، مانیتورینگ و Rollback را یک سناریوی واحد ببینید
برای سامانههای حساس میتوان از Canary، Blue/Green یا انتشار روی بخشی از Nodeها استفاده کرد. انتخاب روش به معماری و تحمل توقف بستگی دارد؛ نام روش مهمتر از امکان مشاهده اثر و بازگشت کنترلشده نیست.
قبل از انتشار
- تصمیم قابل ثبت
- مسئول، زمان، توقف مجاز و نسخه قبلی
- شاهد موفقیت
- چکلیست تأییدشده و Backup قابل بازیابی
حین انتشار
- تصمیم قابل ثبت
- ترتیب Nodeها و Migrationها
- شاهد موفقیت
- Health Check و Log بدون خطای بحرانی
پس از انتشار
- تصمیم قابل ثبت
- مدت مراقبت و شاخصهای هشدار
- شاهد موفقیت
- تراکنش آزمایشی و شاخصهای پایدار
بازگشت
- تصمیم قابل ثبت
- Trigger، مسئول و حداکثر زمان تصمیم
- شاهد موفقیت
- نسخه قبلی، داده سازگار و خدمت سالم
بهروزرسانی را از واکنش اضطراری به فرایند نگهداری تبدیل کنید
- بازبینی ماهانه اعلانهای امنیتی و چرخه عمر نسخهها
- ثبت مالک هر Runtime، سرویس و وابستگی حیاتی
- محیط Staging و مجموعه تست رگرسیون قابل استفاده
- تقویم Patch با مسیر استثنا برای آسیبپذیری بحرانی
- گزارش تغییر، نتیجه تست، زمان انتشار و رخدادهای پس از آن
- بودجه و نقشه راه برای خروج از نسخههای نزدیک پایان پشتیبانی
پرسشهای متداول
آیا نصب آخرین Runtime روی سرور کافی است؟
خیر. باید Target Framework، مدل استقرار، Hosting Bundle، وابستگیها و سازگاری برنامه بررسی شود. وجود Runtime جدید الزاماً برنامه را به آن منتقل نمیکند.
آیا هر پروژه .NET Framework باید فوراً بازنویسی شود؟
خیر. ابتدا وضعیت پشتیبانی Windows، ریسک امنیتی، محدودیت کتابخانهها، هزینه تغییر و نیازهای آینده را ارزیابی کنید. گاهی نگهداری کنترلشده یا Refactor مرحلهای منطقیتر است.
میتوان نسخه Preview را در Production استفاده کرد؟
طبق سیاست رسمی .NET، نسخههای Preview برای Production پشتیبانی نمیشوند. برای سرویس واقعی از نسخه پشتیبانیشده متناسب با چرخه عمر انتخابشده استفاده کنید.
Rollback شامل دیتابیس هم میشود؟
بله. بازگشت فایل برنامه کافی نیست؛ سازگاری Schema و داده، Forward-fix یا Down Migration و امکان بازیابی باید پیش از انتشار تعیین شود.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.