پاسخ کوتاه
تحویل کامل حداقل شامل مخزن و نسخه نهایی سورسکد، ساختار و نسخه پشتیبان دیتابیس، روش Build و استقرار، دسترسی حسابهای زیرساختی، فهرست سرویسها و لایسنسها، مستندات عملیاتی، نتایج تست و فهرست موارد باز است. رمزها نباید در ایمیل یا صورتجلسه نوشته شوند؛ حسابها و Secretها باید از مسیر امن به مالکیت کارفرما منتقل یا چرخانده شوند.
تحویل کامل نرمافزار چه بخشهایی دارد؟
تحویل را در پنج بسته ببینید: داراییهای کد، داده، زیرساخت، دانش و امور قراردادی. نبود هرکدام میتواند ادامه کار را متوقف کند؛ حتی اگر سامانه فعلاً روی سرور قبلی در حال اجرا باشد.
کد
- اقلام اصلی
- مخزن، تاریخچه، Tag نسخه، وابستگیها و اسکریپت Build
- آزمون قابل قبول
- ساخت نسخه از یک Clone تازه
داده
- اقلام اصلی
- Schema، Migration، Backup، فرهنگ داده و سیاست نگهداری
- آزمون قابل قبول
- بازیابی نسخه پشتیبان در محیط کنترلشده
زیرساخت
- اقلام اصلی
- دامنه، DNS، سرور، CI/CD، ذخیرهسازی، مانیتورینگ و گواهیها
- آزمون قابل قبول
- انتشار آزمایشی و مشاهده سلامت سرویس
دانش
- اقلام اصلی
- معماری، راهاندازی، عملیات روزانه، خطاهای متداول و راهنمای کاربر
- آزمون قابل قبول
- اجرای یک سناریو توسط فردی خارج از تیم سازنده
قراردادی
- اقلام اصلی
- محدوده، مالکیت، مجوزها، موارد باز، ضمانت و پشتیبانی
- آزمون قابل قبول
- صورتجلسه امضاشده با پیوست دقیق
چکلیست سورسکد و فرایند ساخت
فقط شاخه اصلی کافی نیست. نسخهای که روی محیط نهایی نصب شده باید با Tag یا شناسه Commit مشخص باشد. وابستگیهای خصوصی، Registry پکیجها، Submoduleها و ابزارهای لازم برای Build نیز باید فهرست شوند.
انتقال یک Repository به حساب سازمانی، تاریخچه، Issueها و Releaseها را بهتر از ارسال فایل پراکنده حفظ میکند. پس از انتقال، دسترسی افراد قبلی باید بازبینی و حسابهای ضروری تیم جدید اضافه شوند.
- آدرس مخزن و مالک سازمانی آن
- شاخه اصلی، سیاست Merge و Tag نسخه نهایی
- README شامل پیشنیازها، Build، Test و Run
- نسخه Runtime، SDK، Package Manager و وابستگیهای خصوصی
- اسکریپتهای CI/CD و وضعیت آخرین Pipeline
- فهرست بدهی فنی، خطاهای شناختهشده و قابلیتهای نیمهتمام
دیتابیس و اطلاعات را قابل بازیابی تحویل بگیرید
وجود فایل Backup بدون آزمون Restore تضمین نمیکند اطلاعات قابل استفادهاند. نوع موتور و نسخه، Collation یا Encoding، افزونهها، حساب سرویس، زمان آخرین Backup و روش بازیابی باید ثبت شوند.
- نسخه پشتیبان رمزگذاریشده با تاریخ و دامنه اطلاعات مشخص
- اسکریپتهای ایجاد Schema و Migrationهای اجراشده
- فرهنگ داده برای جدولها و فیلدهای کسبوکاری مهم
- فهرست Jobها، Viewها، Stored Procedureها و اتصالهای بیرونی
- سیاست نگهداری، حذف، آرشیو و سطح دسترسی اطلاعات
- نتیجه Restore آزمایشی و کنترل تعداد رکوردهای حیاتی
دسترسیها و Secretها را چگونه منتقل کنیم؟
فهرستی از مالک حساب، سطح دسترسی و روش بازیابی برای دامنه، DNS، Hosting، Cloud، ایمیل، پیامک، درگاه پرداخت، مخزن کد، فروشگاه اپلیکیشن و سامانه مانیتورینگ تهیه کنید. حساب شخصی توسعهدهنده نباید تنها مالک دارایی حیاتی باشد.
رمزها، Tokenها و کلیدهای API را داخل سند تحویل، پیامرسان یا مخزن کد قرار ندهید. پس از انتقال مالکیت، آنها را از طریق Secret Manager یا مسیر امن جایگزین کنید و دسترسیهای بلااستفاده را لغو کنید.
دامنه و DNS
- مالک مطلوب
- حساب سازمانی کارفرما
- اقدام هنگام تحویل
- تأیید مالک و اطلاعات بازیابی
مخزن و CI/CD
- مالک مطلوب
- Organization کارفرما
- اقدام هنگام تحویل
- انتقال، بازبینی اعضا و Branch protection
Cloud و سرور
- مالک مطلوب
- Tenant یا حساب سازمانی
- اقدام هنگام تحویل
- تعریف نقش حداقلی و حذف حسابهای موقت
API و سرویس ثالث
- مالک مطلوب
- حساب سازمانی یا قرارداد مشخص
- اقدام هنگام تحویل
- چرخش کلید و ثبت محدودیت و هزینه
استقرار، مانیتورینگ و بازگشت نسخه را آزمایش کنید
تحویل زمانی عملیاتی است که تیم بعدی بداند تغییر چگونه از محیط توسعه به آزمایش و Production میرسد. تفاوت تنظیمات محیطها، تأیید لازم برای انتشار، محل مشاهده Log و Alert و راه Rollback باید مستند باشد.
- نقشه محیطهای Development، Staging و Production
- فرایند انتشار خودکار یا دستی و افراد مجاز
- Health Check، Log، Metric و Alertهای حیاتی
- برنامه Backup و نتیجه آخرین آزمون بازیابی
- روش Rollback یا Roll-forward در انتشار ناموفق
- راهنمای Incident و اطلاعات تماس پشتیبانی
صورتجلسه تحویل باید چه چیزهایی را ثبت کند؟
صورتجلسه جای چکلیست فنی را نمیگیرد؛ خلاصه میکند چه نسخهای، در چه تاریخی و با چه پیوستهایی تحویل شده است. موارد باز، مهلت رفع، وضعیت پذیرش و شروع دوره ضمانت یا پشتیبانی باید بدون عبارتهای کلی ثبت شوند.
- نام پروژه، نسخه، Commit یا Release تحویلی
- فهرست پیوستها و محل امن نگهداری آنها
- نتیجه Build، Restore، Deploy و UAT
- موارد باز، شدت، مسئول و موعد توافقشده
- تاریخ شروع ضمانت، پشتیبانی و سطح خدمت
- تأیید نماینده فنی و نماینده کسبوکار
نکته: این راهنما مشاوره حقوقی نیست. تعریف مالکیت مادی و معنوی سورسکد، حق تغییر، استفاده مجدد و مجوز اجزای ثالث باید با قرارداد و مشاور حقوقی شما تطبیق داده شود.
پرسشهای متداول
آیا کارفرما همیشه باید مالک کامل سورسکد باشد؟
پاسخ به قرارداد، نوع محصول و اجزای از پیش موجود بستگی دارد. اما حق دسترسی، استفاده، تغییر، نگهداری و شرایط خروج باید صریح باشد؛ برای متن حقوقی از مشاور متخصص کمک بگیرید.
فایل ZIP سورسکد برای تحویل کافی است؟
معمولاً خیر. تاریخچه تغییرات، نسخه دقیق Production، وابستگیها، Pipeline و Issueهای باز در فایل ZIP از بین میروند. مخزن قابل انتقال همراه با آزمون Build گزینه مطمئنتری است.
آیا رمز سرور را داخل صورتجلسه بنویسیم؟
خیر. صورتجلسه فقط تحویل دسترسی را ثبت کند. رمز و کلید باید با روش امن منتقل و سپس چرخانده شود.
مهمترین آزمون قبل از پایان همکاری چیست؟
یک Dry Run که طی آن فردی خارج از تیم قبلی، با مستندات تحویلی نسخه را Build و Deploy و یک Backup را Restore کند، وابستگیهای پنهان را آشکار میکند.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.