أدوات لمساعدة متجر صغير على تحقيق درجات أعلى في "اختبار جويل"

Question

الأسئلة من رقم 1 إلى رقم 4 اختبار جويل في رأيي، كل هذا يتعلق بأدوات التطوير المستخدمة ونظام الدعم المطبق للمطورين:

1. هل تستخدم التحكم بالمصادر؟
2. يمكنك جعل البناء في خطوة واحدة؟
3. هل جعل يبني يوميا؟
4. هل لديك قاعدة بيانات علة؟

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

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

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

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

بالنسبة لفريق مكون من فرد أو شخصين، تمت مناقشة ذلك بالفعل في SO بحيث يمكنك استخدام FogBugz On Demand، ولكن ما هي حلول تتبع الأخطاء الأخرى الموجودة للفرق الصغيرة؟

Answer 1

1. التحكم بالمصدر: التخريب أو زئبقي أو شخص سخيف
2. بناء الأتمتة: نانت, MSBuild, مجرفة, مخضرم
3. التكامل المستمر: CruiseControl.NET أو الأستمرارية أو جنكينز
4. تتبع القضية: تراك, بوجزيلا, تَوأَم (إذا كان يجب أن يكون .NET ومجانيًا)

لا تنس الاختبار الآلي مع وحدة, ملائم, ، و واتين.

Answer 2

1) التخريب

2) نملة / مخضرم

3) الأستمرارية

4) بوجزيلا / تراك

Answer 3

مجموعتي المفضلة:

1) التخريب.أنا مهتم بالتحكم في المصادر الموزعة ولكن لم تتح لي الفرصة لتجربة أي منها في حالة من الغضب حتى الآن.بالنسبة للحل المركزي فإن svn صلب كالصخر.

2) النملة.من الممتع استخدام Maven عندما يكون يعمل، لكن باعتباري أحد قراصنة النمل القدامى، أجد صعوبة في متابعة Maven عندما تسوء الأمور.

3) هدسون.لم يتم ذكرها حتى الآن ولكن بالتأكيد تستحق التحقيق.أداة قابلة للاستخدام بشكل لا يصدق ويتم صيانتها بنشاط.في السابق، دفعنا ثمن Anthill Pro الذي بدا هشًا وكان إصلاحه مؤلمًا في كل مرة يفشل فيه.

4) نحن ندفع ثمن جيرا.ليست رخيصة ولكنها أكثر قابلية للاستخدام من الخيارات مفتوحة المصدر التي نظرنا إليها ومرنة للغاية أيضًا.

Answer 4

مجموعتي الهندسية:

1. Git (أنا أحب GitHub، لكن Git لا يتطلب حلاً مستضافًا)
2. مجرفة
3. CruiseControl.rb
4. com.FogBugz

لا شك أن هذه الاختيارات تتأثر بمكدس التطوير الخاص بي، والذي يتضمن غالبًا Ruby وRails وSQLite وFirefox وOSX.

Answer 5

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

Answer 6

1. شخص سخيف
2. يصنع
3. كرون
4. تراك

أنا رجل قليل المقاطع ;-)

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

هذه الميزة هي ما أحبه في git.أعتقد أنه موجود فقط في أنظمة التحكم في الإصدارات الموزعة؛إن استخدام DVCS لا يعني أنه يتعين عليك فعليًا القيام بالتطوير الموزع.

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

إذا كنت تريد إنشاءات يومية، ضع أمر البناء في ملف cron.daily الخاص بك.قم بإعداد خطاف procmail للتعامل مع البريد من cron إذا لزم الأمر.

لتتبع الأخطاء، استخدم $(apt-cache search bug tracking).في الأساس، طالما أنه مكتوب على العلبة "متعقب الأخطاء" وأنت تعلم أن هناك أشخاصًا آخرين يستخدمونه، فمن المحتمل أن يعمل بشكل جيد.من بين النظاميين بوغزيلا، السرعوف و تراك.

Answer 7

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

Answer 8

كان جهاز تعقب المشكلات الجيد وغير مكلف نسبيًا axoSoft OnTime.لقد استخدمته لسنوات قبل أن أحصل على MS TFS.

نانت و مثبت السرعة هي العناصر الأساسية في بيئتي.

Answer 9

لا أعتقد أنك تحتاج حقًا إلى التشويش على .Net بعد الآن (انظر رد آخر)

لن أفكر في Vault، SVN هي حقًا الشركة الرائدة في السوق في الوقت الحالي (ومجانية).يبدو Git واعدًا جدًا ولكنه حاليًا عبارة عن سطر أوامر فقط مع منحنى تعليمي حاد.

MSBuild يتفوق على NAnt لـ .Net 2 أو 3.5

CC.Net ممتاز.

Answer 10

*4) ريدمين

أوصي بيتنامي لاختبار مكدسات مختلفة.إنه يحتوي على Trac وRedmine وSubversion، بالإضافة إلى العديد من العناصر الأخرى غير ذات الصلة.

Answer 11

راجع هذه المقالات حول التكامل المستمر باستخدام MSBuild، وCruiseControl.NET، وFxCop، وNUnit، وNCover، وSubversion...

من خنادق تطوير البرمجيات

Answer 12

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

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

Answer 13

من أجل أتمتة البناء والتكامل المستمر، قم بإلقاء نظرة على TeamCity من العقول النفاثة.

أنه يحتوي على الكثير من سمات وهو حقًا سهل الإعداد والاستخدام.

إذا كنت تستخدم Visual Studio 2005/2008، فسوف يقوم ببناء الحل الخاص بك مباشرة دون الحاجة إلى برامج نصية إضافية (إذا كان البناء هو كل ما تريده.)

سيقوم أيضًا بتنفيذ اختبارات الوحدة الخاصة بك وجمع الإحصائيات حول نجاح البناء وأوقات تنفيذ اختبار الوحدة وما إلى ذلك.

أفضل للجميع:الإصدار الاحترافي مجاني للفرق التي تضم ما يصل إلى 20 مستخدمًا و3 وكلاء بناء.

Answer 14

1. التحكم بالمصدر:السير الذاتية
2. بناء جنو جعل
3. وظيفة cron التي تستدعي البرامج النصية bash
4. com.bugzilla