بناء مؤسسة الفريق أو TeamCity؟

Question

نحن في الغالب متجر MS في العمل نقوم بتطوير .NET LOB.نحن نستخدم أيضًا MS Dynamics لتطبيق CRM الخاص بنا...يستخدم جميع المطورين حاليًا VS/SQL Server 2008.نحن نستخدم أيضًا VSS، لكن الجميع يكرهونه في العمل وهذا في طريقه للزوال سريعًا.

لقد بدأنا مبادرتنا لتنفيذ TDD عبر الفريق (حوالي عشرات الأشخاص).لقد حصلت على إعداد TeamCity وتم تشغيل أول إصداراتي الآلية بنجاح باستخدام 2008 sln builder وأيضًا باستخدام SVN الذي قام أحد زملائي بإعداده والذي يقوم بتحليل التحكم في المصدر.عند العرض التوضيحي للإدارة، أعتقد أنهم بدأوا في شراء زيت الثعبان الخاص بي وتجاهلوا اقتراحات النظر في TFS.

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

أدرك أن TFS يشمل أكثر بكثير من مجرد خادم بناء ...لكنني لم أرغب في جعل هذا السؤال واسعًا جدًا على الأقل عن قصد. ما هي الإيجابيات/السلبيات العملية لاستخدام TFS/TFB بدلاً من TeamCity - على سبيل المثال.ما هي الفوائد التي سنخسرها/نربحها؟هل استخدم أي شخص هنا بالفعل كلا النظامين (TFS لـ TDD/CI وTeamCity/SVN) ويمكنه التحدث من وجهة نظر عملية؟

لقد أجريت بعض البحث حول هذا الموضوع، وقد ذكرت إحدى المشاركات التي وجدتها هنا على SO أن سلبيات TFB هي أنه يدعم MSBuild فقط.كنت أخطط لاستخدام FinalBuilder مع TeamCity؛ويبدو أنه يدعم TFS أيضًا ...

شكرا على أي نصيحة

يحرر:هل استخدم أي شخص TFS كخادم Build/CI الخاص به ويمكنه سرد قصص النجاح/الفشل؟

Answer 1

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

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

دعمهم لمكافحة SVN المصدر ممتازة، ونحن نحب حقيقة أنهم يدعمون كل من MSTest و nunit للاختبار الوحدة.

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

Answer 2

هذا السؤال لديه الكثير من الإجابات الجيدة حول TeamCity. لا يقارن TFS ولكن قد يتم إلقاؤه بعض الضوء في الفريق.

لقد استخدمت كلاهما، وكان لدي نجاحا مع كليهما، لكن فريق العمل كان أسهل كثيرا. تعتبر الفريق نسيم لإعداد وتكوين. لم يكن TFS. الفريق هو الصخور الصلبة، من السهل الحفاظ عليها ولديها مجرد أعمال واضحة. قام المطورون في JetBrains بعمل رائع يستجيب للمجتمع. يحصلون على إصدار كل من 6 إلى 8 أشهر يضيف قيمة حقيقية. TFS في دورة لمدة عامين أو أكثر.

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

لقد مررت من خلال ترقيات الأكنية المطلقة في الفريق. تقوم TFS بترقية TFS، استغرقنا السيطرة على المبنى ومصدرنا لمدة 3 أيام. أنا المشرف للجملة في مشروعنا ويستغرق بضع ساعات في الشهر. استغرق TFS بضعة أيام في الأسبوع.

لقد كانت TeamCity + SVN + VisualSvn هي بيئة منسقة تعمل في أي وقت مضى. كان TFS على نحو سلس بشكل عام في اليوم التالي، ولكن فقط إذا كان شخص ما كان هناك يحتفظ به تشغيله.

امل ان يساعد

Answer 3

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

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

لقد استخدمت أيضا finalbuilder مع TFS - سؤالي هناك ما الذي تشتريه حقا مع FinalBuilder أنه لا يمكنك القيام به مع Nant / Msbuild؟ الجواب في متجري هو لسوء الحظ قليلا جدا من المنظمة البحرية الدولية.

Answer 4

في البداية، راجع هذه المشاركة:

سفن مقابل.مؤسسة خادم فريق

فيما يتعلق بسؤالك حول البيئة التي تعزز TDD بشكل أفضل وما إلى ذلك، فإن ما يهمني هو أن نظام إدارة البناء أقل أهمية بكثير مما هو موجود في ملف البناء نفسه.يجب أن يحتوي ملف Ant أو MSBuild الخاص بك على الأهداف التي تقوم باختبارك.مع MSBuild أو Ant، ​​لا يتعين عليك استخدام مجموعة اختبار MS.لا يزال بإمكانك استخدام nUnit أو أي شيء آخر تريده.وهذا يعني أنه لا يهم إذا كان TFS يتصل بملف MSBuild الخاص بك، أو إذا كان CruiseControl كذلك، أو إذا كان TeamCity كذلك.كل ما هو ذكي موجود في ملف البناء والأدوات التي تدمجها معه.

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

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

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

Answer 5

