ابدأ بتغيير صغير واحد صباح الغد
لقد انتهيت للتو من القراءة عن CI/CD، وخطوط التوصيل، والمنصات الداخلية، والتحسين المستمر. يبدو الأمر رائعاً. لكن عندما تنظر إلى فريقك، تجد الفجوة بين ما قرأته وما تفعله فعلياً هائلة.
ربما لا تزال عملية البناء تُنفذ على حاسوب أحد المطورين. ربما قائمة التحقق من الإصدار موجودة في رأس شخص ما. ربما انحرفت بيئة الاختبار عن بيئة الإنتاج لدرجة أن النشر أصبح مقامرة. ربما ليس لديك فريق حتى - فقط أنت وفكرة.
هذه الفجوة طبيعية. كل فريق يُصدر الآن بشكل موثوق بدأ من حيث أنت الآن. لم يستيقظوا صباحاً ولديهم خط أنابيب مثالي ينشر عشر مرات يومياً بدون أي فشل. بل بنوه تغييراً صغيراً واحداً في كل مرة.
نقطة البداية الحقيقية
معظم الفرق لا تعاني من مشكلة توصيل تحتاج إعادة تصميم شاملة. لديهم خطوة واحدة في عمليتهم الحالية تؤلمهم أكثر من غيرها. تلك الخطوة هي حيث تبدأ.
ألق نظرة على كيفية إصدار فريقك لتغيير اليوم. من لحظة كتابة أحدهم للكود إلى لحظة بدء المستخدمين في استخدام الإصدار الجديد، اذكر كل خطوة. كن صريحاً بشأن ما يحدث فعلياً، وليس ما يجب أن يحدث.
- من يشغل البناء؟
- كيف تعرف أن البناء نجح؟
- ماذا يحدث إذا فشل اختبار؟
- من يقرر أنه آمن للنشر؟
- كيف تضع الإصدار الجديد فعلياً في الإنتاج؟
- كيف تعرف أنه يعمل بعد وضعه؟
في مكان ما في هذه القائمة توجد خطوة تعتمد على شخص واحد يتذكر فعل شيء ما. في مكان ما توجد خطوة لا يمكن تكرارها بنفس الطريقة مرتين. في مكان ما توجد خطوة تجعل الناس متوترين قبل كل إصدار.
اختر تلك الخطوة. واحدة فقط.
كيف يبدو التغيير الواحد
لنفترض أن البناء لا يزال يُنفذ على جهاز مطور. عندما يكون هذا المطور في إجازة، لا يستطيع أحد البناء. عندما يستخدم إصداراً مختلفاً قليلاً من مكتبة، يتصرف البناء بشكل مختلف. عندما تنفد بطارية حاسوبه المحمول في منتصف البناء، ينتظر الفريق.
إليك مثال بسيط على ما قد يبدو عليه هذا السكريبت:
#!/bin/bash
set -e
echo "جارٍ استنساخ المستودع..."
git clone https://github.com/your-org/your-app.git
cd your-app
echo "جارٍ تثبيت التبعيات..."
npm install
echo "جارٍ تشغيل البناء..."
npm run build
echo "تم البناء بنجاح!"
احفظ هذا كـ build.sh، وأضفه إلى مستودعك، وشغّله من خادم مشترك أو خدمة CI. الآن يمكن لأي شخص تشغيل بناء قابل للتكرار.
تغيير واحد: انقل هذا البناء إلى خادم مشترك أو خدمة CI بسيطة. لا يحتاج أن يكون متطوراً. سكريبت واحد يسحب الكود، ويشغل البناء، ويبلغ عن النجاح أو الفشل هو بالفعل أفضل من بناء على حاسوب محمول. الآن يمكن لأي شخص تشغيله. الآن النتيجة مرئية للجميع. الآن البناء قابل للتكرار.
أو ربما المشكلة مختلفة. ربما البناء مؤتمت، لكن النشر لا يزال سلسلة يدوية من أوامر SSH يعرفها شخص واحد فقط. تغيير واحد: اكتب تلك الأوامر في سكريبت، وأضفه إلى المستودع، وشغّله من نظام CI. الآن النشر موثق، وقابل للتكرار، ولم يعد يعتمد على الذاكرة.
أو ربما المشكلة أن بيئة الاختبار لا تطابق الإنتاج أبداً. تغيير واحد: استخدم نفس سكريبت النشر لكلتا البيئتين. إذا عمل السكريبت في بيئة الاختبار لكنه فشل في الإنتاج، يصبح الفرق بين البيئتين مرئياً وقابلاً للإصلاح.
لا تتطلب أي من هذه التغييرات فريق منصة جديد. لا تتطلب شراء أدوات باهظة الثمن. لا تتطلب موافقة الجميع على سير عمل كامل. تتطلب فقط اختيار خطوة مؤلمة واحدة وجعلها أفضل قليلاً.
تأثير كرة الثلج
إليك ما يحدث بعد ذلك التغيير الأول: ستشعر به. الإصدار التالي سيكون أقل إجهاداً بقليل. البناء التالي لن يتطلب رسالة في Slack تسأل من لديه الحاسوب المناسب. النشر التالي لن يتطلب مشاركة شاشة حتى يتمكن شخص من مشاهدة الأوامر وهي تُكتب.
هذا الشعور يجعلك ترغب في إصلاح الخطوة التالية. والتي تليها. ليس لأن أحداً أخبرك بذلك، ولكن لأنك تذوقت كيف يكون الأمر عندما يصبح جزء من التوصيل متوقعاً. تريد المزيد من ذلك.
هكذا يحدث التبني الحقيقي لـ CI/CD. ليس من خلال خطة عظيمة. ليس من خلال ترحيل منصة لمدة ستة أشهر. بل من خلال سلسلة من التحسينات الصغيرة العملية التي تتراكم بمرور الوقت.
طريقة سريعة لإيجاد خطوتك الأولى
قبل أن تغلق هذه المقالة، افعل هذا:
- افتح مستودع تطبيقك.
- اكتب كل خطوة من مرحلة تقديم الكود إلى النشر في الإنتاج، كما تحدث فعلياً اليوم.
- ضع علامة على الخطوة التي تؤلم أكثر - تلك التي تفشل في أغلب الأحيان، أو تستغرق أطول وقت، أو تعتمد على أكبر قدر من المعرفة الضمنية.
- قرر شيئاً واحداً ملموساً يمكنك فعله غداً لجعل تلك الخطوة أفضل قليلاً. ليس مثالياً. أفضل.
هذه هي نقطة بدايتك.
ما هو CI/CD حقاً
بعد كل الفصول، والرسوم البيانية، والمناقشات حول خطوط الأنابيب، والمنصات، والحوكمة، هذه هي الحقيقة الجوهرية: CI/CD ليس عن الأدوات. ليس عن امتلاك مخطط خط أنابيب مثالي. ليس عن محاكاة ما تفعله شركة FAANG.
CI/CD هو قدرة مؤسستك على الاستمرار في إصدار التغييرات - لكود التطبيق، ومخططات قواعد البيانات، والبنية التحتية - بأمان، والاستمرار في التحسن مع كل إصدار.
هذه القدرة لا يمكن شراؤها. لا يمكن تثبيتها. لا يمكن تكوينها بواسطة مستشار في مهمة مدتها أسبوعان. إنها تُبنى، تغييراً صغيراً واحداً في كل مرة، بواسطة أشخاص يقررون أن إصدار اليوم سيكون أقل إيلاماً قليلاً من إصدار الأمس.
ابدأ صباح الغد. اختر خطوة واحدة. اجعلها أفضل. ثم افعلها مرة أخرى.