سفن مقابل.خادم أساس الفريق [مغلق]

https://stackoverflow.com/questions/4219

08-06-2019
|

سؤال

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

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

الفرق الأكثر وضوحًا بين هذين المنتجين هو السعر.من الصعب التغلب على Apache Subversion (مجاني).يعد Team Foundation Server باهظ الثمن للغاية، لذا فإن الميزات الإضافية يجب أن تؤدي بالفعل إلى التخلص من Subversion.

هل لدى أي شخص خبرة عملية مع كليهما؟
كيف يقارنون؟
هل يستحق Team Foundation Server هذه التكلفة بالفعل؟

المحلول

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

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

نصائح أخرى

فيما يلي أكبر الاختلافات بين الاثنين بالنسبة لي، وقد استخدمت كليهما:

1) يرتبط TFS ارتباطًا وثيقًا بـ "طريقة Visual Studio" للقيام بالتطوير. هذا لا يعني أن TFS مقترن بإحكام بـ VS IDE، فهذا يعني أن TFS يكافح للحفاظ على نموذج "تسجيل الدخول"/"الخروج" المألوف لـ Visual SourceSafe، حتى عندما لم يعد نموذجًا مناسبًا بعد الآن.يعد مفهوم Subversion المتمثل في "الالتزام"/"التحديث" أكثر واقعية عندما يكون لديك مطورين قد يقضون وقتًا غير متصلين بالشبكة.تتوقع TFS أن يكون المطورون متصلين دائمًا بالخادم.وهذا ناقص كبير.أنا شخصياً أجد أن TFS أقل شفافية فيما يتعلق بكيفية تنظيم الملفات على الخادم وعلى القرص المحلي الخاص بك بسبب تكامل Visual Studio المحكم.حتى أكبر مؤيدي TFS يعترفون بأن نموذج تسجيل الوصول/المغادرة المتصل الخاص به ليس خيارًا مقنعًا للمطورين الذين يعملون دون اتصال.في مناخ حيث بدأ الناس في النظر إلى خيارات DVCS مثل git و Mercurial عبر SVN، يبدو نموذج "السحب" الخاص بـ TFS أشبه بالديناصور.

2) يكلف. أولئك الذين يقولون إن TFS ليس باهظ الثمن هم إما متاجر صغيرة جدًا، أو غير ملتزمين بشروط ترخيص TFS.أنت بحاجة إلى ترخيص وصول العميل للتعرف على كل ما تفعله.هل أنت مدير يدير الأخطاء فقط؟أنت بحاجة إلى ما يقرب من 250 دولارًا أمريكيًا (توجد 5 منها مضمنة في ترخيص TFS للبيع بالتجزئة).مستخدم أعمال يريد فقط الإبلاغ عن مشكلاته؟250 دولارًا كالوريًا.مطور؟250 دولارًا (ما لم يكن لديهم MSDN وفي هذه الحالة يتم تضمينه).الخادم؟500 دولار (مضمنة إذا كان لديك MSDN).بالطبع، سيخبرك شخص يبيع لك نسخة من TFS أن تعقب عناصر العمل مجاني للمستخدمين الإضافيين، ولكن يمكن لهؤلاء المستخدمين الإضافيين فقط رؤية عناصر العمل التي يقومون بإنشائها بأنفسهم، وليس عناصر عمل الفريق بأكمله، وهو ما لا مفيد جدًا في بيئة رشيقة وموجهة نحو الفريق.كل هذا يضاف عندما يكون لديك مؤسسة متوسطة الحجم، ويصبح من الصعب تبريره عندما تكون التكلفة الإضافية للعديد من أفضل المنتجات مثل SVN وCruiseControl.net هي 0 دولار.(إنصافًا لـ TFS، ما زلت أنتظر حقًا أداة تعقب جيدة لقضايا OSS)

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

رأيي لما يستحق:

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

أنا مندهش من أن الشخص الذي استخدم Subversion في الماضي قد يكون لديه رغبة/حاجة للتحكم في مصدر TFS.

