كيف تنظم مستودع التحكم في الإصدار الخاص بك؟

https://stackoverflow.com/questions/222827

03-07-2019
|

سؤال

أولاً أعرف عن هذا: كيف يمكنك تنظيم مستودع التخريب لمشاريع البرامج الداخلية؟التالي السؤال الحقيقي:يقوم فريقي بإعادة هيكلة مستودعنا وأبحث عن تلميحات حول كيفية تنظيمه.(SVN في هذه الحالة).وهنا ما توصلنا إليه.لدينا مستودع واحد ومشاريع متعددة ومتعددة svn:الإسنادات الترافقية الخارجية

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

لمسح المفردات:الحل يعني منتجًا واحدًا، والمشروع هو مشروع Visual Studio (ينتج عنه ملف .dll واحد أو .exe واحد)

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

ما رأيك في هذا التخطيط؟خاصة فيما يتعلق باستخدام svn:externals.إنه ليس حلاً مثاليًا، ولكن بالنظر إلى جميع الإيجابيات والسلبيات، فهو أفضل ما يمكن أن نفكر فيه.كيف يمكنك أن تفعل ذلك؟

المحلول

إذا اتبعت توصياتي أدناه (التي اتبعتها لسنوات)، فستتمكن من:

- ضع كل مشروع في أي مكان في التحكم بالمصادر، طالما أنك تحافظ على البنية من الدليل الجذر للمشروع إلى الأسفل

- بناء كل مشروع في أي مكان وعلى أي جهاز، مع الحد الأدنى من المخاطرة والحد الأدنى من الإعداد

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

- البناء والعمل مع أي مجموعة من المشاريع، لأنها مستقلة

- إنشاء نسخ/إصدارات متعددة من مشروع واحد والعمل عليها، لأنها مستقلة

- تجنب ازدحام مستودع التحكم بالمصادر بالملفات أو المكتبات التي تم إنشاؤها

أوصي (هنا لحم البقر):

