سؤال

نحن حاليًا بصدد إعداد خادم التحكم بالمصدر/الإنشاء/والمزيد لتطوير .NET ونفكر إما في استخدام Team Foundation Server (الذي يكلف الكثير من المال) أو الجمع بين عدة خيارات مفتوحة المصدر ، مثل SourceForge Enterprise/GForge وSubversion وCruiseControl.net وما إلى ذلك.هل سار أي شخص في طريق OSS الكامل أم أنه TFS فقط إذا كنت تريد تصحيحه والبدء في العمل قريبًا؟

هل كانت مفيدة؟

المحلول

يستخدم عملي حاليًا عملية بناء OSS في الغالب مع التحكم في السرعة كمحرك وهو أمر رائع.أود أن أقترح أنه إذا كنت لا تعرف سبب حاجتك إلى TFS، فمن المحتمل أن الأمر لا يستحق التكلفة.

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

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

نصائح أخرى

لقد اتبعت دائمًا طريق OSS ولم أواجه أي مشكلة أبدًا.أود أيضًا أن أوصي بشدة بـ TeamCity لحل CI الخاص بك.هناك ترخيص مجاني وأعتقد أنه يتفوق على CC.NET لسهولة التكوين والتعليقات.

لقد كنت مستخدمًا يوميًا لـ TFS منذ حوالي 1.5 عام حتى الآن.

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

إذا كنت تستخدم TFS تأكد من تثبيت VSTS2008SP1.الغالبية العظمى من الأشخاص الذين رأيتهم ينشرون شكاوى يستخدمون إصدار 2005.2005 هو متلازمة "مايكروسوفت 1.0" الكلاسيكية.كان هناك الكثير من المشكلات التي تم إصلاحها بواسطة "الإصدارين" اللاحقين.

إن حزمة الخدمة لعام 2008 ليست مجرد إصلاح للأخطاء - ولكنها أضافت العديد من الميزات الجديدة.

فيما يتعلق بالاختيار مقابل OSS - هناك الكثير من المناقشات (هنا وفي أماكن أخرى).إنه ليس منتجًا رخيصًا - ولكنه الخيار الأفضل للعديد من السيناريوهات (والأسوأ بالنسبة للآخرين).

لقد نظرنا إلى TFS، لكن انتهى بنا الأمر باستخدام Subversion + Trac + VisualSVN.نحن لا نقوم بـ CI في الوقت الحالي ولكن أعتقد أن نظام تثبيت السرعة هو ما سنستخدمه.

لقد بدأت باستخدام Trac مع العديد من المشاريع مفتوحة المصدر، وهو أمر رائع.إنه في الواقع جزء فقط مما يفعله TFS، لذا سيتعين عليك اتخاذ قرار هناك - إذا كنت تستخدم كل شيء، فمن المحتمل أن يقوم TFS بعمل أفضل في ربط كل ذلك معًا.Trac هو متصفح ويكي/متعقب الأخطاء/المصدر.كل شيء مرتبط - عندما تكتب اسم صفحة WikiPage أو تقول "Fix bug #1234" في رسالة التزام، عندما ترى تلك الرسالة في Trac، تنتقل الروابط إلى الأماكن الصحيحة.إنها أداة تساعدك على القيام بعملك ولكنها تبقى بعيدة عن الطريق بشكل عام.

يعد VisualSVN جسرًا رائعًا بين TortoiseSVN (عميل Subversion) وVisualStudio، ويعمل على تحسين الإنتاجية بشكل كبير.لديهم نسخة تجريبية مجانية، وهي ليست باهظة الثمن بعد ذلك (50 دولارًا لكل مستخدم)، ولكنها جديرة بالاهتمام.

أحد الجوانب السلبية المحتملة لـ Trac هو وجوده في عالم Windows، ومن الصعب العمل على IIS.لقد قمت بتثبيت Trac عدة مرات، ولكني شعرت بالإحباط سريعًا أثناء محاولتي تشغيله بشكل صحيح.انتهى بي الأمر بتثبيت Apache على عنوان IP مختلف (يمكن أيضًا استخدام منفذ مختلف) وبعد ذلك كان الأمر سلسًا.

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

تستخدم شركتنا مجموعة CruiseControl/SVN/nAnt/JIRA بنجاح كبير.

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

يعد Subversion + Cruisecontol.Net بديلاً جيدًا.SVN غني بالميزات ومستقر ومرن.

الفائدة الحقيقية لاستخدام TFS مقارنة بمجموعة منفصلة من أدوات نظام التشغيل هي تكامل التدفق المتنوع للمعلومات المتاحة.

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

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

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

