ما هي أفضل طريقة لإعداد خادم اختبار التكامل؟

Question

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

Answer 1

أنت بالتأكيد تريد تقسيم المهام.فيما يلي مثال جيد لتكوين CruiseControl.NET الذي يحتوي على أهداف (مهام) مختلفة لكل خطوة.ويستخدم أيضًا ملف common.build الذي يمكن مشاركته بين المشاريع مع القليل من التخصيص.

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

Answer 2

أستخدم TeamCity مع برنامج نصي لبناء nant.يسهل برنامج TeamCity إعداد جزء خادم CI، كما يسهل البرنامج النصي nant build تنفيذ عدد من المهام فيما يتعلق بإنشاء التقارير.

فيما يلي مقال كتبته حول استخدام CI مع CruiseControl.NET، وهو يحتوي على نص برمجي nant build في التعليقات والذي يمكن إعادة استخدامه عبر المشاريع:

التكامل المستمر مع نظام CruiseControl

Answer 3

النهج الذي أفضّله هو الإعداد التالي (في الواقع بافتراض أنك في مشروع .NET):

• CruiseControl.NET.
• مهام NANT لكل خطوة على حدة.Nant.Contrib لقوالب CC البديلة.
• NUnit لتشغيل اختبارات الوحدة.
• Ncover لتنفيذ تغطية التعليمات البرمجية.
• FXCop لتقارير التحليل الثابتة.
• التخريب للتحكم في المصدر.
• CCTray أو ما شابه ذلك في جميع صناديق التطوير للحصول على إشعار بالإصدارات والفشل وما إلى ذلك.

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

ما أفعله في هذه الحالات هو إنشاء ثلاثة تصميمات (أو ربما اثنين):

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

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

Answer 4

نحن نستخدم buildbot, ، مع تقسيم البناء إلى خطوات منفصلة.يمكن العثور على توازن بين تقسيم خطوات البناء بتفاصيل كافية وبين كونها وحدة كاملة.

على سبيل المثال، في منصبي الحالي، نقوم ببناء الأجزاء الفرعية لكل منصة من منصاتنا (Mac وLinux وWindows) على الأنظمة الأساسية الخاصة بها.لدينا بعد ذلك خطوة واحدة (مع بضع خطوات فرعية) تجمعها في الإصدار النهائي الذي سينتهي في التوزيعات النهائية.

إذا حدث خطأ ما في أي من هذه الخطوات، فمن السهل جدًا تشخيصه.

نصيحتي هي كتابة الخطوات على السبورة البيضاء بعبارات غامضة قدر الإمكان ثم بناء خطواتك على ذلك.في حالتي سيكون ذلك:

1. بناء قطع البرنامج المساعد
   1. تجميع لنظام التشغيل Mac
   2. تجميع للكمبيوتر
   3. تجميع لنظام التشغيل Linux
2. إنشاء الإضافات النهائية
3. تشغيل اختبارات البرنامج المساعد
4. بناء بيئة تطوير متكاملة (IDE) متوسطة (يتعين علينا تمهيد البناء)
5. بناء IDE النهائي
6. قم بإجراء اختبارات IDE

Answer 5

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

يجب أن تكون قادرًا على إنشاء مهمة واحدة كبيرة من الأجزاء الأصغر، على أي حال.

Answer 6

يوم سعيد،

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

</thebloodyobvious> (-:

هتافات ، روب

Answer 7

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

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

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

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