لماذا لا يجب أن تحاول بناء كل شيء دفعة واحدة
عندما يبدأ فريق بالحديث عن CI/CD، غالبًا ما تتبادر إلى الذهن صورة تحول ضخم. كل تطبيق يحتاج إلى pipeline. قواعد البيانات يجب أن تكون مؤتمتة. البنية التحتية يجب أن تُعلن ككود. كل البيئات يجب أن تكون متطابقة. وكل شيء يجب أن يُنجز في نفس الوقت.
هذه الصورة مرعبة، ويجب أن تكون كذلك. لأنك عندما تحاول فعل كل شيء دفعة واحدة، فإن النتيجة الأكثر ترجيحًا ليست تحولًا، بل فوضى.
فكر في ما ستحتاج إلى تغييره في دفعة واحدة: كيف يرسل المطورون الكود، كيف يتعامل فريق قواعد البيانات مع ترحيلات المخطط (schema migrations)، كيف تقوم البنية التحتية بتجهيز الخوادم، كيف يجري فريق ضمان الجودة الاختبارات، كيف يوافق مديرو الإصدارات على النشر، وكيف يتتبع الجميع ما تغير. كل هذا يحدث بينما يستمر تطبيقك الحالي في خدمة المستخدمين.
هذا ما يُسمى تحول الانفجار الكبير (big bang transformation). الاسم يبدو ضخمًا، لكنه في الممارسة عادةً ما ينتهي بفشل ذريع. أشياء كثيرة تتغير دفعة واحدة. متغيرات كثيرة خارجة عن السيطرة. وعندما يحدث عطل، لا أحد يعرف أين يبحث لأن كل شيء جديد.
النهج التدريجي يبدو أقل بريقًا، لكنه أكثر واقعية بكثير. بدلاً من تغيير كل شيء دفعة واحدة، تختار جزءًا واحدًا لديه أعلى فرصة للنجاح، تُنهيه، تتعلم منه، ثم تنتقل إلى الجزء التالي.
الفرق بين هذين المسارين واضح عندما تراهما جنبًا إلى جنب:
لماذا النهج التدريجي أفضل من الانفجار الكبير
لكل فريق نقطة بداية مختلفة. قد يكون لدى فريق تطبيق يعمل في الإنتاج لكنه لا يزال ينشر يدويًا. قد يكون لدى فريق آخر pipelines لتطبيقه لكنه لا يزال يدير قواعد البيانات عبر SSH مباشرة إلى الخوادم. قد يكون لدى فريق ثالث بنية تحتية مؤتمتة لكنه لم يكتب أبدًا اختبارًا آليًا لتطبيقه.
لا يوجد مخطط واحد يناسب جميع الفرق. محاولة نسخ مخطط شخص آخر كاملًا عادةً ما تنتهي بتعديلات مؤلمة. النهج التدريجي يحترم نقطة البداية الفعلية لفريقك. يتيح لك البناء من حيث أنت، وليس من حيث يعتقد شخص آخر أنه يجب أن تكون.
النهج التدريجي يمنحك أيضًا مساحة للتعلم. كل خطوة تنتج خبرة حقيقية: كيف تتصرف pipeline مع قاعدة كود فريقك، كيف تتفاعل قاعدة بياناتك مع الترحيلات الآلية، كيف تستجيب بنيتك التحتية لتغييرات التكوين. هذه الخبرة تساوي أكثر من أي وثائق أداة أو نظرية، لأنها تأتي مباشرة من سياقك الخاص.
المخاطرة هي سبب آخر للسير خطوة بخطوة. عندما يتغير جزء واحد فقط، ويحدث خطأ ما، تعرف بالضبط أين تبحث. عندما يتغير كل شيء دفعة واحدة، قد تأتي المشكلة من أي مكان. سيقضي فريقك وقتًا في البحث عن السبب بدلاً من إصلاح التأثير.
أخيرًا، التغيير التدريجي أسهل على الناس لتقبله. التحولات الكبيرة تخلق مقاومة لأن الناس مرتاحون لسير العمل المألوف. لكن عندما يحدث التغيير في خطوات صغيرة، كل خطوة تشعر بأنها أخف. يرى الفريق النتائج، ويشعر بالفوائد، ويصبح أكثر انفتاحًا على الخطوة التالية.
كيف تجد خطوتك الأولى
الجزء الأصعب هو تحديد من أين تبدأ. العديد من الفرق تعلق هنا لأنها تحاول تخطيط خارطة الطريق بأكملها قبل اتخاذ أي إجراء. هذا خطأ. لا تحتاج إلى خريطة كاملة. تحتاج إلى خطوة واحدة واضحة تقدم قيمة.
ابدأ بالنظر إلى عملية التسليم الحالية لديك. ابحث عن الجزء الذي يسبب أكبر قدر من الألم أو يستغرق معظم الوقت. هذا عادةً ما يكون مرشحًا جيدًا لخطوتك الأولى.
إليك بعض نقاط البداية الشائعة:
- إذا كان النشر إلى الإنتاج يتطلب قائمة مراجعة يدوية تستغرق ساعات، ابدأ بأتمتة نشر خدمة واحدة غير حرجة.
- إذا كانت تغييرات قاعدة البيانات تُطبق يدويًا وتتسبب غالبًا في حوادث إنتاجية، ابدأ بأتمتة ترحيلات المخطط لقاعدة بيانات منخفضة المخاطر.
- إذا كان فريقك يقضي أيامًا في الاختبار اليدوي لكل إصدار، ابدأ بكتابة اختبارات آلية لتدفقات المستخدم الأكثر أهمية.
- إذا كانت تغييرات البنية التحتية تتم عبر طلبات تذاكر تستغرق أسابيع، ابدأ بإعلان جزء واحد من البنية التحتية ككود.
المفتاح هو اختيار شيء صغير بما يكفي لإنهائه في وقت معقول، لكنه ذو معنى كافٍ ليشعر الفريق بالتحسن.
كيف تبدو خارطة الطريق التدريجية النموذجية
خارطة الطريق التدريجية لا تعني أن تخطط لكل خطوة مسبقًا. إنها تعني أن تعرف اتجاهك وتتخذ خطوة واحدة في كل مرة.
قد يبدو التسلسل النموذجي كالتالي:
- أتمتة بناء ونشر تطبيق واحد. أبقِ كل شيء آخر يدويًا.
- أضف اختبارات آلية للمسارات الأكثر أهمية لذلك التطبيق.
- وسّع الـ pipeline لتشمل ترحيلات قاعدة البيانات لذلك التطبيق.
- طبق نفس النمط على تطبيق ثانٍ، مع إجراء تعديلات بناءً على ما تعلمته.
- انقل تدريجيًا توفير البنية التحتية إلى الـ pipeline.
- أضف قدرات المراقبة والتراجع (rollback).
- وسّع إلى التطبيقات المتبقية.
لاحظ أن كل خطوة تبني على التي تسبقها. لا تقفز من النشر اليدوي إلى أتمتة البنية التحتية الكاملة في خطوة واحدة. دع كل خطوة تغذي التالية.
قائمة تحقق عملية لخطوتك الأولى
قبل أن تبدأ، راجع قائمة التحقق السريعة هذه:
- هل يمكنك تحديد تطبيق أو خدمة واحدة منخفضة المخاطر وغير حرجة؟
- هل لديك تعريف واضح لما يعنيه "تم الإنجاز" لهذه الخطوة؟
- هل يوجد شخص في الفريق يمكنه تولي هذه الخطوة ومتابعتها حتى النهاية؟
- هل أخبرت الفريق أن هذه تجربة، وليست تغييرًا دائمًا في العملية؟
- هل لديك طريقة للتراجع إذا حدث خطأ ما؟
إذا كان بإمكانك الإجابة بنعم على هذه الأسئلة، فأنت جاهز للبدء. إذا لم يكن الأمر كذلك، فاقضِ وقتًا في توضيح هذه النقاط أولاً.
الخلاصة
لا تحتاج إلى تحويل كل شيء دفعة واحدة. تحتاج إلى خطوة واحدة عاملة يمكن لفريقك رؤيتها، لمسها، والتعلم منها. ابدأ من هناك. دع الخطوة التالية تنبثق مما تكتشفه. الفريق الذي يتعلم تدريجيًا يبني ممارسات تدوم. الفريق الذي يحاول تغيير كل شيء دفعة واحدة عادةً ما ينتهي به الأمر بإعادة البناء من الصفر.