تطبيقات الويب

تطبيق الويب تطبيق تبنيه المنصّة من مستودع GitHub وتشغّله لك. ادفع إلى الفرع المتتبَّع فتصدر نسخة جديدة؛ وإن انكسرت، ارجع إلى الصورة نفسها التي كانت تعمل قبلها. وكل ما في هذه الصفحة موجود في لوحة التحكّم تحت تطبيقات الويب.

وتعمل تطبيقات الويب على نموذج العزل نفسه الذي تعمل عليه النسخ: كل تطبيق في حاوية خاصة به، ولا شيء مشترك مع مساحة عمل أخرى.

اربط GitHub أولاً

افتح صفحة التكاملات في مساحة عملك واربط GitHub. يثبّت ذلك تطبيق سحابتي على الحساب أو المؤسسة التي تختارها، ويمنح هذه المساحة وصولاً إلى المستودعات التي تحدّدها أنت — لا نحن — ويمكنك توسيع الاختيار أو تضييقه لاحقاً من الصفحة نفسها.

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

استورد مستودعاً

يعرض تطبيقات الويب ← نشر تطبيق المستودعات التي تستطيع أنت رؤيتها على GitHub ضمن التثبيت — تُقرأ بحسابك أنت على GitHub، فالمستودع الذي يشمله التثبيت ولا تستطيع فتحه على GitHub لا يُعرض ولا يُقبل. اختر واحداً واملأ:

• الفرع — فرع الإنتاج. الدفع إليه يُطلق نشراً.
• المجلد الجذر — المجلد الفرعي الذي يُبنى منه؛ اتركه ./ لجذر المستودع. وهذا هو الحقل الخاص بالمستودعات الأحادية (monorepo).
• النشر التلقائي — مفعّل افتراضياً؛ انظر النشر عند الدفع.
• اسم التطبيق — أحرف إنجليزية صغيرة وأرقام وشُرَط داخلية. يدخل ضمن رابط تطبيقك، فاختر اسماً تميّزه.
• الموارد المتصلة — اربط نسخاً من مساحة العمل، فيُضاف رابط اتصال كلٍّ منها متغيّرَ بيئة يشير إلى اسمها الخاص.
• متغيّرات البيئة — الإعدادات والأسرار التي يحتاجها تطبيقك. الصق ملف .env كاملاً في حقل مفتاح فتُضاف كل أسطره دفعة واحدة.

اضغط نشر فيبدأ البناء الأول فوراً. وإعدادات البناء في صفحة عام للتطبيق بعد إنشائه؛ اتركها فارغة ليكتشف النظام كل شيء.

رابط تطبيقك

يُقدَّم كل تطبيق ويب عبر HTTPS على اسم مضيف خاص به:

https://<اسم-التطبيق>-<لاحقة>.sahabti.app

واللاحقة القصيرة تجعل اسم المضيف فريداً على مستوى المنصّة، فيمكن لمساحتَي عمل أن تسمّيا تطبيقاً باسم web. ويظهر الرابط في صفحة التطبيق بمجرد إنشائه، ويفتحه زر زيارة.

ولتقديمه تحت نطاقك الخاص أيضاً، أضف اسم المضيف في صفحة النطاقات للتطبيق: تعرض سجل TXT يثبت ملكيتك للنطاق وسجل CNAME يوجّه اسم المضيف إلى المنصّة، وتصدر الشهادة من تلقاء نفسها. ويبقى الرابط الافتراضي يعمل.

كيف يجري البناء

تكتشف المنصّة بنية تطبيقك وتولّد البناء المناسب لها. الأطر المكتشَفة:

وثلاث طبقات تحدّد كيف يُبنى التطبيق، والأعلى منها يفوز دائماً:

1. sahabti.json في مستودعك — إعدادات بناء مُودعة إلى جانب الشيفرة.
2. إعدادات البناء في التطبيق — طبقة التجاوز في لوحة التحكّم: الإطار، وأوامر التثبيت والبناء والتشغيل، ومجلد المخرجات، ومسار Dockerfile.
3. الاكتشاف التلقائي — ما يجري حين لا تقول الطبقتان أعلاه شيئاً.

