قيمة نظام فريق Microsoft ضمن فريق DEV فقط

Question

يبدو أن نظام فريق Microsoft هو منصة رائعة لتنفيذ الأنظمة الموجهة للعملية ، ولكن إذا قمت بتجريد الوصول إلى BAS و PM و Business Wepress المهنية ، المصادر ، أداة تتبع العيوب وخادم تكامل مستمر مثل Cruisecontrol أو TeamCity؟

Answer 1

نعم. كل تقنية بديلة ذكرتها هي شيء تدعمه حزمة نظام الفريق (إما في هذا الإصدار أو التالي). تم تصميم كل هذه المكونات لدمج بعضها البعض في TFS والعمل مع بعضها البعض. هذه أولوية عالية لفريق TFS لجميع المكونات. والنتيجة هي مجموعة من الميزات التي تتكامل في معظم الحالات مع بعضها البعض.

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

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

Answer 2

واحدة من نقاط البيع الكبيرة لـ TFS لفريقي هي التماسك الذي يوفره لدورة حياة المنتج الإجمالية. نحن نسمح لـ BAS و PMS ومستخدمي الأعمال أن يكون لديهم مستويات معينة من الوصول إلى TFS ، ولكن حتى لو لم نفعل ذلك ، فسيظل المنتج ذا قيمة كبيرة للاستخدام. القدرة على إدارة سير العمل لدينا داخل TFS وفرض الاتساق عبر فريق التطوير أمر رائع.

بعض الميزات التي توفرها TFS نستخدمها: الأمان ، الإبلاغ ، إدارة تدفق العمل ، بنيات متكاملة ، تنبيهات البريد الإلكتروني ، المتفرعة / الاندماج.

هل يمكنك سحبها باستخدام أدوات أخرى من الأدوات الأخرى؟ ربما ، ولكن لن يكون من السهل إدارتها وصيانتها ، وربما لن تكون قادرًا على سحب نوع البيانات اللازمة للإبلاغ وتتبع الطريقة التي يمكنك بها مع TFS.

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

افكاري.

Answer 3

بالتأكيد لديها قيمة. لا يوجد الكثير من ميزات العميل إلا في فريق SKUS (لا تدع الاسم يخدعك-فهي في المقام الأول فقط الإصدارات الجديدة "الفائقة الممتازة" ، والتي تحتوي أيضًا على مكافأة لطيفة تضم خادم Cal for TFS.) المواصفات الدقيقة المتاحة هنا: http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx

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

والسؤال هو ما إذا كان الأمر يستحق $$ لك. لماذا تستخدم Visual Studio Professional بدلاً من SharpDevelop؟ لماذا المصدرين بدلا من git؟ لماذا لا تفتح المجلدات المسمى خصيصًا؟

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