ما هي بعض الحجج ضد استخدام التكامل المستمر؟

Question

أستطيع أن أفكر في الكثير من الأسباب الوجيهة لاستخدامه؛ومع ذلك، ما هي سلبيات لذلك؟

(بصرف النظر عن شراء خادم آخر)

ما هي بعض المزايا لاستخدام البناء اليومي بدلا من ذلك؟

Answer 1

(تجدر الإشارة إلى أنني أعني بـ "التكامل المستمر". الآلي التكامل مع الآلي عملية البناء و تلقائيا يدير الاختبارات و تلقائيا يكتشف فشل كل قطعة.

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

هناك الكثير من الطرق للقيام بالتكامل المستمر بشكل خاطئ.)

---

لا أستطيع التفكير في أي سبب لعدم إجراء اختبار التكامل المستمر.أعتقد أنني أفترض أن "التكامل المستمر" يشمل الاختبار.فقط لأنه يجمع لا يعني أنه يعمل.

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

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

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

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

تتمثل ميزة إجراء البناء اليومي في أنك تعلم على الأقل أن هناك إنشاءًا كاملاً ونظيفًا واختبارًا يتم تنفيذه كل يوم.ولكن يجب عليك أن تفعل ذلك على أي حال.

Answer 2

وأنا لا أعتقد أن هناك أي سلبيات لذلك. ولكن من أجل من ذي الحجة، وهنا href="http://www.anthillpro.com/blogs/anthillpro-blog/2008/07/14/1216083300000.html" المادة اريك Minick ل على UrbanCode <م> ( "الأمر يتعلق الاختبارات لا يبني".) وينتقد الأدوات التي تعتمد على <لأ href = "http://martinfowler.com/articles/continuousIntegration.html" يختلط = "noreferrer"> عمل مارتن فاولر قائلة إنها لا تدع وقتا كافيا للاختبارات.

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

Answer 3

كان لدى جيمس شور سلسلة رائعة من إدخالات المدونة حول مخاطر التفكير في أن استخدام أداة CI مثل CruiseControl يعني أنك تقوم بالتكامل المستمر:

• لماذا لا أحب نظام CruiseControl
• التكامل المستمر هو موقف وليس أداة
• التكامل المستمر بدولار واحد في اليوم

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

Answer 4

وعموما هناك حالتين حيث رأيت التكامل المستمر حقيقة غير منطقي. نضع في اعتبارنا أنا داعية كبيرة من CI ومحاولة استخدامه عندما استطيع.

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

أما السيناريو الآخر الذي قد سمع المذكورة I هو أن CI لا معنى له إذا كنت لن تفعل أي شيء مع النتائج. على سبيل المثال، إذا كان برنامج لديه ليتم إرسالها إلى QA، ويمكن للموظفين QA ننظر فقط حقا في نسخة جديدة كل بضعة أيام، فإنه لا معنى ليبني كل بضع ساعات. إذا مطورين آخرين لن ننظر إلى مقاييس رمز ومحاولة تحسينها، فإنه لا معنى لتتبع لهم. منح هذا ليس خطأ من CI أنها ليست تقنية جيدة، هو عدم وجود فريقك على استعداد لاحتضان CI. ومع ذلك، تنفيذ نظام CI في مثل هذا السيناريو لا معنى له.

Answer 5

عند بدء التشغيل، فإنه يأخذ بعض الوقت لوضع كل شيء.

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

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

Answer 6

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

.