النشر الآلي CI/CD ببساطة: عبدالله عبدالرحيم الكندي يشرح الرحلة

في مشاريع كثيرة، نشر نسخة جديدة طقس متوتر: المطوّر يدخل الخادم بنفسه، ينسخ ملفات، يشغّل أوامر من ذاكرته، ويدعي إنه ما ينسى خطوة. وإذا نسي، يطيح الموقع ليلة الخميس وهو بعيد عن جهازه. عبدالله عبدالرحيم الكندي يبني المواقع بـ Next.js و TypeScript والتطبيقات بـ Flutter، وما ينشر شي منها يدوياً. هنا يشرح النشر الآلي CI/CD بدون مصطلحات زايدة: وش هو، وكيف يمشي التعديل فيه خطوة بخطوة، ووش تكسب أنت كصاحب مشروع.

الاختصاران في جملتين

CI اختصار Continuous Integration، أي التكامل المستمر: كل ما رفع أحد تعديلاً للمستودع، يُبنى ويُختبر آلياً قبل ما يندمج مع الكود الأساسي. و CD اختصار Continuous Delivery أو Continuous Deployment: بعد ما ينجح الفحص، يُجهَّز التعديل للنشر، أو يُنشر فعلاً بدون تدخل يدوي. الفرق بين الاثنين في الكلمة الأخيرة: Delivery يعني النسخة جاهزة وتنتظر ضغطة موافقة من إنسان، و Deployment يعني تنزل مباشرة. وأغلب المشاريع تبدأ بالأولى، وتنتقل للثانية لما تصير اختباراتها تستاهل الثقة.

رحلة تعديل واحد، من الفرع إلى الموقع الحي

خلنا نتابع تعديلاً بسيطاً جداً: تغيير نص زر في صفحة الطلب. هذي المحطات اللي يمر فيها في مشروع مضبوط:

• الفرع: المطوّر ما يكتب على الفرع الرئيسي مباشرة. يفتح فرعاً باسم التعديل ويشتغل فيه براحته.
• طلب الدمج: يرفع الفرع ويفتح Pull Request. هنا يبدأ الشغل الآلي عبر أداة مثل GitHub Actions أو GitLab CI، تقرأ ملف إعداد داخل المستودع يحدد الخطوات بالترتيب.
• الفحوصات: تثبيت الحزم من ملف القفل بالإصدارات نفسها، ثم فحص الأنواع في TypeScript، ثم أداة التدقيق (linter)، ثم الاختبارات، ثم بناء نسخة الإنتاج. أي خطوة تفشل توقف كل شي وتطلع علامة حمراء على الطلب.
• المعاينة: منصات استضافة كثيرة تنشر الفرع على رابط مؤقت، فتفتحه وتشوف الزر بعينك على جوالك.
• المراجعة: شخص ثاني يقرأ التعديل. الآلة تتأكد إن الكود يشتغل، والإنسان يتأكد إنه منطقي وما يكسر شي ما تغطيه الاختبارات.
• الدمج والنشر: بعد الموافقة يندمج الفرع، والدمج نفسه يطلق النشر: لبيئة الاختبار أولاً، ثم للإنتاج تلقائياً أو بضغطة موافقة.
• التحقق بعد النشر: فحص آلي سريع يتأكد إن الصفحة الرئيسية ترد، وإن نقطة فحص الصحة في الخادم تقول إن كل شي تمام.

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

وش يتغيّر عندك كصاحب مشروع

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

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

وفي تطبيقات Flutter؟

الفكرة نفسها مع محطات إضافية. الفحص يشغّل flutter analyze و flutter test، ثم يبني ملف AAB لأندرويد وملف IPA لآيفون. بناء آيفون يحتاج جهاز macOS، والخدمات السحابية للبناء توفّر أجهزة ماك لهذا الغرض. والتوقيع هو الجزء الحساس: شهادات آبل ومفتاح توقيع أندرويد تُحفظ كأسرار مشفّرة في أداة البناء، مو داخل المستودع. وأدوات مثل fastlane تأتمت الرفع إلى TestFlight وإلى مسار الاختبار في Google Play.

ونقطة لازم تكون واضحة: في الجوال، النشر الآلي ينتهي عند «انرفعت النسخة». بعدها مراجعة المتجر لها وقتها وقرارها، فالأتمتة تختصر شغلك، لكنها ما تختصر طابور آبل وجوجل.

أخطاء تخلّي الأتمتة تعطيك ثقة كاذبة

• مسار أخضر بلا اختبارات: البناء ينجح، لكن ما فيه اختبار واحد يتأكد إن الدفع يشتغل. العلامة الخضراء هنا تقول «الكود ينبني»، مو «الموقع سليم».
• أسرار مكتوبة في ملف الإعداد: مفتاح خدمة منسوخ نصاً داخل ملف workflow في المستودع، بدل مخزن الأسرار في الأداة.
• تجاوز الفحص وقت الزحمة: «ندمج الحين ونصلح بعدين». فعّل حماية الفرع الرئيسي بحيث يمنع الدمج إذا الفحص أحمر، حتى عن صاحب المستودع.
• ترحيل قاعدة بيانات بلا خطة: الكود يرجع بضغطة، لكن عموداً انحذف ما يرجع. التغييرات المدمّرة تتقسّم على أكثر من نشر: أولاً توقف الكتابة على العمود، وبعدين تحذفه.
• مسار بطيء: لو الفحص ياخذ نص ساعة، الفريق يبدأ يتحايل عليه. تخزين الحزم مؤقتاً وتشغيل الخطوات المستقلة بالتوازي يختصر الانتظار.
• إصدارات أدوات غير مثبّتة: إصدار Node أو Flutter في خادم البناء يختلف عن اللي عند المطوّر، فيطلع خطأ ما أحد قادر يكرره على جهازه.

ابدأ صغيراً، وزِد خطوة خطوة

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

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