Publish، Deployment و IIS
Publish، Deployment و IIS
محتوای درس Publish، Deployment و IIS
.NET 10 | Hosting، Configuration و عملیات انتشار
Deployment پایان Build نیست؛ فرآیندی شامل Artifact قابل تکرار، Configuration محیط، Runtime/Hosting Bundle، Database Migration، Health Check و Rollback است. IIS در Windows نقش Reverse Proxy و Process Hosting را برای ASP.NET Core ایفا میکند.
این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیتها و رفتار قابل پیشبینی در محیط واقعی تنظیم شده است. مثالها بر پایه ASP.NET Core و .NET 10 نوشته شدهاند.
1. چارچوب موضوع و مفاهیم اصلی
Deployment پایان Build نیست؛ فرآیندی شامل Artifact قابل تکرار، Configuration محیط، Runtime/Hosting Bundle، Database Migration، Health Check و Rollback است. IIS در Windows نقش Reverse Proxy و Process Hosting را برای ASP.NET Core ایفا میکند.
واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن میماند که مسئولیت هر جزء بهصورت صریح تعریف شود.
| مفهوم | کارکرد |
|---|---|
| dotnet publish | تولید Artifact |
| Hosting Bundle | Runtime و IIS Module |
| App Pool | فرآیند میزبان IIS |
| web.config | تنظیم Hosting Module |
| Environment Variable | تنظیم محیط |
| Rollback | بازگشت نسخه |
2. ساختار پیشنهادی در پروژه
Artifact با Configuration Release تولید و روی مسیر مستقل منتشر میشود. Secretها در محیط مقصد تنظیم میشوند و دسترسی فایل، Certificate و Connection String پیش از Start بررسی میگردند.
dotnet publish -c Release -o ./publish
# Example environment
ASPNETCORE_ENVIRONMENT=Production
ConnectionStrings__DefaultConnection=...3. سناریوی اجرایی
پس از انتشار روی IIS، App Pool و Hosting Bundle بررسی میشوند. اگر برنامه با 500.30 متوقف شود، Event Viewer و stdout موقت برای یافتن خطای Startup استفاده میشوند و پس از عیبیابی Logging ناامن غیرفعال میشود.
در این سناریو، قرارداد ورودی و خروجی، مسیر شکست و رفتار قابل مشاهده سرویس باید پیش از جزئیات پیادهسازی مشخص شود. این رویکرد باعث میشود تغییرات بعدی بدون وابستگی پنهان و با امکان تست دقیق انجام شوند.
<aspNetCore processPath="dotnet"
arguments=".\ProductApi.dll"
stdoutLogEnabled="false"
hostingModel="inprocess" />4. اصول طراحی و نگهداری
پیادهسازی قابل نگهداری تنها به درست کار کردن در مسیر موفق محدود نیست. مرزهای مسئولیت، قابلیت مشاهده، امنیت، رفتار در خطا و امکان توسعه تدریجی باید همزمان بررسی شوند.
- Artifact Build شده در CI همان Artifact محیط مقصد باشد.
- Configuration از Artifact جدا باشد.
- Migration و Rollback Plan پیش از Release مشخص باشند.
- Data Protection Keyها در چند Instance به Storage پایدار منتقل شوند.
5. خطاهای رایج و کنترل آنها
بخش مهمی از کیفیت یک API در نحوه جلوگیری از خطاهای تکرارشونده مشخص میشود. موارد زیر باید در بازبینی کد و تستهای قبل از انتشار کنترل شوند.
- کپی فایل Development با appsettings حاوی Secret.
- نصب نبودن Hosting Bundle سازگار.
- تغییر دستی Production بدون ثبت نسخه.
- فعال ماندن stdoutLog با اطلاعات حساس و رشد فایل.
6. چکلیست نهایی فصل
- Release publish موفق است.
- Runtime/Hosting Bundle مقصد سازگار است.
- Connection و Certificate Production تست شدهاند.
- Health Check پس از Deployment و مسیر Rollback تعریف شده است.
7. جمعبندی
مفاهیم این فصل زمانی کامل محسوب میشوند که هم مسیر موفق و هم مسیر خطا قابل پیشبینی، قابل تست و قابل مشاهده باشند. طراحی نهایی باید با Contract API، امنیت و نیازهای نگهداری پروژه هماهنگ بماند.