واختيار إطار Docker، أو تحديد مسار Dockerfile، يبني ملف Dockerfile الخاص بمستودعك — فلا تولّد المنصّة شيئاً. ومتغيّرات بيئتك ليست وسائط بناء أبداً، فأي ARG لا يتلقّى شيئاً من لوحة التحكّم؛ بل تصل إلى خطوات البناء سرّاً مركَّباً، فتبقى خارج طبقات الصورة. وتشرح إعدادات البناء ما يعنيه ذلك لملف Dockerfile تصونه بنفسك.

ويحصل كل تطبيق على حجم الحاوية القياسي في المنصّة. لا حجم تختاره ولا حجم تدفع ثمنه لكل تطبيق.

شاهد النشر

يسرد تبويب عمليات النشر كل بناء، الأحدث أولاً، ويتوسّع كل صفّ ليعرض سجل البناء الحيّ. وتمرّ عملية النشر بخمس خطوات:

1. استنساخ المستودع — عند الالتزام (commit) الذي أطلق النشر بالضبط.
2. اكتشاف الإطار — تحويل الطبقات الثلاث أعلاه إلى خطة بناء واحدة.
3. بناء الصورة — تُبنى الصورة بعيداً عن حاوية التطبيق وتُدفع إلى سجلّ المنصّة.
4. نشر الحاوية — تُشغَّل الصورة الجديدة إلى جانب القديمة، وعليها أن تجتاز فحص سلامة قبل أن تستلم. وإن لم تجتزه، تُستعاد النسخة السابقة ويُعلَّم النشر فاشلاً — ويبقى تطبيقك يعمل طوال الوقت.
5. حيّ — النسخة الجديدة تقدّم الخدمة.

والخطوة الفاشلة تُذكر بالاسم ومعها مخرجات البناء. وتُحفظ سجلات البناء 30 يوماً؛ وبعدها يحتفظ الصفّ بخطواته وحالته والتزامه، ويصير السجل «منتهي الصلاحية».

النشر عند الدفع

النشر التلقائي مفعّل افتراضياً. وكل دفعة إلى فرع الإنتاج تضع نشراً في الطابور بوسم دفعة Git، ويُطابَق على المستودع نفسه لا على اسمه — فإعادة تسمية المستودع في GitHub لا تكسر الارتباط.

وأطفئه من صفحة عام للتطبيق فيبقى الفرع متتبَّعاً: يظهر التطبيق بوسم تغييرات جديدة لم تُنشر حين يتقدّم الفرع على ما هو حيّ، وتنشر أنت حين تجهز.

إعادة النشر والتراجع والإلغاء

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

متغيّرات البيئة

تحوي صفحة البيئة للتطبيق المتغيّرات التي تُحقن فيه أثناء البناء وأثناء التشغيل. والقيم المعلّمة كأسرار مخفية في الواجهة. ويقبل الإضافة الجماعية كتلة KEY=value ملصوقة، متجاهلاً الأسطر الفارغة وأسطر التعليق #.

كل قيمة سطر واحد. يعمل JSON ما دام على سطر واحد (مفتاح حساب خدمة مثلاً — تصل علامات الاقتباس والأقواس إلى الحاوية كما كُتبت تماماً)؛ أما JSON المنسّق على عدة أسطر ومفاتيح PEM متعدّدة الأسطر فتُرفض بدلاً من أن تُقتطع. للشهادات والمفاتيح، خزّنها مشفّرة بـ base64 أو كسلسلة JSON بهروب \n، وفكّها في التطبيق.

ويعرض الحفظ خيار حفظ وإعادة نشر: فالمتغيّرات تُخبز في البناء، أي أنها تسري عند النشر التالي لا على الحاوية العاملة.

الحذف

يحذف زر حذف التطبيق، في منطقة الخطر من صفحة عام للتطبيق، التطبيقَ وحاويته وتاريخ نشره. ويبقى تثبيت GitHub مرتبطاً لبقية تطبيقاتك.

الخطوات التالية

• إعدادات البناء — ثبّت طريقة البناء في مستودعك بملف sahabti.json
• النسخ — قواعد بيانات وذاكرات مؤقتة مُدارة تعمل إلى جانب تطبيقك
• مساحات العمل والأدوار — من في فريقك يمكنه النشر
• رموز API — اقرأ التطبيقات وعمليات النشر من سكربت