تجربتي مع TFS (2005) كانت مروعة جدًا.لقد قرأت جميع أنواع المستندات والإرشادات المتعلقة بكيفية تنظيم مصدرك بشكل صحيح لتلبية احتياجات التطوير المختلفة.

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

مشكلتي الرئيسية مع TFS:

الدمج هو ألم بالمقارنة مع التخريب.
هناك أخطاء غير ثابتة.لقد واجهت مشكلة تتعلق بإعادة التسمية/الدمج والتي كانت معروفة منذ عامين ولن يتم إصدار الإصلاح أبدًا لعام 2005.انتهى بنا الأمر بنقل فرعنا إلى مجلد "مكسور" ونتجاهله الآن.
يعد وضع أقفال للقراءة فقط على ملفاتك بمثابة احتكاك.من يقول أنني بحاجة إلى تحرير الملفات الدفعية وإنشاء البرامج النصية داخل TFS حتى يتمكن من "التحقق منها" من أجلي؟التخريب يعرف الملفات التي تغيرت.لا توجد أقفال للقراءة فقط هناك.
سرعة.TFS بطيء للغاية عبر شبكة WAN، ولا يمكن استخدامه حقًا إلا إذا قمت بتوصيل VPN إلى كمبيوتر العمل الخاص بي، مما يجعل تجربة التطوير الخاصة بي بطيئة جدًا بشكل عام.
عدم وجود تكامل جيد بين سطر الأوامر والمستكشف.يعد تكامل IDE أمرًا رائعًا حقًا لبرنامج Get-Latest اليومي وإضافة الملفات وتسجيل الوصول، ولكن عندما تحتاج إلى القيام بأشياء عبر العديد من المشاريع، فمن الجيد أن يكون لديك أدوات جيدة تحت تصرفك.وقبل أن يقفز شخص ما في حلقي مدعيًا أن tf.exe يعمل بشكل جيد ...إنها ليست حقًا أداة خط cmd.على سبيل المثال، لا ينبغي أن يؤدي تسجيل الدخول إلى ظهور مربع حوار مشروط.

...والقائمة تطول.أعتقد أنه حتى مع كل هذا التكامل، هناك بدائل مجانية أفضل بكثير.

نحن متجر VS.NET، وقمنا بتنفيذ:

بوجزيلا لتتبع المشكلة
أباتشي التخريب كواجهة خلفية لمستودع التعليمات البرمجية المصدر
خادم فيسوال إس في إن لإدارة SVN على الخادم
السلحفاةSVN (في مستكشف Windows) و AhnkSVN أو VisualSVN (في Visual Studio) على العميل
CruiseControl.NET للبنيات الآلية

يكلف:فوائد $ 0:لا يقدر بثمن

إذا كان فريقك صغيرًا، أو لم تكن مستعدًا للمشاركة في عملية TFS، فإن أدوات SVN والأدوات مفتوحة المصدر هي الحل الأمثل.

كما أشار آخرون، يمنحك TFS الكثير من الميزات مقارنة بـ SVN في شكل إدارة المشروع وما شابه.بعد أن استخدمت كليهما، وعملت مع شركات كبيرة جدًا في تنفيذ TFS، إليك سنتي.

1) إذا كنت تستخدم TFS 2005، فقم بالترقية إلى TFS 2008.سوف تشكرني.هناك الكثير من التحسينات في TFS 2008 التي تجعله قابلاً للتطبيق.

2) إذا كنت تعيش في Visual Studio وتريد تكامل IDE، فانتقل إلى TFS.لقد استخدمت تكامل SVN ودائمًا ما أعود إلى استخدام TortoiseSVN.

3) إذا كنت تحب فكرة دمج الحسابات مع مصادقة Windows، فانتقل إلى TFS.الإدارة من هذه الغاية لطيفة.قد يكون هناك خطافات لـ SVN - لست متأكدًا من ذلك، ولكن إذا كنت تحب الإدارة التي تعتمد على واجهة المستخدم الرسومية، فمن الصعب التغلب على TFS.

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

5) إذا كان لديك أشخاص لن يقوموا بتنفيذه إذا لم يكن MSFT، فانتقل إلى TFS.

