كيف تُعد بيئة staging لتطبيقك

لإعداد بيئة staging، انشر نسخة ثانية من تطبيقك على رابط خاص بها، وامنحها قاعدة بيانات ومفاتيح واجهة اختبار خاصة بها، واجعل إعدادها مطابقاً للإنتاج قدر الإمكان. ثم أطلق كل تغيير مهم على بيئة staging أولاً، ومرّ على التدفقات المهمة، ولا تنشر على الإنتاج إلا عندما تبدو بيئة staging سليمة.

إذا كانت الفكرة جديدة عليك، فإن ما هي بيئة staging يشرح المفهوم. أما هذا الدليل فهو الإعداد العملي، ومكتوب للأشخاص الذين يبنون بأدوات الذكاء الاصطناعي وليس لفرق DevOps.

التطوير وStaging والإنتاج

معظم التطبيقات الصغيرة تحتاج إلى ثلاثة أماكن، حتى لو كان الأول مجرد معاينة أداة البناء لديك:

الغاية من staging أن تتصرف مثل الإنتاج، بالكود نفسه والبنية نفسها ونوع الإعدادات نفسه، لكن الخطأ فيها لا يضر أحداً.

الخطوة 1: قرر ما الذي يجب أن تطابقه بيئة staging

بيئة staging مفيدة فقط إذا ظهرت المشكلات فيها قبل أن تظهر في الإنتاج. طابِق:

• الكود نفسه، ويُطلق بالطريقة نفسها.
• البنية والإصدارات نفسها، أي الإطار وبيئة التشغيل ونوع قاعدة البيانات.
• نوع الإعدادات نفسه، أي أسماء متغيرات البيئة نفسها، مع قيم اختبار.
• الخدمات نفسها، فإن كان للإنتاج تطبيق ويب وواجهة برمجية، فلتكن لبيئة staging الاثنان.

ويمكن أن تختلف في الحجم (جهاز أصغر لا بأس به) وفي البيانات.

الخطوة 2: أنشئ النسخة

أبسط طريقة: نشر ثانٍ للمشروع نفسه، على رابط مختلف مثل staging.yourapp.com أو yourapp-staging.example.com.

وكيفية ذلك تعتمد على مضيفك:

• المضيفون الذين يوفرون نشر معاينة أو staging مدمجاً يمكنهم إنشاء واحدة تلقائياً لفرع Git.
• المضيفون الذين لا يوفرون ذلك: أنشئ تطبيقاً أو مشروعاً ثانياً من الكود نفسه، وانشره بشكل منفصل.
• الكود في Git: احتفظ بفرع staging أو main يُنشر على بيئة staging، وانشر على الإنتاج من إصدار. انظر كيف تستخدم Git مع تطبيق بناه الذكاء الاصطناعي.

الخطوة 3: امنح بيئة staging قاعدة بيانات خاصة بها

هذه الخطوة هي التي تحميك. فإذا تشاركت بيئة staging والإنتاج قاعدة البيانات نفسها، فإن اختباراً يحذف السجلات سيحذف سجلات حقيقية.

• أنشئ قاعدة بيانات منفصلة لبيئة staging.
• املأها بـ بيانات أولية (seed)، أي سجلات وهمية واقعية يمكن للذكاء الاصطناعي توليدها لك.
• إذا احتجت إلى نسخة من بيانات الإنتاج، فاحذف الأسماء والبريد الإلكتروني وأي شيء شخصي أو اخلطه أولاً.

اكتب سكربت بيانات أولية يملأ قاعدة بيانات فارغة ببيانات اختبار واقعية: 20 عميلاً، و50 طلباً في حالات مختلفة، ومستخدمَي مشرف. استخدم أسماء وهمية واضحة وعناوين بريد من النطاق example.com.

قبل أن تثق بالإعداد، تأكد من قاعدة البيانات التي تتصل بها كل نسخة. اسأل مباشرة:

