یک Change میتواند کاملاً تأیید شده باشد اما اجرای آن همچنان شکست بخورد؛ چون بسته انتشار درست ساخته نشده، تست ناقص بوده، UAT انجام نشده یا زمان Deployment با سرویسهای وابسته هماهنگ نشده است. این دقیقاً جایی است که Release Management در ServiceDesk Plus ارزش پیدا میکند.
Change Management تصمیم میگیرد «آیا این تغییر باید انجام شود؟» و Release Management پاسخ میدهد «چطور این تغییر یا مجموعه تغییرها را به شکل کنترلشده وارد محیط عملیاتی کنیم؟». در پروژههای واقعی، جداکردن این دو نگاه باعث میشود CAB روی ریسک و مجوز تمرکز کند و تیم Release روی Build، Test، Deployment و بازبینی.
Release با Change چه تفاوتی دارد؟
| موضوع | Change | Release |
|---|---|---|
| پرسش اصلی | آیا تغییر مجاز و قابل قبول است؟ | چطور بسته تغییر را تحویل و مستقر کنیم؟ |
| تمرکز | ریسک، Approval، CAB، زمانبندی | Build، Test، UAT، Deployment، Review |
| خروجی | Change تأییدشده | نسخه یا بسته منتشرشده |
| شاخص مهم | Change Success Rate | Release Success / Rollback / Defect Rate |
چه زمانی Release Record بسازیم؟
برای هر Patch کوچک الزاماً Release جدا لازم نیست. Release زمانی ارزش بیشتری دارد که چند Change به یک خروجی واحد وابسته باشند، Deployment چندمرحلهای باشد یا ذینفعان کسبوکار باید قبل از Go-Live نتیجه را تأیید کنند.
- انتشار نسخه جدید ERP یا CRM؛
- Upgrade سازمانی ServiceDesk Plus؛
- مهاجرت Database یا زیرساخت؛
- Rollout یک Agent یا Client روی تعداد زیادی Endpoint؛
- تغییراتی که UAT و برنامه Rollback جدی میخواهند.
مراحل Release در ServiceDesk Plus
در مستندات رسمی ServiceDesk Plus Cloud، Release Management با ۹ مرحله اصلی معرفی میشود: Submission، Planning، Development، Testing، UAT، Deployment، Training، Review و Closure. لازم نیست هر سازمان این مراحل را عیناً و با همان جزئیات اجرا کند، اما منطق آنها برای جداسازی تصمیم، ساخت، آزمون و تحویل بسیار مفید است.
| مرحله | خروجی مورد انتظار |
|---|---|
| Submission | تعریف Release و Scope |
| Planning | زمانبندی، Owner، وابستگیها و Rollback |
| Development | ساخت یا آمادهسازی Package |
| Testing | تأیید فنی و رفع Defect |
| UAT | تأیید کسبوکار یا کاربران کلیدی |
| Deployment | استقرار کنترلشده |
| Training | آمادهسازی تیم پشتیبانی و کاربر |
| Review | بررسی نتیجه و Lessons Learned |
| Closure | بستن رسمی پس از تأیید نتیجه |
Release را به Changeهای واقعی متصل کنید
یک Release نباید به سند مستقلی تبدیل شود که ارتباطش با Changeهای تأییدشده معلوم نیست. اگر Release شامل سه Change است، باید بتوانید از Release به هر سه Change و از Change به Release برگردید. برای تفکیک انواع تغییر نیز مقاله Standard، Normal و Emergency Change مکمل این راهنماست.
Rollback Plan باید قبل از Deployment آماده باشد
عبارت «در صورت خطا برمیگردانیم» Rollback Plan نیست. برنامه بازگشت باید Trigger، مسئول، Backup، ترتیب بازگشت و زمان تقریبی بازیابی را مشخص کند. برای Database Migration ممکن است نقطه بازگشت با Snapshot یا Backup تعریف شود؛ برای Software Rollout ممکن است نسخه قبلی Package نگهداری شود.
UAT را با Test فنی یکی نگیرید
تیم فنی میتواند بگوید نسخه نصب میشود و Error ندارد؛ اما واحد مالی باید بگوید فرآیند صدور فاکتور بعد از Release همچنان درست است. UAT باید روی سناریوهای کسبوکاری کلیدی متمرکز باشد، نه تکرار تست فنی.
نقشها را از قبل مشخص کنید
| نقش | مسئولیت نمونه |
|---|---|
| Release Manager | هماهنگی کل Release و عبور از Stageها |
| Change Owner | مالک Changeهای مرتبط |
| Technical Owner | Build و Deployment |
| Business Owner | UAT و پذیرش کسبوکار |
| Service Desk | آمادگی برای Incidentهای پس از انتشار |
پس از Deployment چه چیزی را اندازه بگیریم؟
- درصد Releaseهای موفق بدون Rollback؛
- تعداد Incidentهای ایجادشده پس از Release؛
- درصد Releaseهای تحویلشده در Window برنامهریزیشده؛
- Defectهای کشفشده پس از Production؛
- تعداد Emergency Fixهایی که بعد از Release لازم شدهاند.
اگر Release باعث Incident تکراری شود، مسیر RCA و Problem Management باید ادامه ماجرا را پوشش دهد.
منبع رسمی
سخن پایانی
Release Management زمانی ارزشمند است که بین Approval یک Change و ورود واقعی آن به Production پل بسازد. هدف اضافهکردن فرم و مرحله نیست؛ هدف این است که Build، Test، UAT، Deployment و Review قابل رهگیری باشند و تیم بتواند در صورت شکست سریع و کنترلشده بازگردد.
مدانت خدمات طراحی Change و Release Management، پیادهسازی Workflow، ارتقا، مهاجرت، آموزش و پشتیبانی ServiceDesk Plus ارائه میکند. برای بررسی سناریوی سازمان، از مرکز تخصصی ServiceDesk Plus مدانت یا تماس با مدانت شروع کنید.

ServiceDesk Plus