6) إذا كنت تفعل أكثر من مجرد .NET (عمل Java، Eclipse، وما إلى ذلك) فاستخدم SVN.نعم، هناك منتجات جيدة جدًا (مثل Teamprise) تعمل بشكل جيد مع TFS.ولكن ما لم تكن اللغات الأخرى جزءًا صغيرًا من متجرك، فما عليك سوى الالتزام بـ SVN.

وبعيدًا عن ذلك، فإن ميزات SCM لكليهما متكافئة تقريبًا.كلاهما يقوم بالتفرع والدمج، وكلاهما يقوم بعمليات تسجيل ذرية، وكلاهما يدعم إعادة التسمية والتحركات.أعتقد أنه بالنسبة للأشخاص الذين بدأوا للتو في مفهوم التفرع والدمج، فإن جعل الفروع مرئية في Source Control Explorer هو أمر جيد.

TFS في الحقيقة ليس باهظ الثمن (ربما 1200 دولار؟).بالمقارنة مع SVN، ربما يكون كذلك.يعد التكامل مع خدمات التقارير وSharePoint أمرًا رائعًا، ولكن مرة أخرى، إذا كنت لا تستخدم ذلك، فلا يهم.

ما أود قوله هو تنزيل الإصدار التجريبي من TFS لمدة 180 يومًا وتجربته.قم بإجراء تجربة جنبًا إلى جنب.أعتقد أنك ستكون سعيدًا بغض النظر عن الطريق الذي تسلكه.

