نگهداری افزونه اختصاصی بعد از انتشار؛ برنامه به‌روزرسانی و امنیت
نگهداری افزونه اختصاصی یعنی نسخه‌ها و وابستگی‌ها را پایش کنید، تغییر را ابتدا روی staging بیازمایید، پیش از انتشار پشتیبان قابل بازیابی داشته باشید و سناریوهای حیاتی را پس از هر تغییر دوباره اجرا کنید. مسئول بررسی، زمان واکنش به اصلاح امنیتی و مسیر بازگشت باید از زمان تحویل مشخص باشند؛ انتشار نسخه اول، پایان چرخه افزونه نیست.
پیش از هر چیز، مسئولیت‌ها را مکتوب کنید
«پشتیبانی افزونه» عبارت دقیقی نیست. مشخص کنید چه کسی اعلان‌های امنیتی و نسخه‌های وردپرس، ووکامرس، PHP و کتابخانه‌های افزونه را دنبال می‌کند؛ چه کسی تغییر را می‌سازد و تأیید می‌کند؛ چه کسی نسخه را روی سایت اصلی منتشر می‌کند؛ و در خطای خارج از ساعت کاری چه مسیری وجود دارد. مالک کسب‌وکار، مدیر سایت و توسعه‌دهنده ممکن است مسئولیت‌های متفاوتی داشته باشند.
| رویداد | اقدام لازم | خروجی قابل ثبت |
|---|---|---|
| انتشار امنیتی | ارزیابی اثر و اولویت، سپس آزمون اصلاح | نسخه متاثر، تصمیم و زمان انتشار |
| به‌روزرسانی وردپرس یا ووکامرس | آزمون سناریوهای افزونه روی staging | نسخه‌ها و نتیجه آزمون |
| تغییر API بیرونی | بررسی قرارداد داده، احراز هویت و خطاها | تغییر نگاشت و برنامه مهاجرت |
| خطای عملیاتی | ثبت نمونه، دامنه اثر و راه بازتولید | گزارش رخداد و اقدام اصلاحی |
یک شناسنامه فنی زنده نگه دارید
شماره نسخه افزونه، نسخه‌های پشتیبانی‌شده PHP و وردپرس، وابستگی‌ها، سرویس‌های بیرونی، cronها، webhookها، جدول‌های پایگاه داده و محل تنظیمات را ثبت کنید. برای افزونه ووکامرس، وضعیت آزمون HPOS، Checkout Blocks، درگاه‌ها و هر مسیر سفارشی سفارش نیز باید معلوم باشد. شناسنامه با هر نسخه تغییر می‌کند و نباید فقط در ذهن سازنده باقی بماند.
چرخه منظم و مسیر فوری را از هم جدا کنید
برای بازبینی عادی، یک زمان‌بندی متناسب با حساسیت سایت تعیین کنید؛ اما اصلاح امنیتی یا خرابی قابلیت حیاتی نباید تا نوبت بعدی صبر کند. مستندات WooCommerce برای بیشتر فروشگاه‌ها بازبینی ماهانه به‌روزرسانی‌ها را نقطه شروع مناسبی می‌داند و برای اصلاح امنیتی، اقدام زودتر را توصیه می‌کند. این عدد قانون همه پروژه‌ها نیست؛ فروشگاه پرتراکنش یا اتصال حساس ممکن است پایش بیشتری بخواهد.
قبل از به‌روزرسانی چه چیزهایی را بررسی کنیم؟
- تغییرات را بخوانید: release note هسته، ووکامرس، کتابخانه یا API مرتبط را با بخش‌های مورد استفاده افزونه تطبیق دهید.
- پشتیبان قابل بازیابی بگیرید: فایل و پایگاه داده هر دو مهم‌اند. وجود فایل پشتیبان بدون آزمون بازیابی، تضمین بازگشت نیست.
- staging را به وضعیت واقعی نزدیک کنید: نسخه‌ها و تنظیمات مهم مشابه باشند، اما ارسال ایمیل، پیامک، پرداخت و webhook واقعی کنترل شود تا آزمون رخداد بیرونی نسازد.
- همان مجموعه نسخه‌ها را آزمایش کنید: ترکیبی را تست کنید که قرار است منتشر شود؛ چند تغییر بزرگِ آزمون‌نشده را هم‌زمان وارد سایت اصلی نکنید.
مجموعه آزمون رگرسیون کوچک اما واقعی بسازید
آزمون باید از قابلیت افزونه بیاید، نه از یک فهرست عمومی. برای هر سناریو، ورودی، اقدام، نتیجه مورد انتظار و محل مشاهده نتیجه را ثبت کنید. مسیر موفق، ورودی نامعتبر، دسترسی ناکافی، اجرای تکراری و قطع سرویس بیرونی را به تناسب ریسک پوشش دهید.
مثال فرضی برای افزونه اتصال سفارش: ساخت سفارش آزمایشی نباید دو رکورد مقصد ایجاد کند؛ لغو باید طبق قاعده توافق‌شده منتقل شود؛ قطع API باید خطای قابل پیگیری بسازد؛ و تلاش مجدد نباید داده را تکراری کند. این مثال گزارش یک پروژه انجام‌شده نیست.
بازبینی امنیت فقط نصب افزونه امنیتی نیست
در تغییرات کد، کنترل سطح دسترسی، nonce برای درخواست‌های مدیریتی، اعتبارسنجی و پاک‌سازی ورودی و escape متناسب با محل خروجی را بررسی کنید. کلیدهای API نباید در مخزن عمومی، لاگ قابل دانلود یا کد مرورگر قرار گیرند. دسترسی کاربر یا سرویس را تا حد لازم محدود و دسترسی‌های موقت را پس از تحویل حذف کنید.
nonce جای کنترل مجوز را نمی‌گیرد و پاک‌سازی ورودی نیز جای escape خروجی نیست؛ هر کدام وظیفه جداگانه دارند. راهنمای امنیت افزونه وردپرس این کنترل‌ها را به‌صورت مستقل توضیح می‌دهد.
انتشار را مرحله‌بندی و قابل بازگشت کنید
- نسخه و فهرست تغییرات را پیش از انتشار ثبت کنید.
- زمانی منتشر کنید که فرد مسئول بتواند سناریوهای حیاتی را بلافاصله بررسی کند.
- علامت توقف و بازگشت را از قبل تعیین کنید؛ مثلاً شکست پرداخت یا توقف همگام‌سازی.
- بدانید بازگرداندن فایل افزونه لزوماً داده مهاجرت‌شده یا پیام ارسال‌شده به سرویس بیرونی را برنمی‌گرداند.
- پس از انتشار، خطاهای PHP، scheduled actions، گزارش افزونه و رفتار واقعی سناریوهای اصلی را پایش کنید.
چه زمانی یک نسخه یا خود افزونه به پایان پشتیبانی می‌رسد؟
پایان پشتیبانی باید اعلام‌شده باشد، نه نتیجه غیرفعال‌شدن ناگهانی توسعه‌دهنده. نسخه‌های پشتیبانی‌شده، مهلت مهاجرت، روش خروجی داده و جایگزین احتمالی را مشخص کنید. اگر افزونه دیگر ارزش نگهداری ندارد، برنامه خروج شامل توقف ورودی جدید، انتقال داده، حذف امن دسترسی‌ها و مستندسازی وضعیت نهایی است.
چک‌لیست برنامه نگهداری
- مالک فنی و مسیر گزارش خطا مشخص است.
- نسخه‌ها، وابستگی‌ها و نقاط اتصال فهرست شده‌اند.
- برنامه بازبینی منظم و مسیر جداگانه اصلاح فوری وجود دارد.
- staging، پشتیبان و روش بازیابی قابل استفاده‌اند.
- سناریوهای رگرسیون و معیار قبولی نوشته شده‌اند.
- انتشار، پایش و بازگشت مسئول مشخص دارند.
- دامنه پشتیبانی و شرایط پایان آن مکتوب است.
منابع فنی
- راهنمای امنیت افزونه وردپرس
- بررسی سطح دسترسی کاربران
- نگهداری افزونه‌های ووکامرس
- راهنمای به‌روزرسانی و آزمون WooCommerce
اگر هنوز اقلام نسخه اول و مسئولیت‌ها را تحویل نگرفته‌اید، ابتدا چک‌لیست تحویل افزونه اختصاصی را مرور کنید. برای تعریف دامنه ساخت یا نگهداری، خدمت توسعه افزونه اختصاصی وردپرس و سپس فرم تماس را ببینید.
اگر چند نفر با فروشگاه کار می‌کنند، راهنمای تعیین سطح دسترسی کارکنان ووکامرس و آزمون نقش‌های اختصاصی را ببینید.
اگر اجرای خودکار یا ارسال داده عقب افتاده، راهنمای بررسی کارهای زمان‌بندی‌شدهٔ ووکامرس به تشخیص وضعیت صف، خطای عملیات و تعریف معیار آزمون کمک می‌کند.