العمليات — النشر

ما هي

كيف يُشغَّل ManpowerIQ اليوم، وكيف يُقصَد استضافته. الواقع الحالي: تقديم محلي. النشر المُستضاف مخطّط، لا مبنيّ.

الحالي — التقديم المحلي

يُشغَّل النظام محليًا عبر docker-compose + dotnet run + npm run dev — انظر التشغيل المحلي وإعادة الضبط. هذه هي الطريقة المدعومة لتشغيله اليوم: لا يوجد نشر إنتاجي قائم، ولا خط أنابيب نشر CI/CD، ولا بنية-تحتية-ككود في المستودع.

المخطّط — EC2 / nginx

الاستضافة المقصودة هي نسخة AWS EC2 خلف nginx (وكيل عكسي يقدّم تطبيق الويب المبنيّ ويُمرّر الـ API). هذا مخطّط، لا مُنجَز:

• لا سكربتات نشر، ولا وحدات systemd، ولا تهيئة nginx مُلتزَمة.
• لا تجهيز بيئة مؤتمت.
• هدف EC2/nginx نيّة في خارطة الطريق، لا قدرة مُشحونة.

عندما يُبنى، يُتوقّع أن يكون الشكل: نشر الـ API الخاص بـ .NET وتشغيله كخدمة، وبناء تطبيق الويب (npm run build) وتقديمه كملفات ساكنة عبر nginx، وnginx ينهي TLS ويُمرّر /api إلى الـ API، وPostgreSQL كنسخة مُدارة أو مُستضافة ذاتيًا مع الحفاظ على فصل الاتصالين (المالك / المربوط بـ RLS) (انظر تعدّد المستأجرين).

مزالق / قيود

• لا تعامل EC2/nginx كحيّ — إنه هدف، لا نشر. أي ادّعاء بأن التطبيق "منشور" طموحي.
• يجب أن ينجو فصل سلسلتي الاتصال إلى الإنتاج — على وقت التشغيل أن يستخدم الدور المربوط بـ RLS، لا المالك أبدًا.
• يجب إزالة/تقييد التشخيصات المُبوّبة بـ IsDevelopment() قبل أي نشر حقيقي — انظر F9 / PB-114.
• لا ترحيل-عند-الإقلاع — على عملية النشر تشغيل dotnet ef database update كخطوة صريحة.

حالة البناء

مخطّط — التقديم المحلي حاليّ؛ استضافة EC2/nginx مقصودة لكن غير مبنيّة. موثّقة بصدق كمخطّطة.

ذو صلة

• التشغيل المحلي وإعادة الضبط · المراقبة · الترحيلات
• تعدّد المستأجرين — فصل سلسلة الاتصال الواجب الحفاظ عليه.