أفضل حل لعملية البناء لإدارة إصدارات البناء

Question

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

• مشروعي
  • التطبيق أ
  • مشترك1
  • مشترك2
  • التطبيق ب
  • التطبيق ج

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

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

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

المبدأ الآخر الذي نحاول اتباعه هو أن الكود الوحيد هو الذي تم إنشاؤه واختباره بواسطة خادم التكامل الذي نقوم بنشره بشكل أكبر.

الحل "CrusieControl Build Labels".

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

السبب وراء تسمية الشجرة الكاملة هو تضمين ليس فقط رمز التطبيق الفعلي (الموجود في مكان واحد في الشجرة المصدر) ولكن أيضًا جميع العناصر المشتركة (الموجودة في أماكن مختلفة في الشجرة).لذا فإن البناء الناجح لـ "Application A" سيصنف على الشجرة بأكملها مع التصنيف "ApplicationA35" على سبيل المثال.

ومع ذلك، قد تكون هناك مشكلة عند محاولة إعادة إنشاء هذا الإصدار وتعيين إصدار DLL قبل النشر حيث لن نتمكن بعد ذلك من الوصول إلى ملصق الإصدار الذي تم إنشاؤه بواسطة CruiseControl بعد الآن.إذا كانت جميع تسميات بناء CrusieControl فريدة لجميع المشاريع، فيمكننا استخدام الرقم فقط للتسمية ولكن هذا ليس هو الحال (يمكن أن يكون كل من التطبيقين A وB في نفس الوقت على الإصدار 35) لذلك يتعين علينا تضمين اسم التطبيق في ملصق.ومن هنا تسمية SourceSafe "Application35". كيف يمكنني بعد ذلك إعادة إنشاء الإصدار 34 وتعيين 1.0.0.34 على أرقام إصدارات DLL بمجرد إنشاء الإصدار 35؟

الحل "رقم المراجعة".

أخبرني أحد الأشخاص أن Subversion على سبيل المثال ينشئ رقم مراجعة لشجرة المصدر بأكملها في كل عملية تسجيل وصول - هل هذا هو الحال؟لديه SourceSafe شيء مماثل؟ إذا كان هذا صحيحًا، فالفكرة هي الحصول على رقم المراجعة هذا عند الحصول على أحدث نسخة والبناء على خادم CruiseControl.يمكن بعد ذلك استخدام رقم المراجعة لتعيين رقم إصدار DLL (على سبيل المثال "1.0.0.5678").أعتقد أنه يمكننا بعد ذلك الحصول على هذه المراجعة المحددة للإصدار الفرعي إذا لزم الأمر، ومن ثم سيتضمن ذلك التطبيق وجميع العناصر المشتركة حتى نتمكن من إعادة إنشاء إصدار محدد من الماضي. هل سينجح هذا وهل يمكن تحقيق ذلك أيضًا باستخدام SourceSafe؟

لخص

لذا فإن المتطلبين الرئيسيين هما:

1. يكون قادرا على تتبع رقم البناء/المراجعة للإنشاء ونشر مكتبة الارتباط الحيوي (DLL).
2. يكون قادرا على إعادة بناء مراجعة/إصدار سابق، وتعيين رقم الإصدار/المراجعة القديم على الملفات التنفيذية لهذا الإصدار (للامتثال للشرط 1).

فكيف يمكنك حل هذا؟ ما هو النهج المفضل لديك و كيف هل ستحلها (أو هل لديك فكرة مختلفة تمامًا؟)** يسر إعطاء إجابات مفصلة.**

السؤال مكافأة ما الفرق بين رقم المراجعة ورقم الإصدار ومتى يحتاج المرء حقًا إلى كليهما؟

Answer 1

مخططك سليم وقابل للتحقيق في VSS (على الرغم من أنني أقترح عليك التفكير في بديل، إلا أن VSS منتج قديم بالفعل).

بالنسبة إلى إصدار "CI" الخاص بك - يمكنك إلقاء نظرة على الإصدار مشروع مهام مجتمع MSBuild الذي يحتوي على مهام "الإصدار".عادةً ما يكون لديك "Version.txt" في شجرة المصدر الخاصة بك وستقوم مهمة MSBuild بزيادة رقم "الإصدار" بينما يتحكم المطورون في أرقام Major.Minor.Release.Revision (هكذا أراد أحد العملاء ذلك).يمكنك استخدام المراجعة إذا كنت تفضل ذلك.

