.NET 11 منتشر شد؛ راهنمای تصمیم‌گیری برای ارتقای تیم‌های توسعه

این سرویس چیست؟

.NET یک پلتفرم متن‌باز و چندسکویی برای ساخت وب‌اپلیکیشن، سرویس‌های ابری، نرم‌افزارهای دسکتاپ و موبایل و محصولات هوش مصنوعی است.

.NET ۱۱ چیست و چه چیزی تغییر کرده است؟

ارتقای دات‌نت ۱۱ برای تیمی معنا دارد که می‌خواهد پلتفرم اجرای وب، کلاد و نرم‌افزارهای چندسکویی خود را با برنامهٔ قابل‌اندازه‌گیری به‌روز کند. .NET ۱۱ تازه‌ترین نسخهٔ اصلی پلتفرم متن‌باز و چندسکویی مایکروسافت برای ساخت وب‌اپلیکیشن، سرویس‌های ابری، نرم‌افزارهای دسکتاپ و موبایل و راهکارهای هوش مصنوعی است. این پلتفرم با runtime، SDK، کتابخانه‌ها، ASP.NET Core، .NET MAUI، Entity Framework Core و ابزارهای ساخت، یک زنجیرهٔ کامل برای توسعه و اجرای نرم‌افزار فراهم می‌کند. انتشار .NET ۱۱ در ۱۰ نوامبر ۲۰۲۶ ثبت شده است و نسخهٔ پایدار ۱۱.۰.۰ در مخزن رسمی release notes قرار دارد.

STS بودن .NET ۱۱ یعنی چه؟

مایکروسافت .NET ۱۱ را در مسیر Standard Term Support یا STS قرار داده است. طبق صفحهٔ رسمی نسخه، پشتیبانی این شاخه از ۱۰ نوامبر ۲۰۲۶ تا ۱۴ نوامبر ۲۰۲۸ ادامه دارد؛ بنابراین تیمی که امروز از .NET ۱۱ استفاده می‌کند، باید چرخهٔ پشتیبانی دو ساله را در برنامهٔ نگهداری خود لحاظ کند. STS بودن به‌معنای بی‌ارزش‌بودن نسخه نیست، اما با LTS تفاوت دارد: برای محصولاتی که عمر انتشار طولانی، ارتقای کم‌تعداد یا قرارداد پشتیبانی چندساله دارند، انتخاب LTS معمولاً ریسک عملیاتی کمتری ایجاد می‌کند.

در مقابل، .NET ۱۱ می‌تواند برای تیم‌هایی مناسب باشد که می‌خواهند سریع‌تر به قابلیت‌های جدید runtime، SDK، ASP.NET Core و کتابخانه‌ها برسند، چرخهٔ ارتقای منظم دارند و تست‌های خودکارشان پوشش مناسبی دارد. تصمیم درست باید بر اساس افق محصول، وابستگی‌های شخص ثالث، imageهای کانتینری و توان تیم برای مهاجرت گرفته شود؛ صرفاً جدیدتر بودن نسخه، دلیل کافی برای ارتقا نیست.

قبل از ارتقا چه چیزهایی را بررسی کنیم؟

ابتدا نسخهٔ فعلی SDK و runtime را در محیط توسعه، CI، staging و production ثبت کنید. سپس فایل‌های global.json، Dockerfile، pipelineهای CI/CD، image پایه، packageهای NuGet و وابستگی‌های native را فهرست کنید. اگر پروژه از ASP.NET Core، EF Core، MAUI، WPF یا WinForms استفاده می‌کند، راهنمای مهاجرت همان بخش را جداگانه بررسی کنید. تفاوت نسخهٔ SDK روی build و نسخهٔ runtime روی اجرای سرویس اثر دارد و نباید این دو با هم اشتباه گرفته شوند.

در مرحلهٔ بعد، یک شاخهٔ ارتقا بسازید و تست‌های unit، integration، smoke و performance را در کنار بررسی لاگ‌ها اجرا کنید. برای سرویس‌های کانتینری، image جدید را با digest مشخص بسازید و رفتار startup، health check، اندازهٔ image و مصرف حافظه را با نسخهٔ قبلی مقایسه کنید. در سامانه‌های وب، مسیرهای احراز هویت، serialization، کش، background job و ارتباط با دیتابیس را در staging بازآزمایی کنید.

برای تیم‌هایی که چند محصول دارند، یک ماتریس ساده بسازید: نام سرویس، نسخهٔ SDK، نسخهٔ runtime، وابستگی‌های حساس، وضعیت تست و تصمیم نهایی. این ماتریس کمک می‌کند ارتقای دات‌نت ۱۱ از یک تصمیم کلی به چند اقدام قابل‌اندازه‌گیری تبدیل شود. همچنین مالک هر سرویس و زمان بازبینی rollback را مشخص کنید تا در زمان بروز خطا، تصمیم‌گیری به حدس و گفت‌وگوی پراکنده وابسته نباشد. مطالعهٔ راهنمای اتوماسیون و زیرساخت تکتاز نیز برای طراحی فرایندهای قابل‌ردگیری مفید است.

برنامهٔ rollout پیشنهادی

ارتقای یک‌بارهٔ همهٔ سرویس‌ها معمولاً ریسک را افزایش می‌دهد. ابتدا یک سرویس کم‌ریسک یا محیط آزمایشی را انتخاب کنید، metricهای خطا و latency را ثبت کنید و سپس rollout را مرحله‌ای گسترش دهید. نگه‌داشتن امکان rollback، pin کردن image و SDK، ثبت تغییرات schema و داشتن backup معتبر، بخش جدایی‌ناپذیر این برنامه است. اگر محصول شما به پشتیبانی طولانی‌تر نیاز دارد، مسیر LTS بعدی را هم در تقویم ارتقا مقایسه کنید.

جمع‌بندی عملی

.NET ۱۱ در ۱۰ نوامبر ۲۰۲۶ منتشر شده و یک شاخهٔ STS با پشتیبانی تا ۱۴ نوامبر ۲۰۲۸ است. برای تیم‌های توسعه‌ای که چرخهٔ انتشار منظم و تست خودکار دارند، می‌تواند گزینه‌ای مناسب برای دسترسی سریع‌تر به runtime و ابزارهای جدید باشد. اما برای ارتقا باید ابتدا dependencyها، CI/CD، کانتینرها، تست‌ها و برنامهٔ rollback بررسی شوند. بهترین اقدام، ساخت یک ماتریس سازگاری و اجرای rollout مرحله‌ای است؛ نه تغییر مستقیم production در روز انتشار.

منبع رسمی: مستندات release notes دات‌نت ۱۱

کلیدواژه: ارتقای دات‌نت ۱۱

در عمل، ارتقای دات‌نت ۱۱ باید با ثبت نسخهٔ فعلی شروع شود. پس از آن، ارتقای دات‌نت ۱۱ در یک شاخهٔ جداگانه و سپس در staging آزمایش می‌شود. برای ارتقای دات‌نت ۱۱، وابستگی‌های NuGet و imageهای کانتینری را pin کنید. در ارتقای دات‌نت ۱۱، rollback را پیش از rollout تولیدی تمرین کنید. در نهایت، ارتقای دات‌نت ۱۱ را با metricهای خطا، latency و مصرف منابع ارزیابی کنید.