ما هي عملية بناء CI الجيدة

https://stackoverflow.com/questions/102902

01-07-2019
|

سؤال

ما الذي يشكل عملية بناء CI جيدة؟

نحن نستخدم CI، ولكن يعتبر النشر إلى الإنتاج هدفًا واقعيًا لـ CI عندما يكون لديك تبعيات على العديد من الخدمات التي يجب نشرها أيضًا وقد تعتمد التطبيقات الأخرى عليها أيضًا.

هل تعتبر عملية بناء CI الجيدة جيدة بدرجة كافية عندما تكون آلية لضمان الجودة ودليلًا من هناك؟

المحلول

حسنا "يعتمد" :)

نحن نستخدم نظام CI الخاص بنا من أجل:

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

هذا لمشروع جديد يضم حوالي اثنتي عشرة خدمة وقواعد بيانات تم نشرها على أكثر من 20 خادمًا، والتي كانت لها أيضًا تبعيات على ستة خدمات "خارجية" أخرى.

هل تستخدم أداة CI لنشر منتجك في بيئة إنتاج كهدف واقعي؟مرة أخرى..."هذا يعتمد"

لماذا تريد أن تفعل هذا؟

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

بعض الأمور التقنية التي يجب عليك معالجتها قبل أن تتمكن من الإجابة على هذا السؤال:

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

فيما يلي بعض الروابط الحديثة ذات الصلة حول أتمتة و بناء الأدوات التي تحتاجها.

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

والآن إليك السر الكبير..التحديات التقنية صعبة ولكنها ليست مستحيلة.ال سياسي قد تكون التحديات لا يمكن التغلب عليها.كل شيء يتعلق بهذا يكلف أموالاً سواء كان وقت التطوير أو شراء حلول الطرف الثالث.هل يمكنك حقًا إنشاء حل بقيمة ألف دولار أو 10 آلاف دولار أو 100 ألف دولار أو مليون دولار؟

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

نصائح أخرى

ليس المقصود من CI أن تكون آلية نشر.هو - هي يكون من الجيد أن تقوم CI الخاصة بك بتنفيذ أي نشر تلقائي إلى خادم ضمان الجودة/الاختبار، لضمان تلك الجوانب من أعمال البناء الخاصة بك، لكنني لن أستخدم نظام CI مثل نظام تثبيت السرعة أو Bamboo كوسيلة للنشر.

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

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

ولتحقيق هذه الغاية، فإن التكنولوجيا المستخدمة في عملية بناء الخادم الفعلية ليست ذات صلة إلى حد كبير مقارنة بما يحدث بالفعل أثناء الإنشاء.كما ذكرpdavis، يجب أن يقوم بناء CI بتجميع قاعدة التعليمات البرمجية، وتنفيذ بعض تحليلات التعليمات البرمجية (FxCop، StyleCop، Lint، وما إلى ذلك)، وتنفيذ اختبارات الوحدة وتغطية التعليمات البرمجية، وتنفيذ أي تحليل مخصص آخر تريد إجراؤه والذي يجب أن يؤثر على المفهوم بناء "ناجح" أو "فاشل".

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

لقد بدأت في مشروع جديد في العمل وأتطلع إليه حقًا.ما زلنا في مرحلة التصميم الأولية وقد أكملنا مؤخرًا بنية النظام المنطقي.لقد طلبنا خوادم جديدة لبيئات الاختبار والتدريج ونقوم بإعداد نظام بناء للتكامل المستمر (CI) يعتمد على نظام تثبيت السرعة (http://cruisecontrol.sourceforge.net/) وMSBuild (http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx) وهو في الأساس منفذ محسّن لـ ANT.يبدو أن ملفات المشروع والحلول Visual Studio 2005 كلها الآن بتنسيق MSBuild.سيقوم نظام التحكم في السرعة بسحب المصدر تلقائيًا من Visual Source Safe (حسنًا، إنه ليس تخريبًا ولكن يمكننا التعامل معه)، وتجميعه، ثم تشغيله من خلال fxCop (http://www.gotdotnet.com/Team/FxCop/) ، نوحدة (http://www.nunit.org/)، ن الغلاف (http://ncover.org/site/)، وأخيرًا وليس تأجير سيميان (http://www.redhillconsulting.com.au/products/simian/).يحتوي نظام تثبيت السرعة على واجهة موقع ويب جيدة جدًا لعرض جميع النتائج المجمعة من الأدوات المختلفة ويمكنه أيضًا عرض تغييرات التعليمات البرمجية من إصدار إلى آخر.كما أنه يتتبع جميع البنيات في سجل البناء.إنني أتطلع إلى التطوير القائم على الاختبار وأعتقد أن هذا النوع من النهج جنبًا إلى جنب مع nUnit/nCover يجب أن يمنحنا فكرة جيدة جدًا قبل أن نطرح التغييرات التي لم نكسر أي شيء.هناك أيضًا خطط لدمج نوع من اختبار واجهة المستخدم الآلي بمجرد أن نكون قد قطعنا مسافة كافية في المشروع.اعتمادًا على الأداة، يجب أن يكون هذا مجرد مسألة تثبيت الأداة على خادم البناء واستدعائها من نظام تثبيت السرعة.حلو.

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

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

كنت أشاهد عرضًا تقديميًا لـ ThoughtWorks (منشئو نظام تثبيت السرعة) وقد تناولوا هذه المشكلة بالفعل.إجابتهم هي أن عملية النشر NO معقدة للغاية بحيث لا يمكن اختبارها.لماذا؟لأنه بخلاف ذلك، يصبح عملاؤك مختبرين لك، وهو بالضبط المكان الذي لا تريد أن تكون فيه.

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

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

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

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

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

هل تعتبر عملية بناء CI الجيدة جيدة بدرجة كافية عندما تكون آلية لضمان الجودة ودليلًا من هناك؟

أعتقد أن هذا النشر "اليدوي" يُستخدم عندما يخشى الشخص الذي لديه دور مهندس النشر من احتمال حدوث خطأ ما بعد النشر.ليس لديه ثقة في موثوقية أدوات النشر واستقرارها.

يمكن أن يختفي هذا العمل الفذ من خلال اختبار عملية النشر الآلي على بيئة تشبه المنتج. ويجب أيضًا اختبار آلية التراجع بعد النشر.

عندما يتم اختبار هذه الوظائف بشكل كافٍ، ستكتسب الثقة في هذه العملية والأداة التي تستخدمها.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow