لماذا يجب ألا تعيد بناء الأرتيفكت بعد اجتيازه الاختبارات أبدًا

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

هذا السيناريو يحدث أكثر مما يعترف به معظم الفرق. الحل ليس أداة بناء أفضل. إنه انضباط يبدأ من اللحظة التي يبدأ فيها خط الأنابيب الخاص بك.

ابنِ مرة واحدة، واستخدم في كل مكان

القاعدة الأولى لإدارة الأرتيفكت بسيطة: ابنِ مرة واحدة بالضبط. هذا الأرتيفكت الواحد يسافر عبر كل بيئة من التطوير إلى الإنتاج. لا إعادة ترجمة. لا إعادة حزم. لا "دعني فقط أعيد بنائه مع علامة الإنتاج."

المخطط الانسيابي التالي يوضح كيف ينتقل أرتيفكت واحد عبر البيئات عن طريق الترقية، دون إعادة بناء:

flowchart TD A[Source Code Commit] --> B[Build Artifact] B --> C[Calculate Checksum] C --> D[Push to Registry] D --> E[Deploy to Dev] E --> F[Run Tests in Dev] F --> G{Tests Pass?} G -- Yes --> H[Promote in Registry] G -- No --> I[Fix Code & Rebuild] H --> J[Deploy to Staging] J --> K[Run Tests in Staging] K --> L{Tests Pass?} L -- Yes --> M[Promote in Registry] L -- No --> I M --> N[Verify Checksum] N --> O[Deploy to Production] O --> P[Production Running] style B fill:#4CAF50,color:#fff style H fill:#FF9800,color:#fff style M fill:#FF9800,color:#fff style N fill:#2196F3,color:#fff

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

نفس الأرتيفكت الذي اجتاز جميع الفحوصات في التدريج يجب أن يكون نفس الأرتيفكت الذي يعمل في الإنتاج. إذا لم تستطع ضمان ذلك، فلا يمكنك الوثوق في اختباراتك.

أعط كل أرتيفكت هوية قابلة للتتبع

يجب أن تكون قادرًا على الإجابة عن سؤال واحد حول أي أرتيفكت: من أين أتى هذا؟ هذا يعني أن كل أرتيفكت يجب أن يحمل هوية تربط بالكود المصدري الدقيق، وتشغيل خط الأنابيب الدقيق، واللحظة الدقيقة التي تم إنشاؤه فيها.

أتمتة هذا. لا تدع أبدًا إنسانًا يعين رقم إصدار. يجب أن يولد خط الأنابيب الخاص بك معرف بناء يجمع بين:

  • طابع زمني لبدء البناء
  • رقم بناء تسلسلي
  • تجزئة commit من Git

بهذا المزيج، يمكنك أخذ أي أرتيفكت من سجل الأرتيفكتات الخاص بك ومعرفة بالضبط أي commit أنتجه، وأي خط أنابيب بناه، ومتى. لا تخمين. لا "أعتقد أن هذا كان من إصدار الأسبوع الماضي."

ضع الأرتيفكتات في سجل، وليس على خادم

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

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

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

رقِّ، لا تعِد البناء

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

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

لكن كيف تعرف أن الأرتيفكت لم يتلف أو يتم العبث به بين الاختبار والترقية؟ هذا هو مكان التحقق.

تحقق قبل أن تثق

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

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

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

شبكة الأمان

تعمل هذه الانضباطات الأربعة معًا كشبكة أمان:

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

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

قائمة مراجعة سريعة لخط الأنابيب الخاص بك

إذا كنت تقوم بإعداد أو مراجعة إدارة الأرتيفكت، فراجع هذا:

  • هل يبني خط الأنابيب كل أرتيفكت مرة واحدة بالضبط لكل commit؟
  • هل لكل أرتيفكت معرف إصدار آلي وقابل للتتبع؟
  • هل يتم دفع الأرتيفكتات إلى سجل مركزي فورًا بعد البناء؟
  • هل يقوم خط الأنابيب بترقية الأرتيفكتات عن طريق تغيير البيانات الوصفية، وليس عن طريق إعادة البناء؟
  • هل يتم إجراء التحقق من المجموع الاختباري أو التوقيع قبل الترقية إلى الإنتاج؟

إذا أجبت بـ "لا" على أي من هذه، فلديك فجوة تستحق الإصلاح قبل إصدارك التالي.

ماذا يعني هذا لفريقك

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

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