سيكون لديك بعد ذلك مهام "FileUpdate" لتحرير ملف AssemblyInfo.cs بهذا الإصدار، وسيكون لملفات EXE و"DLL's" الخاصة بك الإصدار المطلوب.

وأخيرًا، ستقوم مهمة VSSLabel بتسمية جميع ملفاتك بشكل مناسب.

بالنسبة إلى إصدار "Rebuild" الخاص بك - يمكنك تعديل "Get" الخاص بك للحصول على ملفات من هذا التصنيف، ومن الواضح أنه لا يتم تنفيذ مهمة "الإصدار" (حيث أنك تحدد إصدارًا للإنشاء) ثم ستستخدم مهام FileUpdate رقم الإصدار هذا.

السؤال مكافأة:

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

إن الأمور الرئيسية والثانوية واضحة بذاتها - ولكن المراجعة التي استخدمتها دائمًا لمؤشر "الإصلاح العاجل".أنوي الحصول على إصدار "1.3" - والذي سيكون في الواقع منتجًا بإصدار 1.3.1234.0 على سبيل المثال.أثناء العمل على الإصدار 1.4 - وجدت خطأً - وأحتاج إلى إصلاح سريع مثل 1.3.2400.1.ثم عندما يكون 1.4 جاهزًا - نقول 1.4.3500.0

Answer 2

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

شكرًا!اجابة جيدة!ماذا سيكون الفرق ، ماذا سيكون من الأفضل حل هذا باستخدام التخريب على سبيل المثال؟ ريتشارد هالغرين (قبل 15 ساعة)

مشاكل VSS ليس لها علاقة بهذا المثال (على الرغم من أن ميزة "التسمية" التي أعتقد أنها يتم تنفيذها بشكل غير فعال ...)

فيما يلي بعض المشكلات المتعلقة بـ VSS

1) التفرع أمر مستحيل بشكل أساسي 2) لا يتم استخدام الخروج المشترك بشكل عام (أعرف بعض الأشخاص الذين حققوا نجاحًا في ذلك) 3) الأداء ضعيف للغاية - إنه أمر خبير "chatty" 4) ما لم يكن لديك مستودع صغير جدًا - إنه أمر غير موثوق تمامًا ، لدرجة أنه بالنسبة لمعظم المتاجر ، إنه قنبلة زمنية موقوتة.

بالنسبة إلى 4 - تكمن المشكلة في أن VSS يتم تنفيذه من خلال تمثيل المستودع بأكمله على أنه "ملفات مسطحة" في نظام الملفات.عندما يتجاوز حجم المستودع حجمًا معينًا (أعتقد أن 4 جيجابايت ولكني لست واثقًا من هذا الرقم) فإنك تحصل على فرصة "للفساد".ومع زيادة الحجم تتزايد فرص الفساد حتى يصبح الأمر شبه مؤكد.

لذا ألقِ نظرة على حجم المستودع الخاص بك - وإذا كنت ستصل إلى الجيجابايت - فإنني أوصي بشدة أن تبدأ التخطيط لاستبدال VSS.

بغض النظر - جوجل "VSS Sucks" يعطي 30 ألف زيارة...أعتقد أنك إذا بدأت في استخدام بديل - فسوف تدرك أنه يستحق كل هذا الجهد.

Answer 3

1. اطلب من CC.net تسمية الإصدارات الناجحة
2. اجعل كل مشروع في رابط الحل يرتبط بملف Solutioninfo.cs شائع يحتوي على سمات إصدار التجميع والملف (قم بالإزالة من كل مشروع Assemblyinfo.cs)
3. قبل الإنشاء، اطلب من التحكم في السرعة تشغيل استبدال regex لـ msbuild (من مهام مجتمع msbuild) لتحديث معلومات الإصدار باستخدام تسمية البناء cc.net (التي تم تمريرها كمعلمة إلى مهمة msbuild)
4. بناء الحل، وإجراء الاختبارات، وشرطي الفوركس وما إلى ذلك
5. يمكنك بشكل اختياري إرجاع ملف معلومات الحل

والنتيجة هي أن كافة التجميعات في الإصدار المنشور من cc.net لها نفس أرقام الإصدار التي تتوافق مع التسمية الموجودة في مستودع التعليمات البرمجية المصدر

Answer 4

يمكن لـ UppercuT القيام بكل هذا من خلال مهمة تعبئة مخصصة لتقسيم التطبيقات.وللحصول على رقم إصدار المصدر، قد تفكر في Subversion.

من السهل أيضًا البدء بجنون.

http://code.google.com/p/uppercut/

بعض التفسيرات الجيدة هنا: UppercuT