التعلم من كل تسليم: إغلاق حلقة التحسين
لقد أنهيت للتو إصدارًا. كان خط الأنابيب أخضر، وتم النشر بسلاسة، والمستخدمون سعداء. أو ربما كانت كارثة: ترحيل فاشل، استرجاع في الساعة 2 صباحًا، وتحليل بعد الحادثة ألقى باللوم على "مشاكل في العملية". على أي حال، انتهى الإصدار. وماذا بعد؟
تتعامل معظم الفرق مع نهاية الإصدار على أنها خط النهاية. ينتقلون إلى الميزة التالية، السباق التالي، الحريق التالي الذي يجب إخماده. لكن كل إصدار - ناجحًا كان أم لا - يحمل معلومات قيمة. ليس فقط حول ما إذا كان الإصدار الجديد يعمل، ولكن حول كيفية أداء عملية التسليم نفسها. أي الخطوات كانت بطيئة؟ أي الفحوصات فشلت بشكل متكرر؟ أي القواعد تبين أنها غير ذات صلة؟ بدون آلية لالتقاط هذه المعلومات والتصرف بناءً عليها، يظل نموذج التسليم الخاص بك مجمدًا عند مستواه الحالي من النضج.
البيانات التي تمتلكها بالفعل
بعد الإصدار، لا تحتاج إلى لوحة تحكم فاخرة لبدء التعلم. تحتاج إلى إجابات لبعض الأسئلة الأساسية:
- كم من الوقت استغرق من أول commit إلى الإنتاج؟
- كم عدد مرات فشل البناء على طول الطريق؟
- كم من الوقت أمضى الفريق في انتظار موافقات البوابات؟
- هل كانت هناك خطوات يدوية كان يمكن أتمتتها؟
- هل حدثت أي حوادث بعد الإصدار؟
عادة ما تكون هذه البيانات متناثرة عبر أداة CI/CD الخاصة بك، ومتعقب الحوادث، وسجل محادثات الفريق. الخطوة الأولى هي جمعها في مكان واحد. لا تحتاج إلى تقرير مصقول. مستند مشترك أو جدول بيانات بسيط يكفي. المهم هو أن تنظر إلى الأرقام بصدق.
ثلاث طبقات للتحسين
بمجرد حصولك على البيانات، يمكنك تحديد أين تركز. يعمل التحسين عبر ثلاث طبقات:
يوضح الرسم البياني أدناه كيف تربط حلقة التحسين بين الإصدارات والطبقات الثلاث للتحسين.
العملية تغطي كيفية عمل الفريق: تسلسل الخطوات في خط الأنابيب، كيفية اتخاذ القرارات، من يحتاج إلى الموافقة على ماذا، وكيف تتم عمليات التسليم بين الفرق.
المنصة تغطي الأدوات والبنية التحتية: نظام CI/CD، بيئات الاختبار، نصوص النشر، وأدوات المراقبة.
السياسة تغطي القواعد: بوابات الحوكمة، معايير التحقق، والشروط التي يجب استيفاؤها قبل أن يتمكن الإصدار من المتابعة.
قد يكون الإصدار البطيء مشكلة في العملية (عدد كبير جدًا من الموافقات اليدوية)، أو مشكلة في المنصة (خوادم البناء غير كافية)، أو مشكلة في السياسة (بوابة تتحقق من شيء غير ذي صلة). غالبًا ما يكون مزيجًا من الثلاثة.
التعلم من النجاح، وليس فقط من الفشل
من الطبيعي التركيز على حالات الفشل. الإصدار المعطل يتطلب الاهتمام. لكن النجاح مفيد بنفس القدر.
عندما يتم الإصدار بسلاسة وسرعة، اسأل لماذا. ربما كان التغيير صغيرًا ومركزًا. ربما كان لدى الفريق الاختبارات الصحيحة في مكانها. ربما كانت بيئة التدريج أخيرًا مطابقة قريبة للإنتاج. مهما كان السبب، فهذا نمط يستحق التعزيز.
عندما يسوء الإصدار، يكون الإغراء هو إضافة المزيد من البوابات، والمزيد من الفحوصات، والمزيد من خطوات الموافقة. لكن في بعض الأحيان لا تكون المشكلة هي قلة التحكم - بل كثرة التحكم. البوابة التي لا تكتشف أبدًا مشكلات حقيقية تضيف تأخيرًا فقط. الاختبار الذي ينجح دائمًا يعطي ثقة زائفة. يجب أن تقوم حلقة التحسين بتقليم ما لا يعمل، وليس فقط إضافة ما قد يعمل.
إغلاق الحلقة بين الفرق والمنصة
في العديد من المؤسسات، هناك فجوة بين الفرق التي تسلم البرامج وفريق المنصة الذي يبني الأدوات. يضيف فريق المنصة ميزات بناءً على افتراضات. تتعامل فرق التسليم مع القيود بصمت. تسد حلقة التحسين هذه الفجوة.
عندما يجد فريق التسليم أن خطوة في خط الأنابيب بطيئة باستمرار، يقومون بإبلاغ فريق المنصة. يحقق فريق المنصة ويصلح البنية التحتية أو الأداة. عندما يطرح فريق المنصة ميزة جديدة، تختبرها فرق التسليم وتبلغ عما إذا كانت تساعد بالفعل أم تضيف تعقيدًا فقط.
هذه التغذية الراجعة ثنائية الاتجاه تحافظ على ملاءمة المنصة. بدونها، يبني فريق المنصة أشياء لا يستخدمها أحد، وتعاني فرق التسليم بأدوات لا تناسب احتياجاتهم.
اجعلها جزءًا من الإصدار، وليس اجتماعًا منفصلاً
لا ينبغي أن تكون حلقة التحسين مراجعة شهرية تقع خارج دورة التسليم. يجب أن تكون مضمنة في كل إصدار.
بعد كل نشر في الإنتاج، حدد موعدًا لمراجعة قصيرة. لا تحتاج إلى أن تكون اجتماعًا رسميًا. محادثة مدتها 15 دقيقة مع الأشخاص المعنيين، والنظر في البيانات، والاتفاق على تغيير أو اثنين للإصدار التالي كافية. المفتاح هو الاتساق. إذا كنت تراجع فقط بعد الحوادث الكبرى، فإنك تفوت التحسينات الصغيرة التي تتراكم بمرور الوقت.
قائمة مراجعة عملية لمراجعة إصدارك التالي
قبل أن تغلق إصدارك التالي، راجع هذه الأسئلة:
- ما هو إجمالي وقت الاستجابة من commit إلى الإنتاج؟
- كم عدد مرات فشل البناء، ولماذا؟
- هل كانت هناك أي خطوات يدوية أخرت الإصدار؟
- هل فشلت أي بوابة تحقق في اكتشاف مشكلة حقيقية؟
- هل اجتازت أي بوابة تحقق دون التحقق الفعلي من أي شيء مفيد؟
- هل كان هناك حادث بعد الإصدار؟ إذا كان الأمر كذلك، هل كان من الممكن اكتشافه مبكرًا؟
- ما الذي سار بشكل أفضل من المتوقع؟ لماذا؟
- ما هو التغيير الوحيد الذي سيجعل الإصدار التالي أسرع أو أكثر أمانًا؟
اختر عنصرًا واحدًا من هذه القائمة وتصرف بناءً عليه قبل الإصدار التالي. ليس كلهم. واحد فقط.
الخلاصة
كل إصدار هو نقطة بيانات. حلقة التحسين تحول هذه البيانات إلى عمليات أفضل، ومنصات أفضل، وسياسات أفضل. لا تتطلب مبادرة كبيرة أو فريقًا مخصصًا. تتطلب عادة: بعد كل تسليم، اسأل عما تعلمته، وقم بتغيير صغير واحد بناءً على الإجابة.
يجب ألا يكون نموذج التسليم الخاص بك ثابتًا. يجب أن ينمو مع كل إصدار. ليس لأنك تخطط لتحول كبير، ولكن لأنك تهتم بما يعلمك إياه كل تسليم.