أفضل الممارسات/التوجيه للحفاظ على أرقام إصدار التجميع

Question

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

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

Answer 1

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

ما يلي يفترض أنك تستخدم شكل من أشكال التحكم في المصدر وخادم إنشاء. للسياق نستخدمه Teamcity والتخريب/git. TeamCity مجاني لعدد صغير (10) من المشاريع وهو خادم بناء جيد للغاية ولكن هناك البعض الآخر ، بعضها مجاني تمامًا.

ماذا يعني رقم الإصدار

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

Major.Minor.Build.Revision

• Revision هذا هو الرقم المأخوذ من التحكم في المصدر لتحديد ما تم بناؤه بالفعل.
• Build هذا هو عدد متزايد باستمرار يمكن استخدامه للعثور على بناء معين على خادم الإنشاء. إنه رقم مهم لأن خادم البناء قد يكون قد صمم نفس المصدر مرتين مع مجموعة مختلفة من المعلمات. يتيح لك استخدام رقم الإنشاء بالاقتران مع رقم المصدر تحديد ما تم بناؤه وكيف.
• Minor يجب أن يتغير هذا فقط عندما يكون هناك تغيير كبير في الواجهة العامة. على سبيل المثال ، إذا كانت واجهة برمجة التطبيقات (API) ، فهل ما زالت الكود المستهلك قادرًا على التجميع؟ يجب إعادة تعيين هذا الرقم إلى الصفر عندما يتغير الرقم الرئيسي.
• Major يشير إلى إصدار المنتج الذي أنت عليه. على سبيل المثال ، تخصص جميع مجموعات VisualStudio 2008 هي 9 و VisualStudio 2010 هي 10.

الاستثناء من القاعدة

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

Major.Minor.Macro.Build

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

ماذا تضع

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

• 1.2.0.0 (تجميع)
• 1.2.3.4 (FileVersion)

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

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

كيفية توصيلها معًا

يمكنك القيام بكل ما سبق يدويًا ولكنه سيكون مضيعة للوقت للغاية ، فيما يلي كيفية أتمتة العملية. كل خطوة يمكن تشغيلها.

• مسح ال AssemblyVersion و AssemblyFileVersion سمات من جميع ملفات AssemblyInfo.cs.
• قم بإنشاء ملف معلومات تجميع مشترك (اتصل عليه versionInfo.cs) وأضفه كعنصر مرتبط بجميع مشاريعك.
• يضيف AssemblyVersion و AssemblyFileVersion سمات إلى الإصدار مع قيم "0.0.0.0".
• قم بإنشاء مشروع MSBuild يقوم بإنشاء ملف الحل الخاص بك.
• أضف مهمة قبل الإنشاء الذي يقوم بتحديث versionInfo.cs. هناك عدد من مكتبات MSBuild مفتوحة المصدر التي تتضمن مهمة تجميع يمكن أن تضع رقم الإصدار. فقط قم بتعيينه على رقم تعسفي واختبار.
• أضف مجموعة عقارية تحتوي على خاصية لكل من قطاعات رقم الإنشاء. هذا هو المكان الذي تقوم فيه بتعيين التخصص والثانوي. يجب أن يتم تمرير رقم البناء والمراجعة كحجيلات.

مع التخريب:

<PropertyGroup>
    <Version-Major>0</Version-Major>
    <Version-Minor>0</Version-Minor>
    <Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
    <Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
    <Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
    <Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>

آمل أن أكون واضحًا ولكن هناك الكثير من المشاركين. الرجاء طرح أي أسئلة. سأستخدم أي ملاحظات لوضع منشور مدونة أكثر إيجازًا معًا.

• أرقام الإصدار في مجموعة مترجمة
• MSBuild Extension Pack
• Teamcity

Answer 2

AssemblyVersion] هو صفقة كبيرة جدا في .NET. فلسفة واحدة ، بتشجيع من قبل Microsoft هي أنك تدعها تلقائيًا ، وتؤثر الكل المشاريع التي تعتمد على التجميع المراد إعادة ترجمة. يعمل بشكل جيد إذا كنت تستخدم خادم بناء. انها ليست أبدا خاطئ - ظلم - يظلم شيء يجب القيام به ولكن احذر من الناس الذين يحملون السيوف.

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

يمكنك مزيد من تمديد هذا النهج عن طريق زيادة الإصدار فقط عند نشر التجميع على الآلات خارج متناول اليد. هذا هو النهج الذي تستخدمه Microsoft ، ونادراً ما تتغير أرقام إصدار مجموعات .NET. في الغالب بسبب الألم الكبير للغاية الذي يسببه على عملائها.

إذن ما تعظه Microsoft ليس ما يمارسه. ومع ذلك ، فإن عملية البناء والتحكم في الإصدار لا مثيل لها ، بل لديها حتى مهندس برمجيات مخصص يراقب العملية. لم ينجح بشكل جيد للغاية ، فإن الحمل الزائد لـ waithandle.waitone (int) على وجه الخصوص تسبب في قدر لا بأس به من الألم. ثابت في .NET 4.0 مع نهج مختلف للغاية ، ولكن هذا يتجاوز قليلا النطاق.

الأمر متروك لك وثقتك في مدى قدرتك على التحكم في عملية الإنشاء ودورات الإصدار لاتخاذ اختيارك. بخلاف ذلك ، يعد التلقائي التلقائي [AssemblyFileversion] مناسبًا جدًا. ومع ذلك ، فإن هذا هو الإزعاج ليس أيد.

Answer 3

يمكنك استخدام جزء البناء من رقم الإصدار للملابس التلقائية.

[assembly: AssemblyVersion("1.0.*")]

في بيئتك ، إصدار اختبار هو إصدار يحتوي على إصدار بناء! = 0. عند الإصدار ، تقوم بزيادة الجزء الثانوي وتعيين جزء البناء على 0 ، هذه هي الطريقة التي ستحدد بها التجميعات التي تم إصدارها.

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

Answer 4

اضافة الى إجابة برونومسكيس, ، أريد أن أشير إلى أنه بعد معيار الإصدار الدلالي 2.0 في Semver.org, Major.Minor.Build.Revision سيكون غير قانوني بسبب القاعدة أنه بعد زيادة عدد ما ، يجب إعادة تعيين جميع القيم العادية إلى اليمين إلى الصفر.

طريقة أفضل لاتباع المعيار هي الاستخدام Major.Minor+Build.Revision. هذا ليس للاستخدام في AssemblyVersionAttribute, ، ولكن يمكن استخدام سمة مخصصة أو فئة ثابتة بدلاً من ذلك.

يجب أن يكون Semver in Teamity متاحًا باستخدام حزمة الطاقة Meta-Runner. بالنسبة لـ Git مع Git-Flow (خاصة في عالم .NET) ، وجدت gitversion أن تكون مفيدة.

Answer 5

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

... لـ EX: 1.0.0.*

محفوظة - هذا يضيف FlexIblity إضافية ، في حالة تريد إجراء أي تغيير في المستقبل. ولكن كإعداد افتراضي ، احتفظ بها كـ 0.

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