حدد كل مشروع لإنتاج تسليم أساسي واحد، مثل .DLL، أو .EXE، أو .JAR (افتراضي مع Visual Studio).
قم ببناء كل مشروع كشجرة دليل ذات جذر واحد.
قم بإنشاء برنامج نصي بناء آلي لكل مشروع في الدليل الجذر الخاص به والذي سيبنيه من الصفر، دون أي تبعيات على IDE (ولكن لا تمنع إنشاءه في IDE، إذا كان ذلك ممكنًا).
فكر في مشروعات nAnt لـ .NET على نظام التشغيل Windows، أو شيء مشابه يعتمد على نظام التشغيل لديك، أو النظام الأساسي المستهدف، وما إلى ذلك.
اجعل كل برنامج نصي لبناء مشروع يشير إلى تبعياته الخارجية (الطرف الثالث) من دليل "مكتبة" مشترك محلي واحد، مع تحديد كل ثنائي من هذا القبيل بالكامل بواسطة الإصدار: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.
اجعل كل برنامج نصي لبناء مشروع ينشر التسليم الأساسي إلى دليل "إخراج" محلي مشترك واحد: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.
اجعل كل برنامج نصي لبناء مشروع يشير إلى تبعياته عبر مسارات مطلقة قابلة للتكوين وإصدار كامل (انظر أعلاه) في دليلي "المكتبة" و"الإخراج"، وليس في أي مكان آخر.
لا تسمح أبدًا لمشروع ما بالإشارة مباشرة إلى مشروع آخر أو أي من محتوياته - اسمح فقط بالإشارات إلى التسليمات الأولية في دليل "الإخراج" (انظر أعلاه).
اجعل كل برنامج نصي لبناء مشروع يشير إلى أدوات البناء المطلوبة من خلال مسار مطلق قابل للتكوين وإصدار كامل: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.
اجعل كل مشروع إنشاء محتوى مرجعي للبرنامج النصي من خلال مسار مطلق بالنسبة إلى الدليل الجذر للمشروع: ${project.base.dir}/src, ${project.base.dir}/tst (يختلف بناء الجملة حسب أداة البناء).
اطلب دائمًا وجود برنامج نصي لبناء المشروع للإشارة إلى كل ملف أو دليل عبر مسار مطلق وقابل للتكوين (مجذر في دليل محدد بواسطة متغير قابل للتكوين): ${project.base.dir}/some/dirs أو ${env.Variable}/other/dir.
لا تسمح أبدًا لبرنامج نصي لبناء المشروع بالإشارة إلى أي شيء بمسار نسبي مثل .\some\dirs\here أو ..\some\more\dirs, ، استخدم دائمًا المسارات المطلقة.
لا تسمح أبدًا لبرنامج نصي لبناء المشروع بالإشارة إلى أي شيء باستخدام مسار مطلق لا يحتوي على دليل جذر قابل للتكوين، مثل C:\some\dirs\here أو \\server\share\more\stuff\there.
لكل دليل جذر قابل للتكوين تمت الإشارة إليه بواسطة برنامج نصي لبناء المشروع، حدد متغير البيئة الذي سيتم استخدامه لتلك المراجع.
حاول تقليل عدد متغيرات البيئة التي يجب عليك إنشاؤها لتكوين كل جهاز.
على كل جهاز، قم بإنشاء برنامج نصي لـ Shell يحدد متغيرات البيئة الضرورية، والتي تكون خاصة بهذا الجهاز (وربما خاصة بهذا المستخدم، إذا كان ذلك مناسبًا).
لا تضع البرنامج النصي لشل التكوين الخاص بالجهاز في التحكم بالمصدر؛بدلاً من ذلك، لكل مشروع، قم بإنشاء نسخة من البرنامج النصي في الدليل الجذر للمشروع كقالب.
اطلب من كل برنامج نصي لإنشاء مشروع التحقق من كل متغيرات البيئة الخاصة به، وإحباطه برسالة ذات معنى إذا لم يتم تعريفها.
مطالبة كل برنامج نصي لبناء مشروع بالتحقق من كل من الملفات التنفيذية لأداة البناء التابعة له، وملفات المكتبة الخارجية، والملفات القابلة لتسليم المشروع التابع، وإحباطه برسالة ذات معنى في حالة عدم وجود هذه الملفات.
قاوم إغراء الالتزام بأي ملفات تم إنشاؤها في التحكم بالمصادر - لا توجد تسليمات للمشروع، ولا يوجد مصدر تم إنشاؤه، ولا توجد مستندات تم إنشاؤها، وما إلى ذلك.
إذا كنت تستخدم IDE، فقم بإنشاء أي ملفات تحكم بالمشروع يمكنك إنشاؤها، ولا تلزمها بالتحكم بالمصادر (وهذا يشمل ملفات مشروع Visual Studio).
إنشاء خادم بنسخة رسمية من جميع المكتبات والأدوات الخارجية، ليتم نسخها/تثبيتها على محطات عمل المطورين وبناء الأجهزة.قم بعمل نسخة احتياطية منه، مع مستودع التحكم بالمصدر الخاص بك.
إنشاء خادم تكامل مستمر (جهاز بناء) بدون أدوات تطوير على الإطلاق.
فكر في استخدام أداة لإدارة مكتباتك وتسليماتك الخارجية، مثل Ivy (المستخدمة مع Ant).
لا تستخدم Maven، فهو سيجعلك سعيدًا في البداية، ثم يجعلك تبكي في النهاية.

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

ملاحظة إضافية بخصوص حلول Visual Studio:لا تضعهم في التحكم بالمصادر!باستخدام هذا الأسلوب، لن تحتاج إليها على الإطلاق أو يمكنك إنشاؤها (تمامًا مثل ملفات مشروع Visual Studio).ومع ذلك، أجد أنه من الأفضل ترك ملفات الحلول للمطورين الفرديين لإنشاء/استخدام ما يرونه مناسبًا (ولكن لا يتم تسجيل الوصول إلى التحكم بالمصادر).أحتفظ ب Rob.sln الملف الموجود على محطة العمل الخاصة بي والذي أشير منه إلى مشروعي (مشاريعي) الحالية.نظرًا لأن جميع مشاريعي مستقلة، يمكنني إضافة/إزالة المشاريع حسب الرغبة (وهذا يعني عدم وجود مراجع تبعية قائمة على المشروع).

