در چارچوب ITIL 4، جداسازی استقرار (Deployment) از انتشار (Release) بخشی از تمرین‌های پیشرفته در دو حوزه‌ی Release Management و Deployment Management محسوب می‌شود. ITIL 4 تأکید دارد که انتشار یک تغییر برای کاربران نهایی نباید الزاماً همزمان با استقرار فنی آن باشد. این رویکرد، که با استفاده از ابزارهایی مانند feature toggles، blue-green deployment یا canary releases پشتیبانی می‌شود، امکان تحویل ارزش به‌صورت امن، کنترل‌شده و با ریسک کمتر را فراهم می‌کند. در ITIL 4، تمرکز بر مدیریت ارزش کسب‌وکار است، نه صرفاً تحویل تغییر، و این جداسازی دقیقاً همین هدف را محقق می‌کند.
قبل از بررسی این جداسازی بیایید یک سناریو واقعی را بررسی کنیم.
نجات پروژه فروشگاه آنلاین در یک جمعه سیاه
سناریو: شرکت ایکس بعنوان مالک یک پلتفرم فروشگاهی بزرگ در کشور، تصمیم می‌گیرد یک فیچر پیشنهاد هوشمند را برای افزایش فروش محصولات خود فعال کند. ویژگی‌ها کاملاً تست شده‌اند، اما ریسک اصلی زمان انتشار است: جمعه سیاه، ساعت ۹ صبح. تیم مجبور است ویژگی جدیدی را در روز جمعه سیاه ارائه دهد. یک اشتباه کوچک در این روز می‌تواند میلیون‌ها تومان خسارت وارد کند. در اینجا، جدا کردن استقرار از انتشار راه‌حلی نجات‌بخش می‌شود. این یعنی شرکت ایکس به‌جای انتشار مستقیم تصمیم می‌گیرد:
- ویژگی را دو روز قبل مستقر (deploy) کند، اما آن را برای کاربران غیرفعال نگه دارد.
- در روز جمعه و پس از بررسی وضعیت سرورها، با استفاده از feature toggle و Canary Release، آن را فقط برای ۵٪ کاربران فعال کنند.
- پس از مشاهده رفتار کاربران و سلامت سیستم، طی چند ساعت بعد، انتشار کامل انجام می‌شود.
نتیجه:
نه‌تنها سیستم بدون مشکل کار کرد، بلکه فروش آن روز ۲۷٪ افزایش یافت. مشتریان هم تجربه بهتری داشتند جدا کردن استقرار از انتشار باعث شد تیم بتواند بدون نگرانی از بروز خطا در زمان اوج ترافیک، کنترل کامل بر ویژگی جدید داشته باشد. این رویکرد نه فقط در جمعه سیاه، بلکه در هر به‌روزرسانی مهمی ضروری است.
در جدول زیر، دو تکنیک مهم در جداسازی استقرار (Deployment) از انتشار (Release) در چارچوب ITIL 4 — یعنی Feature Toggle و Canary Release — به صورت مقایسه‌ای شرح داده شده‌اند:
جدول مقایسه Feature Toggle و Canary Release
تکنیک‌های Feature Toggle و Canary Release سابقه‌ای چندده‌ساله در مهندسی نرم‌افزار دارند، اما با گسترش متدلوژی‌های چابک (Agile) و DevOps، نقش آن‌ها در مدیریت تغییر و انتشار بسیار پررنگ‌تر شده است. Feature Toggle نخستین بار توسط توسعه‌دهندگان در شرکت‌هایی مثل Flickr و Facebook مورد استفاده قرار گرفت تا ویژگی‌هایی را در محیط production مستقر کنند اما تنها برای گروه خاصی از کاربران یا در شرایط خاص فعال نمایند. این روش به تیم‌ها اجازه می‌دهد بدون نیاز به بازاستقرار، ویژگی‌ها را روشن یا خاموش کرده و کنترل دقیق‌تری بر زمان و نحوه انتشار داشته باشند. از سوی دیگر، Canary Release الهام‌گرفته از روش‌های ایمنی در معادن (استفاده از قناری‌ها برای شناسایی گازهای سمی) است و اولین بار در مقیاس وسیع توسط Google و Netflix به‌کار گرفته شد. این تکنیک به تیم‌ها اجازه می‌دهد تا نسخه‌ی جدیدی از نرم‌افزار را ابتدا برای درصد محدودی از کاربران منتشر کرده و در صورت عدم مشاهده مشکل، آن را به کل کاربران گسترش دهند. هر دو روش امروز بخشی جدایی‌ناپذیر از استراتژی‌های مدرن انتشار در چارچوب‌هایی مانند ITIL 4، Site Reliability Engineering (SRE) و Continuous Delivery هستند.
| ویژگی / تکنیک | Feature Toggle (کلید ویژگی) | Canary Release (انتشار قناری‌وار) |
|---|---|---|
| تعریف | مکانیسمی در کد که به شما اجازه می‌دهد یک ویژگی را بدون تغییر در کد اصلی فعال یا غیرفعال کنید. | نوعی انتشار تدریجی که ابتدا تنها برای درصد کمی از کاربران فعال می‌شود. |
| هدف اصلی | جدا کردن زمان استقرار از زمان فعال‌سازی ویژگی برای کاربران. | شناسایی مشکلات احتمالی در مقیاس کوچک قبل از انتشار عمومی. |
| نحوه اجرا | از طریق پارامترهای پیکربندی یا ابزارهای third-party (مثلاً LaunchDarkly، Unleash). | با تقسیم ترافیک به چند گروه و هدایت آن به نسخه جدید از نرم‌افزار در محیط production. |
| مزیت کلیدی | کنترل لحظه‌ای و سریع بر فعال‌سازی ویژگی‌ها بدون نیاز به استقرار مجدد. | کاهش ریسک انتشار و امکان rollback سریع در صورت بروز مشکل. |
| مناسب برای | ویژگی‌های بزرگ یا حساس که نیاز به تست در زمان‌های خاص دارند. | نسخه‌هایی که ممکن است در رفتار یا عملکرد ریسک بالایی داشته باشند. |
| میزان وابستگی به کد | وابسته به کدنویسی و ساختار معماری نرم‌افزار. | بیشتر در سطح زیرساخت و مسیر ترافیک و نسخه‌های سرویس اجرا می‌شود. |
| ابزارهای متداول | LaunchDarkly، Unleash، ConfigCat | Kubernetes، Istio، Spinnaker، AWS CodeDeploy |
| در ITIL 4 در کدام تمرین؟ | در تمرین‌های Release Management و Deployment Management به‌عنوان الگوهای مدرن توصیه می‌شوند. |
در ادامه، یک جدول مزایا و توضیح درباره چرایی و چگونگی جداسازی استقرار (Deployment) از انتشار (Release) ارائه می‌دهیم:
مزایای جداسازی استقرار از انتشار
| مزیت | توضیح |
|---|---|
| کاهش ریسک | امکان فعال‌سازی تدریجی ویژگی‌ها و جلوگیری از بروز خطا در محیط واقعی |
| سرعت در تحویل | استقرار پیش از زمان انتشار، باعث کاهش تأخیر و افزایش چابکی تیم می‌شود |
| کنترل بیشتر | تیم می‌تواند زمان دقیق انتشار را با توجه به شرایط بازار یا سیستم انتخاب کند |
| انعطاف‌پذیری در مدیریت ویژگی‌ها | امکان استفاده از feature toggle برای فعال/غیرفعال‌سازی ویژگی‌ها |
| بهبود تجربه کاربر | کاربران با نسخه‌ای پایدار و تست‌شده روبه‌رو می‌شوند، بدون اختلال ناگهانی |
| امکان آزمون تدریجی | استفاده از تکنیک‌هایی مانند Canary Release برای تست محدود در ابتدا |
چرا باید استقرار و انتشار را جدا کرد؟
- در مدل‌های سنتی مانند واترفال، استقرار و انتشار همزمان هستند؛ یعنی با استقرار کد، ویژگی بلافاصله در اختیار کاربران قرار می‌گیرد. این موضوع باعث افزایش ریسک بروز خطا و کاهش کنترل روی زمان عرضه می‌شود.
- در محیط‌های پویا و سریع مانند Agile یا DevOps، جداسازی باعث می‌شود تیم‌ها بتوانند کد را زودتر در محیط عملیاتی قرار دهند و در زمان مناسب آن را منتشر کنند.
چگونه این جداسازی انجام می‌شود؟
| مرحله | اقدام |
|---|---|
| استقرار (Deploy) | کد به محیط production ارسال می‌شود ولی برای کاربران نهایی غیرفعال می‌ماند. |
| ابزارهای کنترل | استفاده از feature toggle، LaunchDarkly، یا config flags برای کنترل انتشار. |
| تست تدریجی | ابتدا با Canary Release یا Blue-Green Deployment روی درصدی از کاربران فعال می‌شود. |
| انتشار (Release) | پس از اطمینان از عملکرد، ویژگی برای کل کاربران فعال می‌شود. |
اجرای جداسازی بین استقرار (Deployment) و انتشار (Release) هرچند مزایای زیادی دارد، اما با چالش‌هایی نیز همراه است. در ادامه مهم‌ترین چالش‌ها را با توضیح مختصر آورده‌ام:
چالش‌های اجرای جداسازی استقرار از انتشار
| چالش | توضیح |
|---|---|
| 1. پیچیدگی در معماری نرم‌افزار | برای پیاده‌سازی feature toggle یا Canary Release، معماری باید ماژولار و قابل‌تنظیم باشد. |
| 2. نیاز به ابزارهای خاص | اجرای این جداسازی نیازمند ابزارهای مدیریت ویژگی (مانند LaunchDarkly یا Unleash) و CI/CD پیشرفته است. |
| 3. هماهنگی بین تیم‌ها | توسعه‌دهندگان، تست‌کنندگان، DevOps و مدیر محصول باید دقیقاً روی زمان‌بندی و سیاست‌های انتشار هم‌نظر باشند. |
| 4. ریسک فعال‌سازی اشتباه | اگر feature toggle به‌درستی پیکربندی نشده باشد، ممکن است ویژگی ناخواسته برای کاربران فعال شود. |
| 5. افزایش بار نگهداری کد | فعال/غیرفعال بودن ویژگی‌ها باید به‌درستی مدیریت شود تا منجر به پیچیدگی بیش از حد در کد نشود. |
| 6. دشواری در تست کامل | وقتی ویژگی‌ای مستقر شده ولی هنوز منتشر نشده، تست آن در محیط production نیازمند دقت و ابزارهای مخصوص است. |
| 7. مقاومت فرهنگی در تیم | برخی تیم‌ها (مخصوصاً در سازمان‌های سنتی‌تر) با تغییر رویکردهای انتشار و استقلال DevOps مخالفت دارند. |
راهکارهای پیشنهادی برای عبور از این چالش‌ها:
- طراحی معماری مبتنی بر microservice یا feature flags
- آموزش تیم‌ها درباره مزایا و روندهای مدرن DevOps
- استفاده از ابزارهای مدیریت انتشار مانند LaunchDarkly، Split.io یا Unleash
- مستندسازی دقیق سیاست‌های feature toggling
- داشتن محیط staging قوی برای تست نهایی قبل از release
در سرویس‌دسک پلاس (ServiceDesk Plus) که یک ابزار ITSM از شرکت ManageEngine است، جداسازی بین استقرار (Deployment) و انتشار (Release) نیز می‌تواند به‌خوبی پیاده‌سازی شود، به‌ویژه در نسخه‌های حرفه‌ای یا Enterprise که ماژول‌های Change Management و Release Management را دارند. در ادامه، توضیح می‌دهیم این جداسازی چگونه در ServiceDesk Plus قابل انجام است:
فرایند Deployment و Release در ابزار سرویس دسک پلاس
| مرحله | شرح کاربردی در ServiceDesk Plus |
|---|---|
| 1. درخواست تغییر (Change Request) | از طریق ماژول تغییر (Change Module) یک RFC (درخواست تغییر) ثبت می‌شود که شامل هدف، تأثیر و خطرات است. |
| 2. برنامه‌ریزی انتشار (Release Planning) | یک Release Record در ماژول Release Management ساخته می‌شود که شامل برنامه زمان‌بندی و rollback plan است. |
| 3. استقرار بدون انتشار | در فاز Deployment, کد یا تنظیمات جدید روی سرورها یا سیستم‌ها نصب می‌شود اما برای کاربران فعال نمی‌شود (feature toggle). |
| 4. تست و بررسی کنترل‌شده | تست توسط تیم تست یا تیم محدود کاربری (pilot group) انجام می‌شود و نتایج در Release Record ثبت می‌گردد. |
| 5. انتشار نهایی | پس از تأیید CAB یا Release Manager، ویژگی به‌صورت گسترده فعال (release) می‌شود و کاربران آن را می‌بینند. |
کاربرد این جداسازی در ITIL
فرض کنید تیم IT می‌خواهد ویژگی جدیدی در پورتال کاربران نهایی اضافه کند (مثلاً قابلیت درخواست تجهیزات جدید).
- تیم توسعه ویژگی را پیاده‌سازی می‌کند و روی محیط production استقرار (deploy) می‌کند اما آن را با یک feature flag غیرفعال نگه می‌دارد.
- در ServiceDesk Plus، در ماژول Release یک Release Record ایجاد می‌شود که زمان انتشار عمومی را مشخص می‌کند.
- تیم QA یا کاربران منتخب، ویژگی را تست می‌کنند.
- پس از تأیید، Release Manager در زمان تعیین‌شده feature flag را فعال کرده و انتشار انجام می‌شود.
ابزارهای کمکی در سرویس دسک پلاس برای این مدل:
- Change Advisory Board (CAB): برای بررسی و تصویب تغییرات و انتشارها
- Release Workflow: تعریف دقیق مراحل approval، deployment و go-live
- Status Tracking: برای مشاهده وضعیت دقیق هر فاز از Release
- Integration با ابزارهای CI/CD: مانند Jenkins یا GitLab برای استقرار خودکار
با مدانت در تماس باشید
