تريد إمكانية تتبع القطع الأثرية دون التخلي عن مؤهل SNAPSHOT

Question

خلفية. تستخدم مؤسستي Maven وBamboo وArtifactory لدعم عملية التكامل المستمر.نحن نعتمد على مؤهل Maven's SNAPSHOT للمساعدة في إدارة التخزين في Artifactory (تدوير إصدارات SNAPSHOT القديمة) وأيضًا للمساعدة في الحفاظ على عمليات التكامل بين الفرق محدثة (يقوم Maven بالتحقق من تحديثات تبعيات SNAPSHOT تلقائيًا على كل إصدار).

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

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

النهج الذي أخذناه في الاعتبار. الفكرة هي أننا نريد ختم الإصدارات بمكون رابع، مثل 1.8.2.1400، حيث المكون الرابع هو نسخة Subversion.(كسؤال جانبي، هل هناك مكون إضافي لـ Maven أو أي شيء آخر يفعل ذلك تلقائيًا؟) ولكن إذا فعلنا ذلك، فسنفقد ميزة SNAPSHOT بشكل أساسي نظرًا لأن Maven وArtifactory يعتقدان أن هذه إصدارات مختلفة.

نحن نستخدم Scrum، لذلك ننشر في بيئات الاختبار مبكرًا جدًا (مثل اليوم الثاني أو نحو ذلك).لا أعتقد أنه من المنطقي إزالة مؤهل SNAPSHOT في وقت مبكر من دورة التطوير لأننا نفقد فوائد SNAPSHOT مرة أخرى.

سأكون ممتنًا لمعرفة كيف تحل المنظمات الأخرى هذه المشكلة.

Answer 1

فقط لدائرة الظهر على هذا واحد، أردت مشاركة ما نفعله.

أساسا ننشر اللقطات يبني مثل 1.8.2 - لقطة في بيئة التطوير.لا تحتاج فرق أخرى إلى استخدام هذه المباني، لذلك من الجيد ترك -Snapshot عليها.

ولكن أي بناء ننشر في بيئة اختبار (E.G. اختبار وظيفي، اختبار النظام) أو الإنتاج يجب أن يشمل المراجعة؛E.G.، 1.8.2.1400.نسمي هذه "الكواد".سبب الإصرار على الكواد في الاختبار هو أنه يمكننا إرفاق القضايا (الميزات، Bugfixes، إلخ) بمراجعات محددة حتى يعرف المختبرون ما لاختباره.بالنسبة للإنتاج، فإنه حقا فقط لأننا نريد نشر نفس القطع الأثرية تماما التي اختبرناها، بحيث نقوم بنشر رباعية.

على أي حال، نأمل أن تكون المعلومات مفيدة لشخص ما.

Answer 2

إذا قمت بتمكين "uniqueversion" بالنسبة لك Snapshot Builds، فسيكون لكل لقطة منتشرة معرف فريد.يمكنك استخدام ذلك للتأكد من أنك تقوم بنشر الترويج بشكل صحيح عبر البيئات.

، كملاحظة جانبية، يمكنك استخدام البرنامج المساعد Buildnumber-Maven-Supply لإضافة Builter Buildnumbers إلى القطع الأثرية.

Answer 3

بدلاً من تضمين رقم الإصدار الخاص بمراجعة VCS في إصدار المنتج، نقوم بتضمين رقم إصدار CI في META-INF/MANIFEST-MF ملف .

انظر على سبيل المثال استخدام متغيرات بيئة Hudson لتحديد بنياتك .على الرغم من أن المقالة تنطبق على Jenkins/Hudson، إلا أنني أعتقد أنه من التافه نقلها إلى Bamboo.