يرجى عدم استخدام عناصر Subversion الخارجية (أو ما شابه ذلك في الأدوات الأخرى)، فهي عبارة عن نمط مضاد، وبالتالي فهي غير ضرورية.

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

@فون سي:أنت لا تريد العمل في جميع الأوقات مع "ant.jar" بدلاً من "ant-a.b.c.d.jar" بعد أن تصاب بالحرق عندما يتعطل البرنامج النصي الخاص بالإنشاء لأنك قمت بتشغيله دون قصد باستخدام إصدار غير متوافق من Ant.وهذا شائع بشكل خاص بين Ant 1.6.5 و1.7.0.بشكل عام، أنت تريد دائمًا معرفة الإصدار المحدد من كل مكون يتم استخدامه، بما في ذلك النظام الأساسي الخاص بك (Java A.B.C.D) وأداة البناء الخاصة بك (Ant E.F.G.H).بخلاف ذلك، ستواجه في النهاية خطأً وستكون أول مشكلة كبيرة تواجهك هي تعقب إصدارات المكونات المختلفة المتضمنة.من الأفضل ببساطة حل هذه المشكلة مقدمًا.

نصائح أخرى

وأعتقد أن عملي التحكم الإصدار باستخدام التخريب كل ما تحتاجه لتنظيم المخزون الخاص بك.

لقد وضع لنا ما يصل إلى ما يقرب من تطابق بالضبط ما كنت قد نشرت. نحن نستخدم الشكل العام:

\Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific

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

لماذا يكون كل شيء في مستودع واحد؟ لماذا لا يكون مجرد مستودع منفصل لكل مشروع (يعني "الحل")؟

حسنا، على الأقل كنت تستخدم لنهج مستودع-مشروع واحد لكل و. هيكل المستودع الخاص بك يبدو overcomplicated لي.

وكم مشروع كنت تخطط لوضع في هذا مستودع واحد كبير؟ 2؟ 3؟ 10؟ 100؟

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

وماذا عن فوضى من كل أرقام إصدار تلك؟ أرقام إصدار مشروع واحد يذهب مثل 2 و 10 و 11، في حين يذهب البعض مثل 1، 3، 4، 5، 6، 7، 8، 9، 12 ...

وربما أنا أحمق، لكني أحب مشروع واحد في مستودع.

وأعتقد أن العيب الرئيسي للهيكل المقترح الذي سيتم تعيين إصدار المشاريع المشتركة فقط مع الحل الأولى التي تمت إضافتها إلى (ما لم إس: الظواهر هي مربي الحيوانات من أنا تخيل). على سبيل المثال، عند إنشاء فرع للإصدار الأول من Solution2، لن تكون متفرعة PROJECT1 لأنه يعيش في Solution1. إذا كنت بحاجة إلى بناء من هذا الفرع في وقت لاحق (نشرة QFE)، فإنه سيتم استخدام أحدث إصدار من PROJECT1 بدلا من الإصدار من PROJECT1 في وقت الفرع.

لهذا السبب، قد يكون من المفيد لوضع مشاريع مشتركة في واحد أو أكثر المشتركة حلول (وبالتالي الدلائل المستوى الأعلى في الهيكل الخاص) ثم فرع لهم مع كل إصدار من أي الحل .

لإضافة لقضية المسار النسبي:

ولست متأكدا من أنها مشكلة:
مجرد الخروج Solution1 / جذع تحت الدليل المسمى "Solution1"، كما سبق لSolution2: هدف "الدلائل" التي تمثل في الواقع الفروع هو لا يكون مرئيا المستوردة مرة واحدة في مساحة العمل. وبالتالي المسارات النسبية ممكنة بين "Solution1" (في الواقع 'Solution1 / الجذع') و "Solution2" (Solution2 / الجذع).

وRE: المسار النسبي وقضية ملف مشترك -

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

ما زلنا نعمل ذلك ولدي 3 جهود مختلفة (العملاء المختلفة) التي لا بد لي من حل الآن منذ أن تولى إنشاء إما غير موجودة أو ضعف التحكم في الإصدار.

ولدي تصميم مماثل، ولكن جذعي والفروع، والعلامات على طول الطريق في الأعلى. لذلك: / جذع / الرئيسي / جذع / تيلس، / الفروع / الإفراج / وغيرها

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow