تسريع التجميع التجميع 2.5 مرة مع فصل التبعية واختبار الحاويات
يمكن أن يتفاقم وقت التحويل البرمجي بسبب التبعيات الداخلية والخارجية المعقدة التي تتطور خلال عملية التطوير، بالإضافة إلى التغييرات في بيئات التجميع مثل نظام التشغيل أو بنية الأجهزة. فيما يلي بعض المشكلات الشائعة التي قد يواجهها المرء عند العمل على مشاريع الذكاء الاصطناعي أو مشاريع MLOps واسعة النطاق:
تجميع طويل للغاية - يتم تجميع التعليمات البرمجية مئات المرات كل يوم. مع وجود مئات الآلاف من أسطر التعليمات البرمجية في المكان، قد يؤدي حتى تغيير بسيط إلى تجميع كامل يستغرق عادةً ساعة أو أكثر.
بيئة التجميع المعقدة - يجب تجميع كود المشروع تحت بيئات مختلفة، والتي تتضمن أنظمة تشغيل مختلفة، مثل CentOS وUbuntu، والتبعية الأساسية، مثل GCC وLLVM وCUDA، وبنى الأجهزة. والتجميع في بيئة معينة قد لا يعمل عادةً في بيئة مختلفة.
التبعيات المعقدة - يتضمن تجميع المشروع أكثر من 30 تبعية بين المكونات وتبعيات الطرف الثالث. وغالباً ما يؤدي تطوير المشروع إلى تغييرات في التبعيات، مما يؤدي حتماً إلى تعارض التبعيات. التحكم في الإصدار بين التبعيات معقد للغاية بحيث يؤثر تحديث إصدار التبعيات بسهولة على المكونات الأخرى.
بطء تنزيل التبعيات التابعة للجهات الخارجية أو فشلها - تتسبب التأخيرات في الشبكة أو مكتبات التبعيات الخارجية غير المستقرة في بطء تنزيل الموارد أو فشل الوصول إليها، مما يؤثر بشكل خطير على تكامل التعليمات البرمجية.
من خلال فصل التبعيات وتنفيذ اختبار الحاويات، تمكنا من تقليل متوسط وقت التحويل البرمجي بنسبة 60% أثناء العمل على مشروع البحث عن تشابه التضمينات مفتوح المصدر Milvus.
فصل تبعيات المشروع
عادةً ما يتضمن تجميع المشروع عددًا كبيرًا من تبعيات المكونات الداخلية والخارجية. وكلما زاد عدد التبعيات في المشروع، أصبحت إدارتها أكثر تعقيدًا. ومع نمو البرنامج، يصبح تغيير أو إزالة التبعيات أو إزالتها أكثر صعوبة وتكلفة، بالإضافة إلى تحديد آثار القيام بذلك. الصيانة المنتظمة مطلوبة طوال عملية التطوير لضمان عمل التبعيات بشكل صحيح. يمكن أن تتسبب الصيانة الضعيفة أو التبعيات المعقدة أو التبعيات المعيبة في حدوث تعارضات تؤدي إلى إبطاء أو تعطيل التطوير. ومن الناحية العملية، يمكن أن يعني ذلك تأخر تنزيلات الموارد، وفشل الوصول الذي يؤثر سلبًا على تكامل التعليمات البرمجية، وغير ذلك. يمكن لفصل تبعيات المشروع أن يخفف من العيوب ويقلل من وقت التجميع، مما يسرع من اختبار النظام وتجنب العوائق غير الضرورية في تطوير البرمجيات.
لذلك، نوصي بفصل التبعيات في مشروعك:
- فصل المكونات ذات التبعيات المعقدة
- استخدم مستودعات مختلفة لإدارة الإصدارات.
- استخدم ملفات التكوين لإدارة معلومات الإصدار وخيارات التجميع والتبعيات وما إلى ذلك.
- أضف ملفات التهيئة إلى مكتبات المكونات بحيث يتم تحديثها مع تكرار المشروع.
تحسين التحويل البرمجي بين المكونات - سحب وتجميع المكون ذي الصلة وفقًا للتبعيات وخيارات التحويل البرمجي المسجلة في ملفات التكوين. ضع علامة على نتائج التحويل البرمجي الثنائي وملفات البيان المقابلة لها وحزمها، ثم ارفعها إلى مستودعك الخاص. إذا لم يتم إجراء أي تغيير على أحد المكونات أو المكونات التي يعتمد عليها، فقم بتشغيل نتائج التحويل البرمجي الخاصة به وفقًا لملفات البيان. بالنسبة لمشكلات مثل التأخير في الشبكة أو مكتبات تبعية الطرف الثالث غير المستقرة، حاول إعداد مستودع داخلي أو استخدام مستودعات معكوسة.
لتحسين التجميع بين المكونات
1- إنشاء رسم بياني لعلاقة التبعية - استخدم ملفات التكوين في مكتبات المكونات لإنشاء رسم بياني لعلاقة التبعية. استخدم علاقة التبعية لاسترداد معلومات الإصدار (فرع Git، والوسم، ومعرف التزام Git) وخيارات التحويل البرمجي والمزيد من المكونات التابعة في المنبع والمصب.
1.png
2- التحقق من التبعيات - قم بإنشاء تنبيهات للتبعيات الدائرية وتعارضات الإصدارات وغيرها من المشكلات التي تنشأ بين المكونات.
3- تسطيح الت بعيات - فرز التبعيات حسب البحث في العمق أولًا (DFS) ودمج المكونات ذات التبعيات المكررة لتشكيل رسم بياني للتبعية.
2.png
4- استخدم خوارزمية MerkleTree لتوليد تجزئة (تجزئة جذرية) تحتوي على تبعيات كل مكون بناءً على معلومات الإصدار وخيارات التجميع وغيرها. بالإضافة إلى معلومات مثل اسم المكون، تشكل الخوارزمية علامة فريدة لكل مكون.
3.png
5- استنادًا إلى معلومات العلامة الفريدة للمكون، تحقق مما إذا كان هناك أرشيف تجميعي مطابق موجود في الريبو الخاص. إذا تم استرجاع أرشيف تجميعي، قم بفك ضغطه للحصول على ملف البيان للتشغيل؛ إذا لم يكن كذلك، قم بتحويل المكون إلى تجميع، وقم بترميز ملفات كائنات التجميع المُنشأة وملف البيان، وقم بتحميلها إلى الريبو الخاص.
تنفيذ تحسينات التحويل البرمجي داخل المكونات - اختر أداة تخزين مؤقت للتحويل البرمجي خاصة باللغة لتخزين ملفات الكائنات المحولة مؤقتًا، وقم بتحميلها وتخزينها في المستودع الخاص. For C/C++ compilation, choose a compilation cache tool like CCache to cache the C/C++ compilation intermediate files, and then archive the local CCache cache after compilation. تقوم أدوات ذاكرة التخزين المؤقت للتجميع هذه ببساطة بتخزين ملفات التعليمات البرمجية المتغيرة واحدًا تلو الآخر بعد التجميع، ونسخ المكونات المجمعة لملف التعليمات البرمجية التي لم تتغير بحيث يمكن إشراكها مباشرةً في التجميع النهائي. يتضمن تحسين التجميع داخل المكونات الخطوات التالية:
- إضافة تبعيات التجميع الضرورية إلى ملف Dockerfile. استخدام Hadolint لإجراء فحوصات التوافق على ملف Dockerfile لضمان توافق الصورة مع أفضل ممارسات Docker.
- قم بنسخ بيئة التجميع وفقًا لإصدار سبرينت المشروع (الإصدار + البناء) ونظام التشغيل ومعلومات أخرى.
- قم بتشغيل حاوية بيئة التجميع المنسوخة، وانقل معرف الصورة إلى الحاوية كمتغير بيئة. إليك مثال على أمر للحصول على معرّف الصورة: "docker inspect " - النوع=صورة" - التنسيق "{{.ID}}" مستودع/بناء-إنف:v0.1-centos7".
- اختر الأداة المناسبة لتجميع ذاكرة التخزين المؤقت: أدخل أداة الاحتواء الخاصة بك لدمج وتجميع أكوادك وتحقق في المستودع الخاص بك إذا كانت هناك ذاكرة تخزين مؤقتة مناسبة للتجميع. إذا كانت الإجابة بنعم، قم بتنزيلها واستخراجها إلى الدليل المحدد. بعد أن يتم تجميع جميع المكونات، يتم حزم ذاكرة التخزين المؤقت التي تم إنشاؤها بواسطة أداة تجميع ذاكرة التخزين المؤقت وتحميلها إلى مستودعك الخاص بناءً على إصدار المشروع ومعرف الصورة.
تحسين التحويل البرمجي الإضافي
يشغل التجميع الأولي لدينا مساحة كبيرة جدًا على القرص والنطاق الترددي للشبكة، ويستغرق وقتًا طويلاً للنشر، اتخذنا الإجراءات التالية
- اختر الصورة الأساسية الأصغر حجمًا لتقليل حجم الصورة، على سبيل المثال: Alpine، وBoolbox، إلخ.
- تقليل عدد طبقات الصورة. إعادة استخدام التبعيات قدر الإمكان. دمج أوامر متعددة باستخدام "&&".
- تنظيف المنتجات الوسيطة أثناء بناء الصورة.
- استخدام ذاكرة التخزين المؤقت للصور لبناء الصورة قدر الإمكان.
مع استمرار تقدم مشروعنا، بدأ استخدام الأقراص وموارد الشبكة في الارتفاع مع زيادة ذاكرة التخزين المؤقت للتجميع، في حين أن بعض ذاكرات التخزين المؤقت للتجميع غير مستغلة بشكل كافٍ. قمنا بعد ذلك بإجراء التعديلات التالية:
تنظيف ملفات ذاكرة التخزين المؤقت بانتظام - التحقق بانتظام من المستودع الخاص (باستخدام البرامج النصية على سبيل المثال)، وتنظيف ملفات ذاكرة التخزين المؤقت التي لم تتغير منذ فترة أو لم يتم تنزيلها كثيرًا.
التخزين الانتقائي لملفات التحويل البرمجي الانتقائية - قم بتخزين الملفات التي تتطلب موارد كثيرة فقط في ذاكرة التخزين المؤقت، وتخطي ملفات التحويل البرمجي التي لا تتطلب الكثير من الموارد.
الاستفادة من اختبار الحاويات لتقليل الأخطاء وتحسين الاستقرار والموثوقية
يجب تجميع البرمجيات في بيئات مختلفة، والتي تتضمن مجموعة متنوعة من أنظمة التشغيل (مثل CentOS وUbuntu)، والتبعية الأساسية (مثل GCC وLLVM وCUDA)، وبنى أجهزة محددة. التعليمات البرمجية التي يتم تجميعها بنجاح في بيئة معينة تفشل في بيئة مختلفة. من خلال تشغيل الاختبارات داخل الحاويات، تصبح عملية الاختبار أسرع وأكثر دقة.
تضمن الحاويات أن بيئة الاختبار متسقة، وأن التطبيق يعمل كما هو متوقع. يقوم نهج الاختبار في الحاويات بتعبئة الاختبارات كحاويات صور وبناء بيئة اختبار معزولة حقاً. وجد المختبرون لدينا أن هذا النهج مفيد جدًا، مما أدى في النهاية إلى تقليل أوقات التجميع بنسبة تصل إلى 60%.
ضمان بيئة تجميع متسقة - نظرًا لأن المنتجات المجمعة حساسة للتغيرات في بيئة النظام، فقد تحدث أخطاء غير معروفة في أنظمة التشغيل المختلفة. يجب علينا وضع علامات وأرشفة ذاكرة التخزين المؤقت للمنتجات المجمّعة وفقًا للتغييرات في بيئة التجميع، ولكن يصعب تصنيفها. لذلك قمنا بإدخال تقنية التجميع في حاويات لتوحيد بيئة التحويل البرمجي لحل مثل هذه المشكلات.
الخاتمة
من خلال تحليل تبعيات المشروع، تقدم هذه المقالة طرقًا مختلفة لتحسين التحويل البرمجي بين المكونات وداخلها، مما يوفر أفكارًا وأفضل الممارسات لبناء تكامل مستقر وفعال للتعليمات البرمجية المستمرة. ساعدت هذه الأساليب في حل مشكلة بطء تكامل التعليمات البرمجية الناجمة عن التبعيات المعقدة، وتوحيد العمليات داخل الحاوية لضمان اتساق البيئة، وتحسين كفاءة التجميع من خلال تشغيل نتائج التجميع واستخدام أدوات التخزين المؤقت للتجميع لتخزين نتائج التجميع الوسيطة مؤقتًا.
أدت هذه الممارسات المذكورة أعلاه إلى تقليل وقت التحويل البرمجي للمشروع بنسبة 60% في المتوسط، مما أدى إلى تحسين الكفاءة الكلية لتكامل الأكواد بشكل كبير. من الآن فصاعدًا، سنستمر في التحويل البرمجي المتوازي بين المكونات وداخلها لتقليل زمن التحويل البرمجي بشكل أكبر.
تم استخدام المصادر التالية لهذه المقالة:
- "فصل الأشجار المصدرية في مكونات مستوى البناء"
- "عوامل يجب مراعاتها عند إضافة تبعيات الطرف الثالث إلى مشروع"
- "النجاة من تبعيات البرمجيات"
- "فهم التبعيات: دراسة تحديات التنسيق في تطوير البرمجيات" "دراسة تحديات التنسيق في تطوير البرمجيات"
نبذة عن المؤلف
تشيفنغ تشانغ هو مهندس أول في DevOps في Zilliz.com يعمل على قاعدة بيانات Milvus، وهي قاعدة بيانات متجهة مفتوحة المصدر، ومدرب معتمد من جامعة LF للبرمجيات مفتوحة المصدر في الصين. حصل على درجة البكالوريوس في إنترنت الأشياء (IOT) من معهد هندسة البرمجيات في قوانغتشو. أمضى حياته المهنية في المشاركة في مشاريع وقيادة مشاريع في مجال CI/CD، و DevOps، وإدارة البنية التحتية لتكنولوجيا المعلومات، ومجموعة أدوات السحابة الأصلية، والحاويات، وتحسين عملية التجميع.
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word