الـ Pipelines والبيئات
الـ CI/CD يعمل في Azure Pipelines — وهو مصدر الحقيقة للـ builds والبوابات والـ deployments. تشرح هذه الصفحة النية والاصطلاحات؛ ولا تلصق أي pipeline YAML.
ما الذي يُشغّله كل PR pipeline
Section titled “ما الذي يُشغّله كل PR pipeline”| # | البوابة | مانعة؟ |
|---|---|---|
| 1 | سياسة الـ branch والـ work item المرتبط | نعم |
| 2 | فحص الأسرار (secret scan) | نعم |
| 3 | الـ Build — التحذيرات أخطاء | نعم |
| 4 | الـ Lint والـ format | نعم |
| 5 | اختبارات الـ unit والـ integration، مع نشر النتائج | نعم |
| 6 | بوابة الـ diff coverage على الأسطر المتغيّرة | نعم |
| 7 | فحص ترتيب الـ database migrations | نعم |
البوابة تمنع لأن Build Validation branch policy على main تشترط ذلك الـ pipeline. الـ YAML وحده لا يمنع شيئًا. أمّا التحليل الساكن ومراجعة الـ AI فقد يُعلّقان، لكنهما لا يمنعان أبدًا وليسا اختبارات.
سلّم البيئات
Section titled “سلّم البيئات”flowchart LR PR["PR<br/>build validation"] --> Dev["Dev<br/>auto-deploy"] Dev --> QA["QA<br/>auto-deploy"] QA --> UAT["UAT<br/>gated: manual approval"] UAT --> Prod["Prod<br/>gated: manual approval"]
أربع بيئات، وأربعة أسماء، ولا مرادفات: dev · qa · uat · prod.
| المرحلة | المُشغّل | الموافقة |
|---|---|---|
| Build validation (CI) | كل PR إلى main |
لا شيء — يجب أن يكون أخضر للـ merge. |
| Dev | الـ merge إلى main |
auto-deploy. |
| QA | نجاح deploy الـ Dev | auto-deploy. |
| UAT | ترقية | يدوي — PM (Firas Alhawasli) أو CTO (Wahid Bitar). |
| Prod | ترقية | يدوي — CTO + توقيع العميل. |
موافقة الـ prod هي الآلية، لا القرار. أمّا هل نُصدر أصلًا فهو قرار المفتاحين — الـ PM و الـ QA Lead، انظر حقوق اتخاذ القرار. وموافقة البيئة من الـ CTO تأتي بعد ذلك القرار، لا بدلًا منه.
ابنِ مرة واحدة، وروِّج الـ artifact. مرحلة build واحدة تُنتج الـ artifact، وكل بيئة تنشر نفس ذلك الـ artifact مع متغيّرات تُربط وقت الـ deployment. فالـ build الذي يصل الـ prod مطابق تمامًا لما وقّع عليه الـ QA. وإعادة البناء لكل بيئة عيب — تعني أن أحدًا لم يختبر ما شُحن فعلًا.
الموبايل الـ native لا يستخدم هذا السلّم: الـ build الموقّع يُروَّج عبر مسارات المتجر الخاصة به. انظر الموبايل الـ native.
الـ Database migrations
Section titled “الـ Database migrations”- الـ deploy يُولّد سكربت migration idempotent انطلاقًا من آخر migration مُطبَّق في تلك البيئة، ملفوفًا في transaction واحدة تتراجع عند الخطأ.
devوqa: تُطبَّق تلقائيًا.uatوprod: يُنتَج السكربت كـ artifact قابل للمراجعة ويُطبَّق عن قصد.- إلى الأمام فقط. لا down-migration أبدًا على قاعدة بيانات عميل — الإصلاح يكون بـ migration جديدة.
الـ Rollback هو إعادة نشر الـ artifact السابق من تاريخ تشغيل نفس الـ pipeline؛ ولأن الـ migrations تراكمية وإلى الأمام فقط، فالـ build القديم يعمل على الـ schema الجديد. والـ migration التي تجعل هذا مستحيلًا عيب تصميمي — قُل ذلك في الـ PR، لا أثناء الحادثة.
الأسرار لا تعيش في الـ repo
Section titled “الأسرار لا تعيش في الـ repo”- الأسرار وسلاسل الاتصال تعيش فقط في variable groups مربوطة بـ Key Vault. أمّا إعدادات البيئات غير السرّية (الروابط، الـ feature flags) فتعيش في الـ repo.
- فحص الأسرار يعمل على كل
PRويمنع الدمج عند أي نتيجة. لا فحص، لا merge. - أي pipeline YAML يحوي كلمة مرور أو مفتاحًا أو سلسلة اتصال هو عيب، لا خيار إعداد.
- إعدادات كل بيئة تُربط وقت الـ deployment، ولا تُدمج داخل الـ build أبدًا.
تسليم بيانات اعتماد الإنتاج للعميل مرتبط بالدفعة النهائية — انظر حدّ الـ Warranty.