Build and Artifact Management
A focused chapter on build and artifact management, with practical delivery concerns, trade-offs, and the operational questions behind CI/CD work.
من الكود المصدري إلى شيء يمكن تشغيله فعليًا
تعرف على الفرق بين الكود المصدري والأرتيفكت، ولماذا تحتاج التطبيقات إلى عملية بناء قبل النشر، وكيفية إدارة الأرتيفكتس بفعالية في مسار CI/CD.
لماذا يحتاج كل بناء إلى هوية فريدة
تعرف على أهمية إعطاء كل نتيجة بناء هوية فريدة لا تتغير، وكيفية دمج معرف البناء ورمز الالتزام والطابع الزمني لضمان التتبع والثقة في نشر البرمجيات.
أين تعيش بنياتك: لماذا يحتاج كل أثر إلى منزل
اكتشف أهمية وجود مستودع مركزي للأرتيفاكت في CI/CD. تعرف على دور الـ Registry كنقطة تسليم بين CI وCD، وكيف يضمن الاتساق بين البناء والنشر.
لماذا يجب ألا تعيد بناء التطبيق للإنتاج أبدًا
تعرف على الفرق بين إعادة بناء الأرتيفاكت وترقيته في CI/CD، ولماذا تؤدي إعادة البناء إلى مخاطر خفية في الإنتاج، وكيف تمنحك الترقية يقينًا بأن ما اختبرته هو ما يُنشر.
لماذا إعادة البناء للإنتاج أكثر خطورة مما تبدو عليه
لديك بناء ناجح في بيئة الاختبار. اجتازت الاختبارات. الفريق مستعد للنشر. يقول أحدهم: "لنقم فقط بسحب نفس العلامة، وإعادة البناء، والنشر للإنتاج." يبدو الأمر فعالاً، لكنه يقدم مشكلتين: فقدان إمكانية التتبع وفقدان قابلية إعادة الإنتاج.
لماذا يجب ألا تعيد بناء الأرتيفكت بعد اجتيازه الاختبارات أبدًا
تخيل أن فريقك أمضى ثلاث ساعات في اختبار بناء في بيئة التدريج. كل شيء أخضر. يقول مدير الإصدار: "عظيم، لنبنيه مرة أخرى للإنتاج." يبدأ شخص ما في ترجمة جديدة، يحزمها، وينشرها. بعد ساعة، يبدأ الإنتاج في إلقاء أخطاء لم تظهر في التدريج. الكود هو نفسه، لكن الأرتيفكت مختلف. لقد فقدت الضمان الوحيد الذي كان مهمًا: ما اختبرته ليس ما تشغله.