لماذا تحتاج عملية النشر الخاصة بك إلى القوالب وقوائم التحقق (حتى لو كنت تعتقد أنك لا تحتاجها)
عملية النشر على وشك الحدوث. يسأل أحدهم في دردشة الفريق: "هل أخذنا نسخة احتياطية من قاعدة البيانات قبل الترحيل؟" يتبعه صمت. ثم سؤال آخر: "من تفقد إعدادات بيئة الاختبار؟" المزيد من الصمت. في النهاية، يقوم شخص ما بتشغيل الترحيل، ويتمنى ألا يحدث شيء.
هذا المشهد يتكرر يومياً عبر فرق الهندسة. ليس لأن الفريق عديم الخبرة، بل لأن العقل البشري سيء جداً في تذكر سلسلة من 20 إلى 30 خطوة تحت الضغط. عندما تكون في سباق مع موعد نهائي أو تتعامل مع حادث إنتاجي، فإن الخطوة التي تنساها غالباً ما تكون هي التي تسبب التوقف.
المشكلة الحقيقية ليست المعرفة، بل الذاكرة
معظم الفرق تعرف ما يجب فعله أثناء النشر. المهندس الأقدم قام بذلك عشرات المرات. شخص DevOps يحفظ الترتيب. لكن المعرفة الموجودة داخل رأس شخص ما هشة. قد يكون ذلك الشخص في إجازة. قد يكون مشغولاً بحادث آخر. قد يكون ببساطة في يوم سيء.
المشكلة ليست أن الناس لا يعرفون. المشكلة هي أن لا أحد دوّن ذلك بطريقة تمكن الفريق بأكمله من اتباعها باستمرار. عندما يكون لكل عضو في الفريق قائمته الذهنية الخاصة، تصبح العملية غير متوقعة. شخص واحد يتذكر دائماً التحقق من لوحة المراقبة بعد النشر. شخص آخر ينسى دائماً. النتيجة هي عملية تنجح أحياناً وتفشل في أحيان أخرى، دون نمط واضح.
القوالب تمنحك نقطة بداية قابلة للتكرار
قالب النشر هو تسلسل محدد مسبقاً من الخطوات لنوع معين من التغيير. يجيب على السؤال: "ماذا نحتاج أن نفعل، بالترتيب، لإدخال هذا التغيير إلى الإنتاج بأمان؟"
عندما يكون لديك قالب، تتوقف عن إعادة اختراع العملية في كل مرة. لنشر تطبيق، قد يتضمن القالب:
- التحقق من أن الأرتيفكت المبني يطابق الإصدار المقصود
- تشغيل ترحيلات قاعدة البيانات إذا لزم الأمر
- تحديث التكوين الخاص بالبيئة
- النشر إلى بيئة كاناري أو اختبار أولاً
- تشغيل اختبارات تدخينية ضد الإصدار المنشور
- الطرح التدريجي إلى نسخ الإنتاج
- التحقق من المراقبة والتنبيهات بعد النشر
القالب ليس جامداً. لكل نشر سياقه الخاص. ربما لا يوجد ترحيل لقاعدة البيانات هذه المرة. ربما التغيير صغير جداً لدرجة أن نشر الكاناري غير ضروري. القالب يعطيك المسار الافتراضي، وتقوم بالتعديل من هناك. المفتاح هو أن تبدأ من هيكل معروف بدلاً من البناء من الصفر في كل مرة.
أنواع التغييرات المختلفة تحتاج إلى قوالب مختلفة. قالب ترحيل قاعدة البيانات يبدو مختلفاً عن قالب نشر التطبيق. قالب تغيير البنية التحتية يبدو مختلفاً عن قالب تدوير الأسرار. كل قالب يلتقط الخطوات والمخاطر المحددة ذات الصلة بهذا النوع من العمل.
قوائم التحقق تلتقط ما تفتقده القوالب
القوالب تخبرك ماذا تفعل. قوائم التحقق تخبرك أنك فعلتها بالفعل. هي طبقة التحقق التي تقع فوق العملية.
قائمة التحقق مفيدة للخطوات التي يسهل تخطيها، خاصة عندما تبدو روتينية. هل أخذت نسخة احتياطية قبل الترحيل؟ هل قمت بتشغيل الترحيل في وضع التشغيل التجريبي أولاً؟ هل تحققت من أن الإصدار القديم لا يزال قادراً على خدمة الحركة المرورية إذا كان التراجع ضرورياً؟ هل تفقدت معدل الأخطاء بعد خمس دقائق من اكتمال النشر؟
بدون قائمة تحقق، تعتمد هذه الخطوات كلياً على الذاكرة. مع قائمة التحقق، تصبح نقاط تحقق صريحة. يجب على شخص ما أن ينظر إلى كل عنصر ويؤكد أنه تم. هذا يحول العملية من "أعتقد أنني فعلت كل شيء" إلى "أستطيع أن أرى أن كل شيء قد تم".
الاتساق يجعل استكشاف الأخطاء أسهل
عندما يتبع كل نشر نفس النمط، يبني الفريق نموذجاً ذهنياً مشتركاً. إذا حدث خطأ ما، يمكن لأي شخص في الفريق النظر إلى سجل النشر وفهم ما حدث. يعرفون أي خطوة كانت قيد التنفيذ عند حدوث الخطأ. يعرفون ما تم التحقق منه قبل النشر وما تم التحقق منه بعده.
هذا الاتساق قيم بشكل خاص لنوبات الاستجابة للحوادث. عندما يستيقظ مهندس في الساعة 3 صباحاً للتعامل مع مشكلة نشر، لا ينبغي له أن يخمن كيف تم تنظيم هذا النشر بالذات. القالب وقائمة التحقق يضمنان أن العملية مألوفة، حتى لو لم يكن المهندس مشاركاً في التخطيط الأصلي.
لأعضاء الفريق الجدد، تعمل القوالب وقوائم التحقق كتوثيق يُستخدم فعلياً. بدلاً من مرافقة مهندس أقدم لأسابيع، يمكنهم دراسة القوالب، وفهم التدفق المتوقع، والبدء في المساهمة بشكل أسرع. المعرفة مُلتقطة في العملية، وليست محبوسة داخل رأس شخص ما.
التدقيق والامتثال هما فوائد جانبية
إذا كانت مؤسستك بحاجة إلى تلبية متطلبات تنظيمية أو معايير امتثال داخلية، فإن القوالب وقوائم التحقق تصبح دليلاً. قائمة تحقق موقعة أو تنفيذ قالب مسجل يُظهر أن الفريق اتبع الإجراء المطلوب. هذا أكثر مصداقية بكثير من بيان شفهي بأن "كل شيء تم بشكل صحيح".
ولكن حتى لو كنت لا تحتاج إلى الامتثال، فإن مسار التدقيق مفيد لمراجعات ما بعد الحادث. عندما يحدث خطأ ما، يمكنك الرجوع إلى قائمة التحقق ورؤية بالضبط ما تم التحقق منه وما تم تفويته. هذا يحول نقاشاً غامضاً حول "فشل العملية" إلى محادثة ملموسة حول الخطوة المحددة التي تحتاج إلى تحسين.
أبقها حية
قالب أو قائمة تحقق لا تتغير أبداً هي قالب أو قائمة تحقق تصبح غير ذات صلة ببطء. يجب على الفرق مراجعة وثائق النشر الخاصة بهم بانتظام. بعد كل حادث، اسأل: "هل كانت هناك خطوة في قائمة التحقق لدينا كان يجب أن تلتقط هذا؟ إذا لم يكن الأمر كذلك، ماذا يجب أن نضيف؟"
بالمثل، عندما تتم أتمتة خطوة ما، قم بإزالتها من قائمة التحقق. إذا كان خط أنابيب CI الخاص بك يقوم بالفعل بتشغيل ترحيلات قاعدة البيانات تلقائياً، فلا حاجة لوجود عنصر قائمة تحقق يدوي له. الهدف ليس الحصول على أطول قائمة تحقق. الهدف هو الحصول على الأكثر دقة.
قائمة تحقق عملية للنشر
إليك قائمة تحقق بسيطة تنطبق على معظم عمليات نشر التطبيقات. قم بتعديلها لتناسب سياق فريقك.
- تأكيد إصدار الأرتيفكت المبني
- مراجعة واختبار سكريبت ترحيل قاعدة البيانات
- أخذ نسخة احتياطية من قاعدة البيانات قبل الترحيل
- إكمال الترحيل التجريبي بدون أخطاء
- التحقق من قيم التكوين للبيئة المستهدفة
- اجتياز نشر الكاناري أو الاختبار لاختبارات التدخين
- الطرح التدريجي لنشر الإنتاج
- معدل الخطأ وزمن الاستجابة طبيعيان بعد 5 دقائق من النشر
- خطة التراجع جاهزة ومختبرة
الخلاصة
القوالب وقوائم التحقق ليست أعباء بيروقراطية. هي الفرق بين عملية نشر تعتمد على الحظ وأخرى تعتمد على الهيكل. ابدأ بقالب واحد لنوع النشر الأكثر شيوعاً لديك. اكتب الخطوات بالترتيب. أضف قائمة تحقق لنقاط التحقق الحرجة. راجعها بعد كل حادث. دعها تتطور مع خبرة فريقك. الهدف ليس الكمال من اليوم الأول. الهدف هو التوقف عن الاعتماد على الذاكرة والبدء في الاعتماد على عملية يمكن لأي شخص في الفريق اتباعها.