DevOps وCI/CD

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

غاية التكامل والنشر المستمر هي التراجع الآمن لا السرعة

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

مم يتكون خط الإصدار

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

تشريح الخط: البناء والاختبار والصورة والنشر

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

إدارة البيئات والإعدادات

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

الحاويات والتنسيق

وجدت الحاويات لتلغي جملة «كان يعمل عندي». يجتمع التطبيق وبيئة التشغيل والاعتماديات في صورة واحدة، وتفتح هذه الصورة بالطريقة ذاتها على حاسوب المطور وعلى خادم التشغيل. أما التنسيق فقرار منفصل لا يلزم كل مشروع. فتطبيق من خدمة واحدة ذو حركة متوقعة تجلب له منصة Kubernetes عبئا تشغيليا أكبر من عائدها. ويظهر المسوغ حين تتوسع خدمات متعددة بشكل مستقل، وحين يشترط النشر دون انقطاع، وحين يطلب تعاف تلقائي. وإن كان مصدر المشكلة الحمل لا الخط انتقل العمل إلى خدمة توسيع نطاق الخلفية، وهناك تناقش البنية والوصول إلى البيانات والتخزين المؤقت.

القابلية للمراقبة: السجلات والمقاييس والتنبيهات

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

إدارة الأسرار والصلاحيات

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

التراجع والاستجابة للحوادث

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

علاقة وتيرة الإصدار بالهشاشة

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

فوائد إدارة البنية التحتية ككود

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

التسليم: كيف تشغلون الخط بأنفسكم

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

معايير اختيار الأداة لدينا

تختار الأداة بحسب المكان الذي يعيش فيه المشروع أصلا، لا بحسب العادة. فإن كان الكود على GitHub ولا رغبة لديكم في تشغيل خادم منفذ منفصل، كانت منصة GitHub Actions أقصر الطرق. وللخطوط التي تعمل على خادمكم أو تطول مدتها أو تضم خطوات خاصة تبقى أداة Jenkins خيارا معقولا: ففي ستة من المشاريع التسعة المرتبطة بهذه الخدمة بنيت أتمتة التكامل والنشر المستمر على Jenkins، ويعمل جانب الخوادم على نظام Ubuntu في تلك المشاريع. أما الثلاثة الباقية فقائمة تقنياتها مختلفة، لأننا لا ننسخ الخط نفسه إلى كل مكان. وتلغي أداة Docker الفارق بين البيئات، فتصير الخيار الافتراضي متى تقرر استعمال الحاويات. وتبقى Kubernetes وAzure رهن المسوغ: خدمات متعددة، أو توسع مستقل، أو سياسة سحابة مؤسسية. ومكان الاستضافة قراركم لا قرارنا، فبنية Lextum AI المدارة أقيمت على AWS، وفي مشاريع أخرى جاء الاختيار مغايرا.

كيف عمل هذا على أرض الواقع

الأعمال التالية قيد التشغيل أو منجزة، وتفصيل كل منها موجود على صفحته الخاصة في قسم قصص النجاح.

• Lextum AI: بنية خدمات مصغرة مع معالجة غير متزامنة عبر RabbitMQ، وواجهة على Next.js وخدمات على .NET وبنية SaaS مدارة على AWS، مع أتمتة التكامل والنشر المستمر على Jenkins، في بنية جاهزة للاستعمال المؤسسي عالي الحركة.
• Anneekspres: بنية سوق إلكتروني قائمة على طابور رسائل RabbitMQ وإدارة بيانات في PostgreSQL وخطوط Jenkins، بإتاحية عالية ونشر سريع.
• Biletico: تخزين مؤقت على Redis فوق حزمة Next.js وNode.js، وأتمتة التكامل والنشر المستمر على خطوط Jenkins، فكل تحديث يختبر قبل وصوله إلى المستخدمين.
• Welldone: تطبيق جوال على Flutter ولوحة إدارة على React وخدمات على .NET، فوق بنية خوادم قابلة للتوسع على Ubuntu، مع أتمتة التكامل والنشر المستمر على Jenkins، فصارت العملية من الطلب إلى الشحن على منصة واحدة.
• World Summer Schools: بنية سحابية قابلة للتوسع على حزمة Next.js و.NET وPostgreSQL، مع أتمتة التكامل والنشر المستمر على Jenkins، وهي بنية مهيأة لنمو عدد البرامج والمستخدمين.
• BiTalih: منصة إنتاج محتوى تعمل على Next.js وMongoDB، ببنية إصدار قائمة على Jenkins وعلى نظام Ubuntu للخوادم.