ما هي الطريقة الصحيحة للتعامل مع نسخة التجميع؟

Question

إنني أتطلع إلى تنفيذ بناء يومي لمشروع قادم.

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

لدي المخاوف التالية:

• هل يجب أن يكون لكل مجموعة رقم إصدار مستقل أم يجب أن يشاركوا جميعًا نفس الإصدار؟
• هل يجب علي استخدام إصدار * للبناء والمراجعة؟
• هل المراجعة ذات صلة بالبناء اليومي؟

Answer 1

نحن نختم جميع التجميعات داخل منتجاتنا مع نفس رقم الإصدار باستخدام الخطوات التالية:

• اربط جميع التجميعات إلى AssemblyInfocommon.cs تحتوي على معلومات رقم الإصدار: انظر هناعلى سبيل المثال.

• قم بإنشاء ملف AssemblyInfocommon.cs كجزء من البناء باستخدام (في حالتنا) مهمة Nant Asminfo ، والتحكم في التطواف .NET و SVN Revision Labeller

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

Answer 2

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

كان المخطط الذي استخدمته في شركة سابقة هو Major.minor.revision.build - لذلك في الإصدار 1.0 من المنتج ، كان إصدار نسخة التجميع وملف التجميع على كل مجموعة 1.0.0.1129 (على سبيل المثال). هذا جعل من السهل مطابقة التجميعات التي كانت جزء منها إصدار البرامج ، وصولاً إلى رقم الإنشاء. لقد أنجزنا ذلك باستخدام بحث مسبقًا واستبداله في كل ملف AssemblyInfo.cs لاستبدال رمز الرمز المميز بأرقام الإصدار التي توفرها عملية الإنشاء الآلية الخاصة بنا.

Answer 3

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

Answer 4

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

بقدر ما يذهب الترقيم ، أنا أتفق مع Guy Starbuck (Major.minor.revision.build). هذه هي الطريقة التي قمت بها دائمًا وقد عملت دائمًا بشكل جيد.

Answer 5

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

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