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