ما قاعدة البيانات التي يتصل بها هذا التطبيق، ومن أين يأتي هذا الإعداد؟ أرني اسم المتغير، لا كلمة المرور.

الخطوة 4: استخدم مفاتيح اختبار وإعدادات منفصلة

كل ما يتصل بخدمة خارجية ينبغي أن يستخدم بيانات اعتماد اختبار في بيئة staging:

• المدفوعات في وضع الاختبار (مفاتيح Stripe للاختبار مثلاً)، حتى لا يُخصم من أي بطاقة حقيقية.
• البريد الإلكتروني يُرسل إلى بيئة تجريبية (sandbox) أو إلى عنوانك وحدك، فلا يتلقى العملاء رسالة اختبار أبداً.
• الذكاء الاصطناعي وواجهات برمجة التطبيقات المدفوعة الأخرى بمفتاح منفصل وحد إنفاق منخفض.
• Webhooks موجّهة إلى رابط staging، لا إلى الإنتاج.

أبقِ أسماء المتغيرات نفسها في البيئتين، ولا تغيّر إلا القيم. بهذه الطريقة لا يحتاج الكود إلى معرفة المكان الذي يعمل فيه. لمزيد من التفاصيل، انظر كيف تحافظ على أمان مفاتيح واجهات البرمجة.

الخطوة 5: أبقِ بيئة staging خاصة

لا ينبغي أن تكون بيئة staging عامة:

• ضعها خلف تسجيل دخول، أو كلمة مرور، أو قائمة سماح بعناوين بريد الفريق.
• امنع محركات البحث من فهرستها باستخدام وسم meta من نوع noindex أو ترويسة X-Robots-Tag.
• لا تضع رابطاً إليها من موقعك العام.
• اجعلها تبدو مختلفة؛ فشريط ملوّن يكتب "STAGING" يمنع الاختبار في التبويب الخطأ.

أضف شريطاً أصفر لافتاً في أعلى كل صفحة يقول "STAGING — بيانات اختبار فقط" عندما يكون متغير البيئة APP_ENV مساوياً لـ "staging". وأضف في هذه الحالة وسم noindex أيضاً.

الخطوة 6: ضع روتيناً للإطلاق

لا تفيد بيئة staging إلا إذا استخدمتها في كل مرة. روتين بسيط:

1. أجرِ التغيير في بيئة التطوير وتحقق منه في المعاينة.
2. أطلقه على بيئة staging.
3. مرّ على تدفقاتك الأساسية: التسجيل، وتسجيل الدخول، والميزة الرئيسية، والمدفوعات، وأي شيء لمسه التغيير.
4. إذا تعطل شيء، فأصلحه وأطلق على بيئة staging مرة أخرى.
5. انشر النسخة نفسها على الإنتاج.
6. تحقق من الإنتاج بسرعة: التدفقات نفسها، ولفترة قصيرة.

اكتب التدفقات الأساسية كنص اختبار قصير. انظر كيف تختبر تطبيقك قبل الإطلاق لمعرفة ما ينبغي تضمينه.

الخطوة 7: تعامل مع تغييرات قاعدة البيانات بحذر

تغييرات بنية قاعدة البيانات، مثل إضافة عمود أو إعادة تسمية جدول، هي المكان الذي تثبت فيه بيئة staging قيمتها.

• شغّل كل تغيير هيكلي على بيئة staging أولاً.
• تحقق من بقاء البيانات الموجودة سليمة، لا من أن الميزات الجديدة تعمل فقط.
• خذ نسخة احتياطية من الإنتاج قبل تشغيل التغيير نفسه هناك. انظر كيف تنسخ قاعدة بيانات تطبيقك احتياطياً.
• فضّل التغييرات التي تضيف على تلك التي تعيد التسمية أو تحذف، حتى تعمل النسخة القديمة إذا تراجعت.

