أين تعيش بنياتك: لماذا يحتاج كل أثر إلى منزل

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

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

الحل بسيط من الناحية النظرية ولكنه حاسم من الناحية العملية: أنت بحاجة إلى مكان واحد مركزي تعيش فيه كل نتيجة بناء. في مصطلحات DevOps، يسمى هذا المكان بـ السجل (Registry) أو مدير المستودع (Repository Manager).

الأرتيفاكتات تأتي بأشكال مختلفة

لنبدأ بالنوع المألوف من الأرتيفاكت: ملف JAR، أرشيف ZIP، ملف ثنائي مُجمّع، أو حزمة NuGet. هذه هي الأرتيفاكتات أحادية الملف. أدوات مثل Nexus، Artifactory، أو سجلات الحزم المدمجة في نظامك البيئي للغات (npm registry، Maven Central، PyPI) تتعامل مع هذه بشكل جيد. تقوم بتخزين الملف، وتتبع الإصدارات، وتسمح لخطوط الأنابيب أو المطورين بسحب التبعية المحددة التي يحتاجونها.

الآن فكر في صور الحاويات. صورة الحاوية ليست ملفًا واحدًا. إنها مبنية من طبقات متعددة مكدسة فوق بعضها البعض. لا يمكنك تخزين صورة حاوية في مستودع أرتيفاكت عادي. إنها تحتاج إلى سجل حاويات (Container Registry): Docker Hub، Amazon ECR، Google Container Registry، أو Harbor. سجلات الحاويات تفهم بنية الطبقات. عندما تسحب صورة، يرسل السجل فقط الطبقات التي لا توجد بالفعل على الجهاز الهدف. هذا يجعل عمليات النشر أسرع ويوفر عرض النطاق الترددي.

أصبحت صور الحاويات أكثر أنواع الأرتيفاكت شيوعًا في خطوط أنابيب CI/CD الحديثة. لكن المبدأ هو نفسه بغض النظر عن التنسيق: السجل هو المصدر الوحيد للحقيقة لكل أرتيفاكت اجتاز البناء والاختبارات الخاصة بك.

السجل هو نقطة التسليم بين CI و CD

إليك الوظيفة الأكثر أهمية للسجل في خط الأنابيب: إنها تحدد الحدود بين التكامل المستمر (CI) والتسليم المستمر (CD).

يوضح الرسم البياني التالي التباين بين التدفق الصحيح والتدفق المعطل الذي يحدث عندما لا يوجد سجل.

flowchart TD subgraph Correct[مع السجل] A1[خط CI] -->|دفع الأرتيفاكت مع الإصدار| B1[السجل] B1 -->|سحب الأرتيفاكت المحدد| C1[خط CD] C1 --> D1[بيئة الاختبار] C1 --> E1[الإنتاج] end subgraph Broken[بدون سجل] A2[مساحة عمل CI] -->|نسخ يدوي| B2[لابتوب] A2 -->|نسخ يدوي| C2[محرك مشترك] B2 --> D2[بيئة الاختبار] C2 --> E2[الإنتاج] D2 -.->|عدم تطابق الإصدار| E2 end Correct -.->|مقارنة| Broken

انظر إلى التدفق. تنتهي مهمة CI في اللحظة التي يصل فيها الأرتيفاكت إلى السجل مع علامة إصدار واضحة. اكتمل البناء. نجحت الاختبارات. تم تخزين الأرتيفاكت. تتوقف مسؤولية CI عند هذا الحد.

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

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

الترقية بدون تعديل

السجل الجيد يتيح أيضًا ترقية الأرتيفاكت (Artifact Promotion). الترقية هي عملية وضع علامة على أرتيفاكت معين على أنه جاهز للبيئة التالية. أنت لا تعدل الأرتيفاكت نفسه. أنت تضيف بيانات وصفية.

على سبيل المثال، ينتج CI الخاص بك أرتيفاكت موسوم بـ 1.2.3-build.45. هذا الأرتيفاكت موجود في السجل. عندما يجتاز اختبارات بيئة الاختبار، تضيف علامة: staging. عندما يجتاز التحقق من صحة الإنتاج، تضيف علامة أخرى: production. الأرتيفاكت الأساسي متطابق. فقط حالته تتغير.

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

ماذا يحدث بدون سجل

الفرق التي تتخطى إعداد سجل مناسب تواجه نفس المشاكل بشكل متكرر:

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

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

قائمة تحقق عملية لإعداد السجل الخاص بك

إذا كنت تقوم بإعداد سجل لأول مرة، أو تراجع الإعداد الحالي، إليك قائمة تحقق قصيرة:

  • اختر النوع الصحيح: سجل حاويات للصور، ومستودع أرتيفاكت للملفات الثنائية والحزم. بعض الأدوات مثل Harbor أو Artifactory تتعامل مع كليهما.
  • فرض الثبات (Immutability): بمجرد تخزين أرتيفاكت مع علامة إصدار، لا تسمح بالكتابة فوقه. البناء الجديد يحصل على إصدار جديد.
  • تعيين سياسات الاحتفاظ: ليس كل بناء يحتاج إلى العيش إلى الأبد. احتفظ بآخر N من البنيات أو البنيات من آخر M يومًا. قم بأرشفة أو حذف الباقي.
  • التحكم في الوصول: يجب أن يكون لخطوط الأنابيب صلاحية الكتابة. يجب أن يكون للمطورين وخطوط CD صلاحية القراءة. استخدم أدوار IAM أو الرموز المميزة (tokens)، وليس كلمات مرور مشتركة.
  • وضع علامات على الترقيات بشكل صريح: استخدم البيانات الوصفية أو العلامات لتحديد الأرتيفاكتات الموجودة في بيئة الاختبار، أو الإنتاج، أو التي تم التراجع عنها. قم بأتمتة هذا في خط CD الخاص بك.

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

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

قم بإعداد السجل الخاص بك قبل نشرك التالي. ذاتك المستقبلية، التي تتصيد حادثًا في منتصف الليل، ستشكرك.