يربط خط CI/CD المفيد للفريق الصغير تغيير الشفرة بإصدار متحقق منه، وقرار نشر واضح، ورحلة مستخدم جرى اختبارها. ابدأ بتطبيق واحد وعملية يستطيع مسؤول صيانة مخوّل آخر تشغيلها. الهدف الأول إصدار يمكن تحديده وشرح خطواته واستعادة تشغيله ضمن شروط متفق عليها، مع أدلة تبقى متاحة بعد انتهاء النشر.
لا تبدأ بالضرورة بتغيير مزود السحابة أو شراء مجموعة أكبر من الأدوات. راجع آخر إصدار فعلي، وسجل الخطوات التي اعتمدت على حاسوب أحد المطورين أو صلاحية غير موثقة أو أمر يتذكره شخص واحد. هذه الفجوات تصنع موجز عمل أوضح من مخطط أدوات لم يتفق أحد على صيانتها أو التعامل مع أعطالها.
يجمع التكامل المستمر التغييرات بصورة متكررة مع فحوص تكشف مشكلات دمجها. ويحافظ التسليم المستمر على البرمجيات في حالة قابلة للإصدار عبر عملية قابلة للتكرار. أما النشر المستمر فيؤتمت إطلاق التغييرات التي تستوفي الشروط المحددة. يوضح دليل DORA للتسليم المستمر الفرق بين القدرة على التسليم ونشر كل تغيير تلقائياً في الإنتاج.
حدد موضع قرار الإنتاج في العملية. يمكن أن يتضمن مسار التسليم نافذة إصدار يراجعها مسؤول، أو نشراً آلياً عندما تدعم طبيعة التطبيق وفحوصه وضوابط استعادته ذلك. اكتب ما يبدأ البناء، وما يسمح بوصول إصدار إلى الإنتاج، ومن يملك تفويضه، وما الذي يوقف المسار. لا تترك هذه القرارات مستترة داخل إعدادات الأداة.
في مثال افتراضي لتطبيق حجوزات، قد يشمل النطاق الأول تطبيق الويب وعامل المهام الخلفية، وبيئة اختبار وبيئة إنتاج. يبقى تطبيق جوال منفصل أو مشروع ترحيل بيانات العملاء خارج هذا المسار ما لم يُدرج صراحة. المثال يوضح حدود النطاق، ولا يصف نظام عميل نفذناه أو نتيجة تشغيل حققناها.
احتفظ بسجل قصير يشير إلى الأدلة التفصيلية. يجب أن يستطيع من يتعامل مع مشكلة تحديد مراجعة الشفرة المنشورة دون سؤال من بنى الإصدار. اسم الفرع وحده لا يكفي لتعريف النسخة، لأنه قد يشير لاحقاً إلى تغييرات أخرى. افصل هوية الإصدار عن المكان الذي يستمر فيه التطوير.
استخدم ورقة العمل الأصلية التالية في أول تجربة، واستبدل أمثلتها بمراجع تطبيقك ومسؤوليه. هي سجل قرارات وأدلة، وليست وصفة تفرض منصة CI بعينها. ينبغي أن يصل المسؤول إلى التفاصيل من خلالها دون نسخ سجلات حساسة أو كلمات مرور إلى مستند متداول بين الفريق.
| البند | ما تسجله | لماذا يحتاجه مسؤول التشغيل؟ |
|---|---|---|
| المصدر | المستودع ومراجعة الشفرة المحددة | معرفة الشفرة التي أنتجت النسخة المرشحة |
| البناء | معرّف الحزمة أو صورة التشغيل ومدخلات البناء | الوصول إلى الوحدة التي خضعت للفحص |
| الفحوص | النتائج المطلوبة وروابط حالات الفشل | معرفة شروط القبول التي اختُبرت |
| الإعداد | البيئة المستهدفة ونسخة إعداداتها | شرح الفروق دون نسخ الأسرار إلى السجل |
| تغيير البيانات | مرجع الترحيل وملاحظات التوافق | معرفة قدرة النسخة السابقة على مواصلة العمل |
| قرار الإصدار | المسؤول المخوّل أو القاعدة والوقت والهدف | تتبع سبب انتقال النسخة إلى هذه البيئة |
| التحقق | نتيجة رحلة المستخدم والإشارات ومرجع الاستعادة | تقرير مواصلة المراقبة أو اتخاذ إجراء |
يدعم دليل DORA لأتمتة النشر استخدام عملية نشر متسقة ووحدات بناء قابلة للتتبع بين البيئات. انقل الوحدة التي فُحصت عندما تسمح المنصة بذلك، بدلاً من بناء بديل مجهول الصلة بها. افصل إعداد البيئة حيث تدعم المنصة هذا الفصل، واحفظ قوالبه بإصدارات دون وضع بيانات الاعتماد في الشفرة.
تدمج بعض أطر العمل قيماً خاصة بالبيئة أثناء البناء. وثق هذا القيد بدلاً من الادعاء بأن ملفات الاختبار والإنتاج متطابقة. سجل مدخلات البناء المختلفة، وحدد الفحوص التي يجب تشغيلها على النسخة المرشحة الفعلية للإنتاج. قابلية تكرار النتيجة تعتمد على العملية المستخدمة في تطبيقك، لا على الوصف المثالي في مخطط عام.
اختر الفحوص حول أخطاء محتملة وسلوك مهم. قد يكشف فحص الأنواع تغييراً غير صالح، ويختبر فحص التطبيق عملية حسابية، ويكشف فحص التكامل اختلافاً في العقد مع نظام آخر. تأتي قيمة الفحص من المشكلة التي يكشفها، لا من عدد الشارات الخضراء. اربط كل فحص بسبب مفهوم لدى المسؤول عن الإصدار.
في مثال الحجوزات، يمكن اختبار حجز مخوّل، ورفض طلب غير مخوّل، وإعادة محاولة يجب ألا تنشئ حجزاً مكرراً. استخدم بيانات وتجهيزات اختبار مناسبة وتكاملات تجريبية تدعمها الخدمة. لا تنقل هذه القائمة آلياً إلى موقع تعريفي أو تطبيق مخزون، فلكل منتج سلوك يستحق التحقق بحسب أثر فشله.
اجعل الفشل قابلاً للتشخيص. يحتاج مسؤول الصيانة إلى معرفة الخطوة والمراجعة المستخدمة ومكان السجل بعد تنقيح بياناته الحساسة. ميّز عطل الفحص نفسه عن عيب التطبيق. تجاوز فحص غير موثوق مراراً يمنح المسار مظهراً مضللاً للحماية؛ أصلح السبب أو عدّل الفحص وفق قرار موثق يمكن مراجعته.
نجاح أمر النشر مرحلة ضمن العملية. يتناول دليل Azure للنشر الآمن فحوص السلامة وقرارات الاستعادة حول الإطلاق. اختر تحققاً يعكس التطبيق: استجابة صفحة بنجاح لا تثبت اكتمال حجز أو معالجة إشعار دفع أو تنفيذ مهمة خلفية. سجل نتيجة الرحلة المهمة نفسها مع هوية النسخة المنشورة.
أبقِ بيانات اعتماد الإنتاج خارج وظائف الاختبار العادية ومستودع الشفرة، وامنح كل مسار ما يحتاجه من صلاحيات. راجع اعتماديات أدوات النشر وطريقة تحديثها. يغطي مرجع GitHub للاستخدام الآمن ضوابط الاعتماديات وتقليل الصلاحيات ومخاطر تشغيل شفرة غير موثوقة في مسارات ذات امتيازات. لا تساوِ سهولة إضافة خطوة جديدة بصلاحيتها للوصول إلى الإنتاج.
عندما يدعم مزود السحابة OpenID Connect، يمكن استبدال هوية مسار مخوّل برمز وصول سحابي قصير العمر. يتطلب ذلك علاقة ثقة مضبوطة وصلاحيات سحابية محدودة. تفعيل طلب الرمز وحده لا ينشئ حدود الوصول المطلوبة إذا بقي استخدام الدور متاحاً لأطراف أو فروع أوسع من المقصود.
تحقق من الضوابط المتاحة للمستودع والخطة الفعليين. يوضح مرجع بيئات النشر في GitHub أن المراجعين الإلزاميين في خطط Free وPro وTeam متاحون للمستودعات العامة. لذلك لا تفترض توافر كل ميزات الموافقة لمستودع خاص لمجرد أنه يسمح بتعريف بيئة. راجع المتاح قبل إدراجه ضمن وعد التنفيذ.
كذلك لا ينشئ اسم البيئة حساباً سحابياً أو قاعدة بيانات أو شبكة منفصلة. وثق الفصل الحقيقي، وكيف يتعامل المسار مع إصدار ثانٍ أثناء نشر الأول: هل ينتظر أم يُرفض؟ وهل يمكن مقاطعة العملية الحالية بأمان؟ إلغاء وظيفة في منتصف تغيير بيانات يحتاج معالجة واضحة؛ زر الإلغاء ليس خطة استعادة بحد ذاته.
اتفق على الاستجابة قبل أول تجربة حية. يعطي الجدول الأصلي التالي الفريق حالات محددة لمراجعتها، مع قرار أول وأدلة يحتاجها المسؤول. استبدل الأدوار بأسماء فعلية، وأبقِ مسار التصعيد متاحاً خارج أداة CI نفسها حتى لا يصبح تعطلها سبباً في فقدان تعليمات التعامل مع المشكلة.
| حالة الفشل | القرار الأول | الدليل والمسؤول |
|---|---|---|
| فشل فحص مطلوب | إيقاف انتقال النسخة وفهم السبب | مخرجات الفحص؛ مسؤول التطبيق |
| رفض الوصول السحابي | مراجعة الهوية المقصودة وصلاحياتها | نتيجة مصادقة منقحة؛ مسؤول الوصول |
| إصدار آخر قيد التنفيذ | اتباع قاعدة الانتظار أو الرفض | سجل الإصدار النشط؛ مسؤول النشر |
| توقف النشر في منتصفه | تحديد الحالة الفعلية قبل الإعادة | حالة المنصة والتطبيق؛ مسؤول التشغيل |
| فشل رحلة مستخدم مهمة | اتباع قرار الاستعادة الخاص بالإصدار | نتيجة الرحلة وتوافق البيانات؛ مسؤول الاستعادة |
| عدم وصول التنبيه | إصلاح مسار الإشعار وتسمية البديل | دليل التسليم؛ مسؤول المتابعة |
قد تعني الاستعادة إعادة نسخة التطبيق، أو تعطيل ميزة، أو إصلاحاً جديداً، أو استعادة بيانات بعملية جرى اختبارها منفصلة. يوضح دليل AWS لتوافق تغييرات البيانات ضرورة مراعاة سلوك النسختين القديمة والجديدة. الرجوع بالشفرة لا يعكس كل كتابة في قاعدة البيانات ولا يلغي إجراءً اكتمل في خدمة خارجية.
استخدم ورقة خطة الرجوع لتسجيل النسخة المتوافقة وقرار الاستعادة وفحوص الإصدار المحدد.
اطلب من مسؤول صيانة مخوّل آخر إصدار تغيير معروف، وتشخيص فحص أُفشل عمداً، واتباع سيناريو استعادة مناسب. سجل مواضع قصور التعليمات وعدّلها. يجب أن يتضمن نطاق التسليم ملفات المسار وملكية الوصول وتحديث الاعتماديات ودليل الإصدار، لا عرضاً ناجحاً لا يستطيع أحد تكراره بعد انتهاء الجلسة.
اتفق على من يراقب النتيجة والمدة التي يغطيها. إعداد التنبيه لا يعني وجود فريق يستجيب طوال اليوم. راجع مسؤوليات الاستضافة واتفاق تطوير التطبيق قبل شراء أعمال متداخلة. وإذا كانت صعوبة الإصدار ناتجة عن ترابط نظام قديم، فقد يساعد دليل التحديث التدريجي في تحديد تغيير مطلوب داخل التطبيق نفسه.
أحضر سجل إصدار حديثاً وأكثر خطوة يدوية تعطل فريقك إلى مراجعة DevOps وعملية النشر. يجب أن يسمي المقترح التطبيقات والبيئات والفحوص وتجربة الاستعادة ومسؤولي التشغيل. مسار محدد يستطيع الفريق شرحه وتشغيله بداية عملية للتحسين التالي، وتبقى إضافاته مرتبطة بما تكشفه التجربة الفعلية من احتياجات.