أمثلة على الطلبات

اشرح ما الذي سيحدث للبيانات الموجودة إذا شغّلنا تغيير قاعدة البيانات هذا على الإنتاج. هل يُحذف شيء أو يُعاد تسميته؟

اجعل كل الإعدادات الخاصة بكل بيئة، مثل عناوين واجهات البرمجة، والمفاتيح، ومرسل البريد، والرابط الخاص بالموقع، تأتي من متغيرات البيئة بالأسماء نفسها في staging والإنتاج. اسردها لي.

اكتب قائمة تحقق قصيرة بالتدفقات التي ينبغي أن أختبرها على بيئة staging قبل كل إطلاق، بناءً على ما يفعله هذا التطبيق.

أخطاء شائعة

• قاعدة بيانات مشتركة. أكثر الأخطاء ضرراً. ينبغي أن تحصل بيئة staging دائماً على قاعدة بيانات خاصة بها.
• مفاتيح حية في staging. خصومات حقيقية، ورسائل بريد حقيقية إلى عملاء حقيقيين.
• انحراف staging عن الإنتاج. الإصدارات أو الإعدادات المختلفة تجعل staging يتوقف عن اكتشاف المشكلات.
• موقع staging عام ومفهرس يظهر في نتائج البحث بجانب موقعك الحقيقي.
• تخطي staging في التغييرات "الصغيرة". التغييرات الصغيرة تعطّل الأشياء أيضاً.
• الاختبار في التبويب الخطأ. الشريط الظاهر يحل هذه المشكلة.

قائمة تحقق

• تشغّل بيئة staging الكود نفسه والبنية نفسها والخدمات نفسها كالإنتاج.
• لبيئة staging قاعدة بيانات خاصة بها، فيها بيانات اختبار أو بيانات منقّحة.
• تستخدم المدفوعات والبريد الإلكتروني وواجهات البرمجة المدفوعة مفاتيح اختبار في staging.
• أسماء المتغيرات متطابقة بين البيئات، والقيم فقط مختلفة.
• بيئة staging خلف تسجيل دخول أو كلمة مرور، وغير مفهرسة.
• يظهر شريط عند وجودك في بيئة staging.
• كل إطلاق يمر على staging أولاً، مع قائمة مكتوبة بالتدفقات المطلوب فحصها.
• تُشغّل تغييرات قاعدة البيانات على staging أولاً، مع نسخة احتياطية للإنتاج قبل الإطلاق.

Staging على Mythex

يمنحك Publish في Mythex رابطاً حياً واحداً لكل تطبيق؛ ولا يوجد مفتاح منفصل لـ staging. وعملياً لديك خياران:

• المعاينة كفحص ما قبل الإطلاق. كل مشروع يعمل في مساحة سحابية خاصة مع معاينة حية. يقوم الأمر /test بجعل الوكيل ينقر فيها كما يفعل المستخدم، ورابط Share يتيح لعميل أو زميل مراجعة المعاينة دون نشرها. انظر المعاينة والكود. وهذا يكفي كثيراً من المشاريع الفردية.
• مشروع ثانٍ كبيئة staging. في خطة Pro، صدّر المشروع واستورده إلى مشروع جديد، وامنح هذا المشروع قاعدة بيانات خاصة به ومفاتيح اختبار في الأسرار، وانشره بمعرّف خاص به. أطلق عليه أولاً قبل أن تنشر مشروع الإنتاج.

وفي الحالتين، اسأل الوكيل عن قاعدة البيانات التي تستخدمها المعاينة والتطبيق المنشور قبل إجراء أي اختبار مدمّر، واستخدم نقاط الاستعادة (checkpoints) للتراجع عن تغيير سيئ. ولمزيد عن نقل التطبيق إلى الإنتاج بشكل عام، انظر كيف تنقل نموذجاً أولياً بالذكاء الاصطناعي إلى الإنتاج.

الأسئلة