في المقالة الأخيرة، تناولت كيفية العثور على الأجزاء البطيئة في SaaS وإصلاحها قبل الإطلاق: استعلامات N+1، والفهارس المفقودة، والحمولات غير المحدودة، والمشتبه بهم المعتادين. هذا العمل يجعل المنتج سريعًا. لا يذكر شيئًا عما إذا كان المنتج جاهزًا بالفعل للتشغيل دون مراقبة، في الساعة 3 صباحًا، عندما يحدث خطأ ما.
هذه هي المقالة الختامية للوحدة 4 في Full Stack SaaS Masterclass، والمقصود منها أن تكون بمثابة قائمة مرجعية تمر بها قبل تشغيل المفتاح عند التشغيل الحقيقي، وليس برنامجًا تعليميًا تتبعه مرة واحدة ثم تنساه. كل عنصر فيه هو شيء رأيته تم تخطيه في الإصدار الأول، وكل تخطي أصبح في النهاية حادثًا.
"جاهز للإنتاج" لا يعني أنه مطلي بالذهب. هذا يعني أن الفجوات التي تحول خطأً بسيطًا إلى انقطاع لعدة ساعات قد تم إغلاقها، والفجوات المتبقية هي الفجوات التي قبلتها بوعي بدلاً من الفجوات التي لم يفكر فيها أحد. هذا التمييز هو بيت القصيد من القائمة المرجعية: فهو يفرض الجزء الواعي.
خطأ الإطلاق الأول الأكثر شيوعًا ليس خطأً برمجيًا. إنه تكوين يتصرف بهدوء بشكل مختلف عما افترضه الجميع. ملف .env يحتوي على بيانات اعتماد الإنتاج التي تم تنفيذها عن طريق الصدفة. لقد تركت سياسة CORS مفتوحة على مصراعيها لأنها كانت أسهل أثناء التطوير. حجم تجمع اتصال قاعدة البيانات مناسب للكمبيوتر المحمول، وليس لحركة المرور المتزامنة.
قبل الإطلاق، قم بالتعرف على كل متغير بيئة يقرأه تطبيقك وتأكد من ثلاثة أشياء: أن له قيمة حقيقية في الإنتاج، وأن هذه القيمة تأتي من مدير الأسرار بدلاً من ملف نص عادي في الريبو، وأن هناك احتياطيًا موثقًا (أو فشلًا فادحًا) إذا كان مفقودًا.
إن توصيل هذا إلى ConfigModule الخاص بـ NestJS عند bootstrap يعني أن السر المفقود أو المشوه يفشل في النشر. لا يفشل بصمت في الساعة الثانية ظهرًا يوم الثلاثاء عندما يصل العميل إلى مسار الكود الوحيد الذي يلمسه. تتمثل المقايضة في إعداد مطور محلي أكثر صرامة قليلاً، نظرًا لأن كل متغير بيئة جديد يحتاج الآن إلى إدخال مخطط. هذه تكلفة تستحق الدفع. المخطط الذي ينحرف عن الواقع هو عبارة عن خطأ ينتظر أن يكتشفه المستخدم، وليس بواسطة CI.