نقطه شروع را ثبت کنید
وقتی بسته سورس‌کد می‌رسد، پیش از شروع سفارشی‌سازی یک نسخه دست‌نخورده را حفظ کنید و انتشار تحویل‌داده‌شده را شناسایی کنید. نسخه اپلیکیشن، مانیفست‌های وابستگی، وضعیت مهاجرت پایگاه داده و دستورالعمل‌های نصب استفاده‌شده را ثبت کنید. تأیید کنید کدام سرویس‌های پشتیبان جزو تحویل هستند و کدام جداگانه تأمین می‌شوند. اعتبارنامه‌ها را از آرشیو سورس بیرون نگه دارید و به‌جای آن نام‌های پیکربندی‌شان را مستند کنید. این خط مبنا به تیم شما امکان می‌دهد نقص تأمین‌کننده را از تغییرات بعدی تشخیص دهد و محیط را برای پشتیبانی بازتولید کند. پوشه‌ای با نام latest سابقه قابل اتکایی برای انتشار نیست. به هر بیلد مستقرشده شناسه‌ای بدهید که بتوان آن را تا سورس واقعی‌اش ردیابی کرد.
کارهای سفارشی را قابل فهم نگه دارید
هر سفارشی‌سازی را با نیاز مشتری که برآورده می‌کند توضیح دهید، نه فقط با فایل‌هایی که تغییر می‌دهد. تا جایی که عملی است، برندینگ و پیکربندی را از تغییرات رفتار هسته جدا کنید. سابقه کوتاهی از افزونه‌ها یا توسعه‌هایی نگه دارید که به بخش‌های مشترک مانند مجوزهای حساب، وضعیت پرداخت یا پردازش پس‌زمینه دست می‌زنند. هنگام رسیدن یک انتشار بالادستی، این بخش‌ها به توجه بیشتری نیاز دارند؛ چون دو تغییر که هرکدام به‌تنهایی منطقی‌اند ممکن است با هم تعارض پیدا کنند. پیش از ادغام، تغییرات تأمین‌کننده را با فرض‌های خودتان مقایسه کنید و تصمیم بگیرید کدام نسخه از هر رفتار مدنظر است. آن تصمیم را کنار کد حفظ کنید تا نگه‌دارندگان آینده مجبور نباشند آن را از یک ادغامِ بی‌توضیح بازسازی کنند.
به‌روزرسانی‌ها را با داده‌های نماینده تمرین کنید
برنامه به‌روزرسانی باید هم تغییرات کد برنامه و هم تغییرات داده را پوشش دهد. نسخه کاندید انتشار را در محیطی جداگانه و با داده‌های نماینده و به‌درستی محافظت‌شده آزمایش کنید، نه با کپی‌کردن رکوردهای نامحدودِ تولید روی یک ماشین توسعه. مهاجرت‌ها، کارهای پس‌زمینه، نشست‌های مشتریان و مسیرهای عملیاتیِ متأثر از تغییر را بررسی کنید. مشخص کنید پیش از جابه‌جایی نسخه، کارهای در حال انجام چگونه متوقف یا تخلیه شوند. روش بازیابی در صورت شکست استقرار را توضیح دهید و بررسی کنید آیا تغییر پایگاه‌داده واقعاً قابل بازگشت هست یا نه. بازگرداندن کد قدیمی‌تر، داده‌های قدیمی‌تر را به‌طور خودکار برنمی‌گرداند. نسخه‌های پشتیبان و رویه بازیابیِ تمرین‌شده را هم‌راستا با برنامه استقراری نگه دارید که قصد استفاده از آن را دارید.
انتشار نسخه‌ها را به مسئولیت‌های پشتیبانی وصل کنید
یادداشت انتشار بنویسید و در آن رفتارهای تغییرکرده، کارهای پیکربندی، محدودیت‌های شناخته‌شده و بررسی‌هایی را توضیح دهید که اپراتور باید انجام دهد. مشخص کنید چه کسی استقرار را تأیید می‌کند، چه کسی دوره نخست بهره‌برداری از آن را زیر نظر می‌گیرد و مشکلات کجا ثبت می‌شوند. پرسش‌های مربوط به بسته اصلی را از پرسش‌های ناشی از توسعه سفارشی جدا کنید، اما شواهد کافی برای بررسی هر دو را نگه دارید. درباره دامنه پشتیبانی و دسترسی به به‌روزرسانی‌هایی که واقعاً در خرید لحاظ شده‌اند توافق کنید؛ این موارد را از مالکیت سورس‌کد نتیجه‌گیری نکنید. محصول نگهداشت‌پذیر با تاریخچه انتشار و تصمیم‌های تکرارپذیر پشتیبانی می‌شود. هدف این است که ارزیابی به‌روزرسانی بعدی آسان‌تر شود، نه اینکه هر ارتقا به یک تحقیق تازه تبدیل شود.