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