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