رفتن به محتوای اصلی
MedaNet
شرکت مدانت مجری تخصصی پیاده‌سازی، آموزش و پشتیبانی راهکارهای فناوری اطلاعات
راهنمای ServiceDesk Plus | دانش و تجربه اجرایی

Release Management در ServiceDesk Plus؛ از Change تأییدشده تا Build، Test و Deployment کنترل‌شده

شرکت مدانت

یک 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 مدانت یا تماس با مدانت شروع کنید.

22