لماذا تشعر تحسينات CI/CD الخاصة بك بأنها مشغولة ولكنها عديمة الفائدة

لقد أنهيت للتو تقييم النضج. فريقك حصل على درجات عبر ستة أبعاد. لوحة البيانات تبدو ملونة. الجميع مستعد للتحرك.

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

هذا هو الفخ الأكثر شيوعًا بعد أي تقييم للنضج: محاولة تحسين كل شيء دفعة واحدة.

المشكلة الحقيقية ليست الدرجات المنخفضة

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

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

إليك رسم تخطيطي بسيط لخط أنابيب التسليم لجعل الاختناق مرئيًا.

flowchart TD A["Code Commit"] --> B["Build & Test\n(5 min)"] B --> C["Manual Approval\n(2 days)"] C --> D["Deploy to Staging\n(2 min)"] D --> E["Integration Tests\n(10 min)"] E --> F["Deploy to Production\n(2 min)"] style C fill:#ffcccc,stroke:#ff0000,stroke-width:3px style C stroke-dasharray: 5 5

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

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

كيفية العثور على الاختناق الحقيقي الخاص بك

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

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

لا تخمن. اسأل الأشخاص الذين يقومون بالعمل الفعلي. إنهم يعرفون بالضبط أي خطوة تؤلم أكثر.

بناء خارطة طريق تستهدف شيئًا واحدًا

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

إليك ما يبدو عليه هذا في الممارسة العملية.

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

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

هذا يبدو غير مريح. يبدو أنك تترك درجات منخفضة دون مساس. ولكن هذا هو الهدف. أنت لا تتجاهلها. أنت تعطي الأولوية للشيء الوحيد الذي سيجعل التسليم أسرع اليوم.

لماذا يعمل هذا

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

الجميع يفهم السبب. خارطة الطريق ليست قائمة مشاريع. إنها حل لمشكلة يشعرون بها كل يوم.

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

قائمة مراجعة عملية لخارطة الطريق التالية

قبل أن تبدأ دورة التحسين التالية، راجع قائمة المراجعة هذه مع فريقك.

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

إعادة التقييم بانتظام، ولكن فقط بعد أن تتصرف

النضج ليس قياسًا لمرة واحدة. إنها دورة. تجد الاختناق. تصلحه. يصبح التسليم أسرع. ثم يظهر اختناق جديد في مكان آخر. تجده مرة أخرى. تصلحه مرة أخرى.

هذا هو السبب في أنك تحتاج إلى إعادة التقييم كل ستة أشهر. ليس للتحقق مما إذا كانت درجاتك قد ارتفعت. للتحقق مما إذا كان الاختناق الذي استهدفته قد تم حله بالفعل، وللعثور على التالي الذي يعيق فريقك الآن.

نموذج النضج ليس خزانة جوائز. إنه مرآة. تنظر إليها لترى أين أنت عالق، وليس للإعجاب بمدى تقدمك.

الخلاصة الملموسة

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