يعد مكدس TFS أكثر بكثير من مجرد التحكم بالمصدر وإعداد بناء CI/ليليًا.فكر في إدارة المشروعات وتقارير الأخطاء وكل ذلك يضيف إلى شيء أكثر من مجرد CruiseControl وSVN وNAnt.مجرد التقارير وحدها قد تكون تستحق الاستثمار.وتذكر أيضًا أنه إذا كنت مشتركًا في MSDN/شريك ISV الذهبي/إلخ.قد تحصل على بعض من هذا مجانا...

لقد بدأت مؤخرًا العمل مع TFS يومًا بعد يوم، وبعد أن أتيت من حزمة مفتوحة المصدر سابقًا، أجد أنها غير متوفرة تمامًا.

في حين أن تكامل جميع الأخطاء وتتبع المهام يعد ميزة رائعة حقًا، إلا أن السلبيات تثقل كاهلها.

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

لقد رأيت كلاهما عمليًا (على الرغم من أنني مطور Java).الجانب الإيجابي من أسلوب الاختيار والمزج هو أنه يمكنك اختيار أفضل القطع لكل شيء (على سبيل المثال.أود التحقق من Hudson for CI - فهو ممتاز لـ Java، ويعمل مع .Net أيضًا الأحمال من المكونات الإضافية وهو سهل الاستخدام حقًا).الجانب السلبي هو أنه عليك القيام بكل عملية التكامل بنفسك.ومع ذلك، هذا هو الحصول على كثير أسهل في عالم جافا.وأيضًا، لا تدع الأشخاص يخبرونك بأن المنتج المدعوم هو الأفضل.في العديد من منتجات OSS في هذا المجال، تكون الجودة ممتازة وتحصل عليها أحسن الدعم من المجتمع بدلاً من انتظار إجابة من عقد الدعم الخاص بالمورد (IBM، أنا أنظر إليك)

أتمنى أن يساعدك هذا.

أتفق بشدة مع النقطة القائلة بأن استخدام TFS لا يستحق إلا إذا كنت تعرف بالضبط ما تحتاجه.تعد الوظائف الإضافية الرخيصة أو المجانية المستندة إلى OSS، مثل Visual SVN وTestDriven.Net، جيدة جدًا لدرجة أن التكامل مع VS أصبح سلسًا بالفعل.

اعتقدت أنني سأطرح منظورًا جديدًا يمكن تناوله مع قليل من الملح لأنني لم أجربه بعد، لكنني أخطط لاستخدامه عض لـ CI في مشروع قادم.يتم تشغيل هذا فوق Trac+SVN، وكلاهما من الأدوات الرائعة التي استخدمتها في العديد من المشاريع بنجاح.

لقد قمنا ببناء حزمة تطوير تدريجيًا هنا، ونحن نستخدم حاليًا:

  • التخريب
  • مثبت السرعة
  • RedMine (يدمج تتبع الأخطاء مع التحكم بالمصادر ويتضمن wiki وإدارة المشاريع الأساسية وما إلى ذلك).

أعتقد أن TFS يستحق كل هذا العناء لجميع الميزات الإضافية المذكورة في المنشورات أعلاه.إن وظيفة البناء المستمر غير متوفرة بشكل خطير، لذلك قمنا بتعزيز هذا الجزء باستخدام CruiseControl.NET وهو أمر رائع.السبب الوحيد الذي يجعلنا نختار ضد TFS إذا أردنا القيام بذلك الآن هو أننا ننتقل إلى تطوير الأنظمة الأساسية لمنتجاتنا.لذا، إذا كنت قد فكرت في ذلك، ففكر في OSS.سيكون Subversion/Trac هو المزيج المفضل لدي بهذه الطريقة مع بقاء CruiseCONtrol.NET هو العمود الفقري.يعمل CC.NET باستخدام mono بشكل جيد على Linux وMac.

يحتوي TFS2010 على TFS Basic، والذي لا يكلف شيئًا (بالإضافة إلى اشتراك msdn/رخصة الاستوديو المرئي).ويقتصر على ترخيص واحد لكل ترخيص VS، ولكنك تحتاج فقط إلى تراخيص إضافية لغير مستخدمي VS

إن أتمتة واجهة المستخدم في VS2010 وحدها تجعل TFS فائزًا في تجميع الحلول مفتوحة المصدر معًا

ومن الجدير بالذكر أن أفضل بديل لمجموعة واسعة من ميزات TFS ليس بالضرورة OSS، ولكنه تجاري منخفض الميزانية، مثل نديبند لجودة التعليمات البرمجية واستكشاف الهندسة المعمارية، تغطية لتغطية الكود، TestDriven.NET للاختبار المتداخل في IDE ...

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top