في فرق الهواة، النشر هو “حدث”. يصرخ المطور الرئيسي: “توقف الجميع عن الدمج! أنا أقوم بالنشر!” أنها SSH إلى الخادم. يقومون بتشغيل “git pull”. يصلون. إذا انكسرت، فإنهم يشعرون بالذعر.

في الفرق المحترفة، يعد النشر ليس حدثًا. ويحدث 20 مرة في اليوم. إنه ممل. إنه غير مرئي. إذا تعطل، يعود النظام تلقائيًا إلى حالته السابقة قبل أن يراها المستخدم.

ويتم تحقيق ذلك من خلال التكامل المستمر / النشر المستمر (CI/CD). خط الأنابيب هو روبوت يحرس بيئة الإنتاج الخاصة بك. وظيفتها بسيطة: رفض التعليمات البرمجية السيئة بلا رحمة.

لماذا تتحدث Maison Code عن هذا

في Maison Code Paris، نعمل كضمير معمari لعملائنا. غالبًا ما نرث حزمًا “حديثة” تم بناؤها دون فهم أساسي للحجم.

نناقش هذا الموضوع لأنه يمثل نقطة تحول حاسمة في النضج الهندسي. التنفيذ الصحيح يميز MVP الهش عن منصة مؤسسية مرنة يمكنها التعامل مع حركة مرور الجمعة السوداء.

1. الفلسفة: الفرع الرئيسي مقدس

الهدف من CI/CD هو التأكد من أن الفرع “الرئيسي” قابل للنشر دائمًا. لا تضغط أبدًا على “الرئيسي” مباشرة. أنت تلتزم بـ التطوير القائم على الجذع (أو الفروع المميزة قصيرة العمر).

1. يقوم المطور بإنشاء فرع “feat/new-checkout”.
2. يقوم المطور بدفع الكود.
3. يعمل خط أنابيب CI. تمر الاختبارات.
4. يفتح المطور طلب السحب (PR).
5. تم نشر معاينة البيئة.
6. تحدث مراجعة النظراء.
7. الدمج في “الرئيسي”.
8. يعمل خط أنابيب الأقراص المضغوطة. ينتشر إلى الإنتاج.

2. الطبقة الأولى: التحليل الثابت (شرطة القواعد)

أرخص الأخطاء التي يجب إصلاحها هي تلك التي يتم اكتشافها قبل تشغيل الكود. نقوم بتشغيل هذا في كل “دفعة بوابة”.

• فحص (ESLint): يكتشف أخطاء بناء الجملة والأنماط السيئة (no-unused-vars).
• التنسيق (أجمل): يفرض النمط. لا توجد حجج حول علامات التبويب مقابل المسافات أثناء مراجعة التعليمات البرمجية.
• فحص النوع (TypeScript): الفحص الأكثر أهمية. “لقد قمت بتمرير سلسلة إلى دالة تتوقع رقمًا.”

“يامل

.github/workflows/ci.yml

الاسم: CI على: [دفع] وظائف: التحقق من صحة: يعمل على: أوبونتو الأحدث الخطوات: - الاستخدامات: الإجراءات/الخروج@v3 - الاستخدامات: action/setup-node@v3 - التشغيل: npm ci - تشغيل: npm run type-check # tsc —noEmit - تشغيل: تشغيل npm لينت

**التكلفة**: 30 ثانية.
**القيمة**: توفر ساعات من تصحيح الأخطاء "غير محدد ليس دالة".

## 3. الطبقة الثانية: اختبارات الوحدة (التحقق المنطقي)

(راجع [اختبار الوحدة](/ar/blog/tech-unit-testing-ar)).
هل تقوم الدالة `calculateTax()` بإرجاع القيمة الصحيحة لمستخدم ألماني؟
نحن نستخدم **فيتست**. يجب أن يكون سريعا.
إذا استغرقت اختبارات الوحدة أكثر من 5 دقائق، فسيتوقف المطورون عن تشغيلها محليًا.

## 4. الطبقة 3: بيئة المعاينة (Vercel)

هذا هو تغيير قواعد اللعبة.
عند فتح PR، يقوم Vercel تلقائيًا بنشر هذا الرمز إلى عنوان URL فريد: `https://my-app-git-feat-checkout.vercel.app`.
وهذا يسمح:
1. ** ضمان الجودة المرئية **: يمكن للمصمم النقر فوق صفحة الدفع لمعرفة ما إذا كانت وحدات البكسل مثالية أم لا.
2. **مراجعة المنتج**: يستطيع مدير المشروع التحقق من استيفاء الميزة للمتطلبات.
3. **اختبارات E2E الآلية**: يمكن لخط الأنابيب تشغيل متصفح مقابل عنوان URL *الحقيقي* هذا.

## 5. الطبقة 4: الاختبارات الشاملة (E2E) (محاكي المستخدم)

اختبارات الوحدة ليست كافية.
"يعمل اتصال قاعدة البيانات. يتم عرض الزر. لكن النقر فوق الزر لا يؤدي إلى الحفظ في قاعدة البيانات."
فقط **الكاتب المسرحي** (أو السرو) يفهم هذا.

يقوم خط أنابيب CI بتدوير متصفح بدون رأس ويعمل كمستخدم.
1. انتقل إلى `/المنتج/الأحذية الرياضية`.
2. انقر فوق "أضف إلى العربة".
3. توقع ظهور "العربة (1)".

``يامل
  e2e:
    الاحتياجات: المعاينة
    يعمل على: أوبونتو الأحدث
    الخطوات:
      - الاستخدامات: الإجراءات/الخروج@v3
      - الاسم : تشغيل الكاتب المسرحي
        تشغيل: اختبار الكاتب المسرحي npx
        البيئة:
          BASE_URL: ${{ github.event.deployment_status.target_url }}

Blocker: إذا فشلت اختبارات E2E، فسيتم تعطيل زر “الدمج” في GitHub.

6. النشر المستمر: الإصدار

بمجرد دمج الكود في “الرئيسي”، يبدأ مسار القرص المضغوط. بالنسبة لـ Vercel/Netlify، يتم ذلك تلقائيًا. بالنسبة إلى AWS (Docker/ECS)، نستخدم GitHub Actions لإنشاء الحاوية والدفع إلى ECR وتحديث تعريف المهمة.

عدم التوقف عن العمل (أزرق/أخضر)

لا نقوم أبدًا بإعادة تشغيل الخادم المباشر.

1. قم بتدوير الأخضر (الإصدار الجديد).
2. انتظر الفحص الصحي (‘200 OK`).
3. قم بتبديل موازن التحميل إلى الأخضر.
4. اقتل الأزرق (الإصدار القديم). وهذا يضمن أنه في حالة تعطل الإصدار الجديد عند التشغيل، فلن يراه أي مستخدم.

7. قاعدة “النشر يوم الجمعة”.

هناك ميم: “لا تنتشر يوم الجمعة”. في Maison Code، نعمل في أيام الجمعة. إذا كنت خائفًا من النشر يوم الجمعة، فهذا يعني ** أنك لا تثق في خط الأنابيب الخاص بك **. هذا يعني أنك تعتمد على دليل ضمان الجودة أو الأمل. يمنحك خط الأنابيب القوي الثقة للشحن في أي وقت.

8. المسح الأمني (الانتقال إلى اليسار)

غالبًا ما يتم الأمان “في النهاية” عبر Pentest. ننقله إلى طلب السحب.

1. Snyk / Dependabot: يقوم بفحص package.json بحثًا عن التبعيات الضعيفة.
2. Trivy: يقوم بفحص حاويات Docker بحثًا عن ثغرات نظام التشغيل.
3. SonarQube: يقوم بمسح التعليمات البرمجية بحثًا عن نقاط الاتصال (على سبيل المثال، كلمات المرور المشفرة). إذا قمت بتنفيذ مفتاح AWS، فسوف ينفجر المسار. يمنع السر من الوصول إلى تاريخ الفرع “الرئيسي”.

9. إدارة التكلفة (البنية التحتية)

يحب المطورون تدوير الحالات الكبيرة. “أحتاج إلى قاعدة بيانات X1.Large للاختبار.” نحن نستخدم البنية التحتية. يتم تشغيله في العلاقات العامة والتعليقات:

“يؤدي هذا العلاقات العامة إلى زيادة الفاتورة الشهرية بمقدار 150 دولارًا (الترقية إلى X1.Large).” وهذا يجعل التكلفة شفافة. يمكن لـ CTO الموافقة على “التغيير المالي” أو رفضه تمامًا مثل “تغيير الكود”. إنه يجلب FinOps إلى DevOps.

10. إدارة الأسرار (Env Vars)

لا تلتزم مطلقًا بملفات .env. نحن نستخدم Vercel Env Management أو AWS Secrets Manager. يقوم خط أنابيب CI بحقن هذه العناصر في وقت الإنشاء. بالنسبة لعمليات التحقق مفتوحة المصدر (مثل تدقيق npm)، فإننا نضمن عدم تسجيل الأسرار في وحدة التحكم.

9.GitOps (ArgoCD): الكأس المقدسة

بالنسبة لمجموعات Kubernetes الخاصة بنا، نستخدم GitOps. يتم تعريف حالة الكتلة في Git. إذا كنت تريد التوسع من 3 كبسولات إلى 5 كبسولات، فلا تقم بتشغيل “مقياس kubectl”. يمكنك تحرير “deployment.yaml” في Git. يرى ArgoCD التغيير ويقوم بمزامنة المجموعة. اكتشاف الانجراف: إذا قام مهندس رعاة البقر بتغيير المجموعة يدويًا (SSH)، فسيكتشف ArgoCD الانجراف ويستبدلها مرة أخرى إلى حالة Git. وهذا يفرض “البنية التحتية كرمز” دينيًا.

10. زرع قاعدة البيانات للمعاينة

بيئة المعاينة تكون عديمة الفائدة إذا كانت تحتوي على قاعدة بيانات فارغة. قمت بتسجيل الدخول، وليس هناك أي منتجات. نقوم بتنفيذ البذر الآلي.

1. نشر قاعدة البيانات (فرع النيون / Supabase).
2. قم بتشغيل npm run بذرة.
3. الحقن: 10 منتجات، 2 مستخدمين (المسؤول/العميل)، 5 أوامر. الآن يمكن لرئيس الوزراء اختبار صفحة “سجل الطلبات” على الفور. هذا هو الفرق بين “النشر الفني” و”المنتج القابل للاستخدام”.

11. التراجع المتقدم: عمليات نشر Canary

بالنسبة للتطبيقات عالية الخطورة، يكون اللون الأزرق/الأخضر ثنائيًا للغاية. نحن نستخدم ** عمليات النشر الكناري **.

1. نشر الإصدار الثاني إلى 5% من حركة المرور.
2. خط الأنابيب يراقب معدل الخطأ.
3. إذا كان معدل الخطأ أقل من 0.1%، قم بزيادة المعدل إلى 20%.
4. في حالة ارتفاع معدل الخطأ، التراجع التلقائي إلى 0%. وهذا يحد من “نطاق الانفجار” للخلل السيئ. فقط 5% من المستخدمين شاهدوا الخطأ. وهذا يتطلب موازنات تحميل متطورة (AWS ALB / Cloudflare)، ولكنها تمثل شبكة الأمان النهائية.

12. الاستنتاج

العمليات اليدوية هي عدو الحجم. في كل مرة يلمس الإنسان الخادم، يصل خطر الخطأ إلى 10%. في كل مرة يلمس البرنامج النصي الخادم، تكون نسبة المخاطرة 0% (بعد أول تشغيل ناجح). أتمتة كل شيء. اجعل “فعل الشيء الصحيح” هو “الشيء السهل”.

---

قلق النشر؟

هل تعبر أصابعك في كل مرة تطلق فيها سراحك؟

قم ببناء خط أنابيب مضاد للرصاص. اقرأ عن الاختبار الآلي والبنية الأساسية كرمز.

العمليات اليدوية هي عدو الحجم. في كل مرة يلمس الإنسان الخادم، يصل خطر الخطأ إلى 10%. في كل مرة يلمس البرنامج النصي الخادم، تكون نسبة المخاطرة 0% (بعد أول تشغيل ناجح). أتمتة كل شيء. اجعل “فعل الشيء الصحيح” هو “الشيء السهل”.

قلق النشر؟

هل تعبر أصابعك في كل مرة تطلق فيها سراحك؟

قم ببناء خط أنابيب مضاد للرصاص. قم بتوظيف مهندسينا.