مخطط انسيابي لعملية نشر البرمجيات: من البناء إلى الإنتاج

كيف تعمل

1. أعد تسمية المسارات لتطابق أدوارك الحقيقية

   استبدل المطوّر وخط CI/CD وضمان الجودة ومهندس الإصدارات والتشغيل بالأدوار الموجودة لديك فعلاً. كثير من الفرق ليس فيها مهندس إصدارات، وعندها ادمج ذلك المسار في من يملك الإنتاج بدل ترك شريط فارغ. وأبقِ خط CI/CD مساراً مستقلاً وإن كان أتمتة، لأن غاية المخطط أن يُظهر أي الخطوات تنفّذها آلة وأيها ما زال ينفّذها إنسان.

2. حدّد ما هي الحزمة وأين تعيش

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

3. عرّف ما تفحصه كل بوابة فعلاً

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

4. ثبّت نافذة التغيير ومن يفتحها

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

5. اختر استراتيجية لكل خدمة واكتب خطوات الطرح

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

6. اجعل مُطلِق التراجع قابلاً للقياس، ثم انشر المخطط

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

الأسئلة الشائعة

ما الفرق بين عملية النشر وعملية الإصدار؟

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

ما مراحل عملية نشر البرمجيات؟

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

هل ننشر بالأزرق-الأخضر أم بالكناري؟

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

متى ينبغي أن يتراجع النشر تلقائياً؟

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

أين يقع الاعتماد إن كنا ننشر عدة مرات يومياً؟

اعتماد كل عملية نشر على حدة لا يتوسّع، والعملية التي لا يستطيع الناس اتباعها يجري الالتفاف عليها. والجواب المعتاد هو اعتماد المسار لا الحالة: عرّف هذا النوع من النشر كتغيير قياسي معتمد مسبقاً، واجعل بوابات الخط واختباراته وتراجعه التلقائي هي الضابط، واحصر الاعتماد الفردي في التغييرات الخارجة عن ذلك النموذج، مثل ترحيلات المخطط أو أي شيء يمسّ بيئة مقيّدة. وهذا موضع قرار «هل اعتُمد النشر؟» في هذا المخطط، ولهذا رُسم فرع التأجيل. وتتوقع أطر مثل SOC 2 (المعيار CC8.1) وضابط إدارة التغيير في ISO/IEC 27001 أن تكون التغييرات على الإنتاج معتمدة ومختبرة وموثّقة، لكنها لا تشترط توقيعاً بشرياً على كل عملية نشر. والمخطط ليس دليلاً بحد ذاته، لكن سجلات النشر ونتائج الاختبارات والاعتمادات التي ينتجها هي ما يطلب المُقيّم رؤيته.