كان Build TFS القديم XAML مقصود ومرهدة للغاية وغير لطيف للعمل معه. ومع ذلك، فإن نظام بناء TFS 2015 الجديد هو قفزات وحدود أفضل، وهو برنامج نصي يستند إلى الكثير من خطافات الويب وتكامل الطرف الثالث؛ مشابهة جدا في مدينة الفريق. أيضا، يدعم TFS الآن GIT، لذلك لم تعد تقتصر على استخدام عنصر تحكم إصدار Foundation Team (TFVC). أيضا، مع TFS، يمكنك استخدام التثبيت الخاص بك على Prem، أو يمكنك الاستفادة من محلول مستضاف من خلال VisualStudio.com. TFS رائعة لأنها واحدة بيئة متكاملة تماما (عناصر العمل والتخطيط والبناء والاختبارات والنشرات)، في حين أن مدينة الفريق هي مجرد حل بناء. عندما تم طرح هذا السؤال في الأصل في عام 2010، أود أن أوصت بيديك في المدينة. الآن على الرغم من أن 2 تنافسية للغاية. أود أن أقول أنه من شأنه أن يغلي إلى ما إذا كنت تريد حل جميع في واحد، ثم انتقل مع TFS، ولكن إذا كنت تبحث عن نظام بناء بحتة، ثم مدينة الفريق.

Answer 6

مقارنة بنشاط الفريق لخدمات فريق Visual Studio (أحدث عرض أحدث من Microsoft) من Microsoft):

• كلا العمل رائع لتنفيذ عملية التكامل المستمر

• TeamCity أكثر نضجا وكل شيء يعمل فقط.

• يتطور خدمات فريق Visual Studio على النقيض باستمرار للحاق بالركب مع الفريق وبعض الأشياء لا تعمل بشكل جيد (على سبيل المثال، حاول تشغيل المباني المستندة إلى المسارات التي تتغير من GIT - الوثائق ضعيفة ولا تعمل الميزة نفسها فقط (اعتبارا من أغسطس 2016))

• تجعل خدمات فريق Visual Studio من السهل الحصول على وكلاء يستند إلى سحابة يقومون بتشغيل Build Build (الجانب السلبي) هو أن لكل منها القيام بسحب نظيف لمستودعك لكل بناء قد يضيف دقيقة أو أكثر للبناء). يمكن كلاهما أيضا دعم وكلاء البناء المحلي الذي لا يحتاج إلى مسح دليل العمل لكل بناء جديد.

ولكن في كلتا الحالين، أود أن أوصي بشدة أن ننظر أيضا إلى Cakebuild الذي يتحرك معظم معلومات التكوين عنه كيف للقيام ببناء من نظام CI وإلى كود C # الموجود في مستودع GIT الخاص بك مع كل شفرة المصدر الأخرى. باستخدام Cakebuild، يمكنك تشغيل نفس الإنشاء محليا كما سترشح في نظام CI وإذا كنت بحاجة إلى العودة شهرا لإنشاء إصدار محدد لديك شفرة المصدر والبرنامج النصي المبني للقيام بذلك.

مع Cakebuild، يمكنك الآن التحرك بسهولة في التبديل بسهولة بين خدمات Teamcity و Visual Studio Team Services.

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

Answer 7

MS هي سنوات وراء في منطقة TDD / CI

كونه شخص لديه TDD لمدة 4 سنوات الآن أنت صحيح. لا تزال MS غير موجودة حتى تروج لها ولا تقدم أدوات تعمل بشكل جيد مع تدفق TDD.

لا تتعثر التعامل مع Visual Studio لأي نوع من الأتمتة، أو التحكم في المصدر، أو فترة سير العمل Agile (توقف عن استخدام TFS من فضلك !!). هذه الأشياء على الرغم من أنهم يقولون هو "جديد" هو متجانسة ويأتي دائما مع قضايا غريبة والخراجة. انها دائما مؤلمة.

لقد استخدمت مدينة الفريق، وهي ببساطة مدهش، والأشياء تعمل، وهي مصممة لسهولة الاستخدام، وهي مصممة ببساطة جيدا ومتوافقة مع معظم أدوات الاختبار، وما إلى ذلك. ابحث عن أدوات مصدر خارجية ومفتوحة للمساعدة في بناء CI أفضل. "يمكنك أن تفعل كل شيء بشكل صحيح في VS" لا يبيع، ولا يعمل. يتم استخدام الأشخاص NewDays ويجمعوا دائما عن أدوات مختلفة من الخارج لإنجاز الأمور. الاعتماد على جميع أدوات MS ليست هي الوحيدة ليست مجرد IMO ل .NET. MS يحب بيع "مهلا يمكنك فقط أن تفعل كل شيء هنا". لكن في نهاية المطاف مع أي شيء سوى الألم عندما تذهب إلى هذا الطريق وشرب Koolade (TFS، MS FACKS، وما إلى ذلك).

إذا كنت تخطط للقيام TDD، فلا تريد بالتأكيد أن تستخدم جميع أدوات MS. سيتم دفع إما "طريقهم" لفعل الأشياء التي غالبا ما تكون ملكية و / أو متضخة عند محاولة TDD بأدواتها أو تكون مقيدة تماما. بالنسبة إلى TDD، يجب أن تكون قادرا على الحصول على بعض المرونة والخيارات عند قررتك أن تقرر الطبقة في أطر اختبار مختلفة، ومكتبات التأكيد، إلخ.

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

توقف عن محاولة الاعتماد على فشل Microsofts في عروض الأداة Agile

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