كما يشير Ubiguchi إلى أن TFS ليس منتجًا للتحكم في الإصدار.من الواضح أن شراء TFS بقصد استخدامه فقط للتحكم في الإصدار سيكون مضيعة للمال.TFS عبارة عن مجموعة متكاملة من الأدوات لأتمتة جميع جوانب إدارة دورة حياة التطبيق (وهي موجهة إلى حد كبير إلى "المؤسسة".

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

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

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

لست على دراية بـ SVN (لم أستخدمه مطلقًا) - لذا لا يمكنني التعليق على أن "الدمج أسوأ مع TFS" - ولم أواجه خطأ الدمج الذي أبلغ عنه Ben S - لكنني كنت رائعًا النجاح في التفرع والدمج باستخدام TFS.

إحدى حالات الاستخدام التي أعرف أن TFS لا تزال ضعيفة جدًا هي للمستخدمين الذين يكونون "غير متصلين بالإنترنت" بشكل منتظم.TFS هو "منتج خادم" يفترض أن المستخدمين متصلون في معظم الأوقات.لقد تحسنت تجربة عدم الاتصال بالإنترنت في إصدار 2008 (كانت كئيبة في 2005) ولكن لا يزال أمامها طريق طويل لنقطعه.إذا كان لديك مطورين يحتاجون (أو يريدون) إلى قطع الاتصال بالشبكة لفترات طويلة من الوقت، فمن المحتمل أن تكون أفضل حالًا مع SVN.

ميزة أخرى يجب مراعاتها لمحبي SVN الذين يستخدمون TFS هي جسر إس في إن Codeplex الذي يسمح للمستخدمين باستخدام TortiseSVN للاتصال بـ TFS.أنا صديق وزميل جيد لي يستخدمه على نطاق واسع ويحبه.

يفاجئني أيضًا التعليق حول عدم وجود سطر الأوامر - أدوات سطر الأوامر واسعة النطاق (على الرغم من أن العديد منها يتطلب تنزيلًا منفصلاً أدوات كهربائية TFS

أظن أن تعليقات Ben مبنية على تقييم لإصدار 2005 والذي كان من الواضح أنه منتج "Microsoft V1.0".المنتج موجود حاليًا في الإصدار 2.1 وسيأتي الإصدار 3 في المستقبل القريب.

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

يجب أن يكون TFS على علم عند تحرير أي ملف، لذلك يجب أن تكون متصلاً بالخادم في جميع الأوقات.
يتم الخلط بين TFS إذا قمت بتحرير الملفات خارج IDE.علاوة على ذلك، يقوم بتعيين كافة الملفات للقراءة فقط في NTFS.

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

أخيرًا، يبلغ حجم Team Explorer (العميل) 400 ميجابايت، ويتطلب خادم TFS SharePoint ويومين للتثبيت.يبلغ حجم برنامج التثبيت التخريب بنقرة واحدة حوالي 30 ميجابايت وسيقوم بتثبيت الخادم لك في أقل من دقيقة.يتمتع TFS بالعديد من الميزات، لكن أساسه هش جدًا لدرجة أنك لن تستخدمه أو تهتم به أبدًا.يعد TFS مكلفًا من حيث الترخيص، وفي الوقت الذي سيضيع فيه المطورون الصراخ على تدفق المكدس بدلاً من كتابة التعليمات البرمجية: P

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

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

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

هنا نسخة مفتوحة المصدر من VisualSVN تسمى انخفيسن.إنه أفضل بكثير الآن بعد أن استحوذت عليه شركة Collabnet.

إذا كان كل ما تحتاجه هو التحكم بالمصدر، فإن TFS مبالغة.كان لدى أحد أصحاب العمل السابقين TFS وVSS وSubversion في مؤسستهم.لم يكن لدينا Active Directory أو Exchange Server 2003 في مؤسستنا، لذلك انتهى بنا الأمر إلى إنشاء مستخدمين منفصلين على خادم TFS حتى يتمكن المطورون من استخدامه.لقد واجهنا نفس أنواع مشاكل الدمج التي ذكرها Ben Schierman، إلى جانب سلوكيات عربات التي تجرها الدواب الأخرى التي دفعتنا نحو Subversion.

ما إذا كان TFS هو الخيار المناسب لك أم لا، فسوف يعتمد جزئيًا على ميزانيتك، وحجم فريق التطوير لديك، ومقدار الوقت والموظفين المتاحين لتكوين/صيانة الحل الخاص بك.إذا كنت تريد تتبع المشكلات الإضافية، وعناصر العمل، وإمكانات إحصائيات المشروع التي يوفرها TFS، فقد يكون من المفيد أن تبحث عن بدائل أخرى.تتكامل منتجات مثل JIRA (من Atlassian Systems) أو Trac بشكل جيد مع Subversion وتوفر نوع الإشراف الذي قد يقدمه مدير المشروع أو البرنامج بسعر أقل.

في بيئة مثالية، مع Active Directory، وExchange Server 2003 أو أعلى، والموظفين المخصصين للمستودع، من المرجح أن يكون TFS اختيارًا جيدًا.

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

خادم فيسوال إس في إن هذا خادم SVN كامل مع مكون إضافي لطيف لإدارته.يتيح لك استخدام مصادقة Windows مباشرة من خلال واجهة المستخدم.سهل.
سلحفاء قال ما يكفي من السلحفاة.
ankhsvn إنه مكون إضافي رائع لـ SCC.بالنسبة لأولئك الذين يريدون التكامل الكامل مع VS IDE، فإن الإصدار الأحدث هو مكون SCC الإضافي الكامل.وبذلك تحصل الآن على التكامل الكامل مجانًا.

الإعداد أعلاه مجاني 100% وسيساعدك على تنفيذ أي شيء تحتاجه للتحكم في المصدر.

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

على الرغم من أنك إذا كنت تتحدث فقط عن SCM، فأنا أفضّل SubVersion.لا أحب حقًا تكامل IDE.أنا أيضًا أحب اتفاقية SVN الخاصة بهيكل الجذع/العلامات/الفروع، والسهولة النسبية للتبديل بين الفروع.بدا الدمج أسهل في TFS بالرغم من ذلك.تتفوق واجهة المستخدم الخاصة بـ Tortoise على TFS، خاصة فيما يتعلق بإضافة ملف إلى الريبو.

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

بعد استخدام كليهما على نطاق واسع، أعتقد أن Wedge كان على المال في ملاحظة أن "TFS يتضمن تتبع الأخطاء وتتبع عناصر العمل وميزات أخرى خارجة عن التحكم بالمصادر".

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

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

لقد استخدمت كلاً من SVN و TFS.الميزة الرئيسية لاستخدام TFS هي تكاملها الوثيق مع Visual Studio.سيتم تتبع الأخطاء وتتبع المهام في مكان واحد.وستساعد التقارير التي تم إنشاؤها لهذه العناصر أصحاب المصلحة على البقاء على علم بحالة المشروع.

أنا أعمل في مشروع مع 5 أشخاص وقمنا مؤخرًا بالتبديل من SVN إلى TFS.لقد كانت العملية برمتها بمثابة كابوس.لدينا تعليمات برمجية تم إنشاؤها تلقائيًا من XMLSpy، ولا يتعرف TFS على الملفات المعدلة خارج VS2008.يمكن لأدوات TFS Power Tools فحص عملية الدفع الخاصة بك وإصلاح هذه المشكلة ولكن من المؤلم أن تتذكر استخدام هذه الأدوات.هناك مشكلة أخرى نواجهها باستمرار وهي أداة الدمج الافتراضية في TFS.إنها إلى حد بعيد أسوأ أداة دمج استخدمتها على الإطلاق.قد يعتقد المرء أن TFS سيكون قادرًا على التعامل مع عمليات دمج الحلول الأساسية ولكن حتى الآن لم يكن الأمر كذلك.

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

آدم

يعد TFS رائعًا لإدارة المشاريع وتتبعها، لكنني أشعر أن التحكم بالمصدر ليس جيدًا مثل SVN.وهنا لحوم البقر بلدي مع TFS:

نموذج الدخول والخروج

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

مطلوب VS للقيام بكل شيء

أحيانًا أرغب في تحرير ملف نصي والتحقق منه.وهذا يتطلب مني بدء تشغيل VS 2010، وهو وحش ضخم، فقط لتحرير ملف وإيداعه.الشيء الذي استغرق بضع ثوانٍ مع SVN يستغرق مني الآن دقيقة واحدة.

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

بعض العمليات التي كانت سهلة في SVN أصبحت الآن مؤلمة

ربما لم أكتشف ذلك بعد، لكنني وجدت أن التراجع عن مجموعة التغييرات كان أمرًا مملاً للغاية مع TFS.
تعد إضافة ملفات إلى التحكم بالمصادر، والتي لا تشكل جزءًا من الحل، بمثابة ألم كبير.يُظهر مستكشف التحكم بالمصدر TFS فقط الملفات الموجودة في التحكم بالمصادر، وليس الملفات غير الموجودة (ربما يوجد إعداد في مكان ما لهذا، لا أعرف).باستخدام Tortoise SVN، يمكنني ببساطة الضغط على زر Commit في مجلد واختيار الملفات التي أريد إضافتها.

أقود حاليًا الجهود المبذولة لتقييم TFS في شركتي مقابل Rational Suite وهو ما نستخدمه حاليًا.حتى الآن، TFS 2008 هو pwning Clearcase + Clearquest.تكامل بيئة التطوير هو المكان الذي يتألق فيه حقًا.

بلدي 10 سنتات:

كان TFS2005 مزحة - من الصعب تثبيتها ، وحتى من الصعب الحفاظ على TFS2008 كان مستقرًا - أسهل في التثبيت ، وصيانة أبسط ، والبناء الآلي الذي يعمل.TFS2010 هو ملحمة!- التثبيت سهل للغاية.الإدارة سهلة للغاية؛كل ذلك عبارة عن واجهة مستخدم مصممة بشكل جيد.إن دمجه مع VS2008 ليس بالأمر السهل نظرًا لأنه لا يمكنك إنشاء مشاريع في vs2008، فيجب عليك استخدام vs2010 (وهو أمر غبي).يتيح لك TFS2010 أيضًا تغيير موقع مشروع Sharepoint بدلاً من وجود تلك المجلدات الفرعية الفظيعة لـ TFS2008.يحتوي TFS2010 أيضًا على أدوات مثل المخطط المتوقف المفيد حقًا لإدارة المشاريع.يبدو الأمر كما لو أن TFS2010 مخصص لفريق الإنتاج بأكمله بما في ذلك العملاء!لا يزال يكلف الكثير على الرغم من :(

ضع في اعتبارك أيضًا أن TFS يتطلب الكثير من القدرات الحصانية من أجهزة الخادم.وعلى الأقل تراخيص Windows Server واحدة بالطبع.

أفضل الممارسات، كما اتبعت شركتنا، هي استخدام خادمين:الواجهة الأمامية (مع نقطة مشاركة متكاملة)، وخادم SQL مخصص في الواجهة الخلفية (نستخدم مجموعة المؤسسات).يمكن تثبيت TFS على جهاز واحد، ولكن لا ينبغي ذلك.

بالمقارنة، تم تثبيت خادم svn الخاص بنا على خادم Linux افتراضي بذاكرة وصول عشوائي تبلغ 256 ميجابايت ووحدة معالجة مركزية واحدة، ولا يزال أسرع بعدة درجات عند القيام بمهام شائعة مثل الدفع الشامل.كانت الأجهزة الافتراضية هي أقل الأجهزة التي يمكن لـ vshpere تعيينها!القرص سريع رغم ذلك (SAN).

أود أن أقترح أن TFS يتطلب أجهزة مخصصة بقيمة 5000 دولار على الأقل، بينما يمكن لخادم svn (على نظام Linux) العمل مع أي جهاز قديم بالنسبة لنظام التشغيل الحالي المستند إلى Windows.

في رأيي أن الأمر يعتمد على الوضع والبيئة التي يتم فيها تنفيذ المشروع.إذا كان لديك مشروع صغير وبسيط، فإن SVN رائع.كما كتب البعض بالفعل، يتكامل VisualSVN بشكل جيد مع Visual Studio st.ليس عليك القيام بعملية تسجيل الدخول/الخروج عبر نظام الملفات الأصلي.

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

نحن فريق صغير في عملية الترحيل من SVN إلى TFS2010.السبب الأكبر للقيام بذلك هو التكامل في Visual Studio وWebAccess لتتبع الأخطاء، والذي أصبح الآن جزءًا من TFS.

@آدم:نأمل أن يكون لدينا تجربة أفضل.لا أستطيع أن أقول بعد ...

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

إذا كنت سأختار التحكم بالمصادر الآن، فسأظل أستخدم SVN.

فيما يتعلق بالأدوات:- المكوّن الإضافي Ankhsvn Visual Studio جيد مثل التحكم في مصدر TFS - السلحفاة أفضل بكثير من نظير TFS

يعد TFS رائعًا، إذا كنت لا تحتاج إلى غير المطورين، للوصول إلى الأشياء مساءً.

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

كما أن إدارة الإنشاء في tfs 2005 على الأقل أمر فظيع، ولا يمكنها حتى الإنشاء مقابل 2008 slns.لا أحب حقًا أن يؤثر خيار التحكم في المصدر الخاص بي على خيارات النشر الخاصة بي، ولهذا السبب ليس فريقي متجرًا لـ svn.

لو أنه فقط بناءً على التحكم بالمصادر، سأختار SVN.تم تحسين الوظيفة الإضافية المجانية AnkhSVN لـ Visual Studio بشكل كبير في إصدارها الجديد.يمكنك أيضًا الحصول على الكود المصدري لـ SVN والوثائق رائعة!لقد تغيروا بعض الأشياء الغامضة في TFS 2010 Source Control، وبدون الكود المصدري، قد يكون استكشاف الأخطاء وإصلاحها أمرًا شاقًا للغاية.بالإضافة إلى ذلك، فأنت تعتمد على فريق MSDN لضخ المستندات وهم يقومون بذلك وفقًا لجدولهم الخاص وبعمقهم الخاص.

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

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

TFS بمقدار ميل.

لقد تسببت عن غير قصد في الكثير من المشكلات لنفسي باستخدام أسلوب SVN القائم على الملفات.مشاكل التحكم في المصدر التي واجهتها:TFS - 0 مشاكل على مدار عامين SVN - فقدت العد ...

نعم، أعلم أن سعر TFS يؤثر على معظم الشركات وهو أمر مؤسف.قد يكون لدى MS حصة أكبر بكثير في السوق (والأرباح) إذا كان لديها نموذج تسعير معقول.

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

لا تنتمي إلى StackOverflow