يجب أن يركز الفريق على إنشاء ألعاب جميلة وناجحة ، لأن كل شيء آخر هو CI.
أين نطبق CI؟ ما هي النهج والمفاهيم التي نستخدمها؟ لماذا بناء واختبار يبني؟ القصة التفصيلية حول CI وكيف يتم تنظيمها في Playrix سوف ترسم دورة من المحاضرات. تحت خفض - الضغط وجيزة وعدد قليل من لهجات.
مرحبا.
أولا ، الاحماء قليلا: ما هو التكامل المستمر؟ إذا كان الفريق يستخدم المستودع ويجمع تصميمات ليلية - فهل هذا CI بالفعل؟ ما هو الفرق بين النشر المستمر والتسليم؟ إنه غير مهم تقريبًا. تفاصيل - لدائرة ضيقة من المتخصصين. إذا كنت ترغب في إشراك الشركة بأكملها في عملية ما ، فابحث عن اسم بسيط وجيد لها. في Playrix ، ندعو جميع هذه الأساليب CI. هذه علامة تجارية محلية وشعار رائع:
فكرة
CI ليس هدفا ، بل هو أداة. يجب أن يكون هناك هدف تريد تحقيقه من خلال التكامل المستمر ، وهي مشكلة تحتاج إلى حل. يحدث أن عمليات التطوير والإطلاق في فريق مبنية على مبدأ "الصلاة والإنتاج". في بعض الأحيان يكون له ما يبرره ، ولكن بشكل غير منتظم.
قمنا بصياغة هدفنا على النحو التالي: تقليل احتمالية حدوث مشاكل تكامل إلى الحد الأدنى ، وتقليل الموارد اللازمة لتصحيح الأخطاء الموجودة ، وتقليل وقت فرق تطوير المشاريع لدعم ودعم عمليات CI.
CI هي أتمتة عمليات الإنشاء ، واختبار الكود وتقديمه إلى بيئات مختلفة ، وأتمتة عمليات التطوير الروتينية ، والتكامل المتبادل للخدمات التي نستخدمها جميعًا.
تكمن الفكرة في نظام يقوم تلقائيًا بجمع كل شيء تلقائيًا ، ويقوم بذلك في كثير من الأحيان ، ويقوم باختبار بناء وتقديمه ، كما يستهدف أيضًا الإبلاغ عن تقرير مناسب إذا حدث خطأ ما.
أين نطبق CI؟
- المحرك والمرافق ،
- ألعابنا لجميع المنصات ،
- كود الخادم
- التحليلات ، خدمات التسويق ، الأتمتة المختلفة ، خدمات CI ،
- البنية التحتية.
هذا هو في كل مكان أو في كل مكان تقريبا.
قم بتجميع الحاويات واختبارها وعمليات النشر التلقائية في تحديثات الاختبار والتدريج وبرود والمتداول والكناري - كل هذا لدينا وأكثر قابلية للتطبيق على الخدمات وتطبيقات الويب. اليوم سوف نركز على CI للألعاب: بناء البنى واختبارها وتسليمها.
نماذج
لتحقيق الأهداف المذكورة أعلاه ، تحتاج إلى حل العديد من المشاكل. في ما يلي خطة نتبعها عندما نقوم بأتمتة بعض العمليات في التطوير ، على سبيل المثال ، تجميع عميل لعبة محمولة. من المريح للغاية الحصول على قائمة من الأسئلة والإجابة عليها ، والتي يمكنك حل أي مشكلة تقع في فريق CI.
بناء تعليمات التجميع هي الوثائق ، وصفا للعملية الآلية لدينا. غالبًا ما تكون هذه الوثائق في رأس المبرمجين. إذا كان لدى الفريق أخصائي فائق في بناء المباني وبدون ذلك ، فلن يتمكن أحد من بناء مبنى سريع وخالي من الأخطاء - لقد حان الوقت لتغيير شيء ما ، فلن يكون هناك إرسال.
حسنًا ، إذا تم تأطير مثل هذه الوثائق في شكل برنامج نصي: لقد أدخلت سطر أوامر ومجموعة من المعلمات على جهاز به بيئة معدة - حصلت على بنية.
أفضل وثائق العملية هي كود
القط . حتى لو كنت بحاجة لسبب ما لتكرار العملية يدويًا ، يمكنك دائمًا القيام بذلك من خلال النظر فيها.
يسمح لك سجل البنية دائمًا بالتأكد بالتأكيد من: من ، ومتى ، ومن الذي ارتكب ، ومع أي نتيجة تم جمع هذا البناء أو ذاك. بالأمس ، كانت البنية على وشك ، ولكن اليوم لم تكن كذلك. ننظر في السجل ، ونجد أول بنية مرنة ، ونرى قائمة الالتزامات التي حصلت هناك - الربح.
المجلة أكثر فائدة عندما يتعلق الأمر ، على سبيل المثال ، برمز الخادم. إذا لم تكن هناك معلومات حول من قام بتحديث prod ومتى ، فعندئذٍ في الحالة العامة ، لا يُعرف الرمز الذي يعمل حاليًا هناك. وأحيانًا يكون ذلك مهمًا جدًا.
يمكنك الاحتفاظ بهذه المجلة في دفتر الأستاذ ، ويفضل أن يكون ذلك في جدول أو ويكي. قائمة البنيات في نظام CI لا تقدر بثمن.
عندما يتعلق الأمر ببناء مبنى ونشره على نوع من البيئة ، فإن السؤال الذي يطرح نفسه دائمًا هو: أين يمكنك تخزين كلمات مرور تسجيل الدخول / الوصول؟ عادة ما يحتاجون إلى الكثير: إلى المستودع لتنزيل البيانات المصدر ، إلى تخزين الملفات لملء موارد اللعبة ، إلى HockeyApp لإرسال الأحرف ، إلى الخادم لتحديث الرمز ، إلخ.
يحدث أن يتم تخزين كافة عمليات الوصول الضرورية في المستودع. هناك فرضية أن هذه ليست جيدة جدا. غالبًا ما يمكنك رؤية حقل "إدخال كلمة المرور" ، على سبيل المثال ، في جنكينز ، حيث يدخل مؤلف البناء إلى الأحرف المخفية.
تذكر كل كلمات المرور عن ظهر قلب هو مهارة جيدة. يتلقى خادم CI الخاص بنا نفسه عمليات الوصول الضرورية وفقًا للتجميع. عادةً ما تكون هذه الرموز المميزة قصيرة العمر التي يتم إنشاؤها في بداية الإنشاء وتعطي الحد الأدنى من الحقوق بالضبط حيث ننشر شيئًا ما أو حيث نقرأ شيئًا منه.
تتيح لك الإدارة المركزية للتجميع والنشر حل مشكلة التمييز بين حقوق الوصول للبنية التحتية. لماذا منح شخص ما حق الوصول إلى الخادم إذا كان يمكنك فقط منح حق الوصول إلى تجميع البنية المقابلة التي تقوم بالعملية الضرورية على هذا الخادم؟ وبما أن هناك بناءًا ، فنحن لدينا وثائق وتوثيق ، حسناً ، أنت تفهم ذلك.
غالبًا ما يتبقى الكثير من الآثار أثناء وقت البناء. لا ، ليس هكذا: أثناء الإنشاء ، من الضروري ترك أكبر عدد ممكن من الآثار. في المستودع ، في تعقب المهام ، في نظام توزيع البناء. في كل مكان ، أينما كنت تقابل بناءً ، يجب أن تكون هناك آثار تقودك إلى إكمال المعلومات المتعلقة به.
لا يجب إزالة هذه الآثار ، بل على العكس ، يجب تركها بعناية وحفظها بعناية. علاوة على ذلك ، سوف أخبركم المزيد حول هذا الموضوع ، لكن أولاً نحتاج إلى جمع بياناتنا. دعنا نذهب.
قبل الالتزام السنانير
مرة أخرى ، الفكرة هي نظام يجمع ويختبر ويبلغ عن كل شيء. ولكن لماذا بناء بناء إذا كنت لا تستطيع بناء عليه؟
جميع مطوري ألعابنا لديهم تثبيتات مسبقة للتثبيت ، أي مجموعة من الاختبارات التي يتم تنفيذها عند محاولة ارتكاب شيء ما. يتم تشغيل الاختبارات فقط للملفات التي تم تعديلها ، لكننا قمنا بتطبيق نظام بحث التبعية التبادلية للغاية للتحقق من جميع المحتويات ذات الصلة أيضًا. أي إذا أضاف الفنان مادة ، فسوف يتحقق السنانير من أنهم لم ينسوا تسجيلها حيثما دعت الحاجة ، ولم يختموها.
اتضح أن السنانير تلتقط جزءًا كبيرًا من الأخطاء الصغيرة. إنها توفر موارد نظام الإنشاء وتساعد المطور على حل المشكلة بسرعة: يرى رسالة توضح بالتفصيل ما حدث من خطأ. وهو لا يحتاج إلى التبديل بين المهام: لقد قام حرفيًا بإجراء تغييرات وهو في السياق الصحيح. خطأ تصحيح الوقت هو الحد الأدنى.
لقد أحببنا ذلك كثيرًا لدرجة أننا صنعنا حتى نظامًا يتحقق مما إذا كانت الخطافات قد صنعت لالتزام دخل في المستودع. إذا لم يكن الأمر كذلك ، سيتلقى مؤلف هذا الالتزام تلقائيًا مهمة يطلب منهم تكوينها وتعليمات مفصلة حول كيفية القيام بذلك.
السنانير موحدة لجميع المشاريع. عدد الاختبارات المخصصة هو الحد الأدنى. هناك تخصيص مناسب ، بما في ذلك اعتمادًا على المستخدم الذي يعمل: هذا مناسب جدًا لاختبارات الاختبار.
بناء
لمعرفة المشكلة في الإنشاء في أقرب وقت ممكن ، تحتاج إلى جمع هذه الإنشاءات واختبارها قدر الإمكان. يجتمع عملاء ألعابنا لجميع المنصات ، لكل التزام ، لجميع المشاريع. ربما هناك بعض الاستثناءات ، ولكن ليس الكثير.
عادةً ما يكون لدى العميل ، وخاصة العميل المتنقل ، العديد من الإصدارات المختلفة: مع أو بدون خداع ، توقيع مختلف ، إلخ. لكل التزام ، نقوم بتجميع تصميمات "منتظمة" ، والتي يستخدمها المطورين والمختبرين باستمرار.
هناك تصميمات تُستخدم نادرًا جدًا ، على سبيل المثال ، متجر ios build - مرة واحدة فقط في التقديم ، أي حوالي مرة واحدة في الشهر. ومع ذلك ، نعتقد أن جميع البنيات ينبغي جمعها بانتظام. في حالة حدوث مشكلة في هذا النوع من التجميع ، على الجانب المتعلق بالتطوير أو البنية التحتية ، سيعرف فريق المشروع عن ذلك ليس في يوم تسليم الإنشاء ، ولكن في وقت أبكر بكثير ، وسيكون قادرًا على الاستجابة للمشكلة وحلها مقدمًا.
نتيجة لذلك ، لدينا قاعدة بسيطة: يتم إطلاق أي بنية مرة واحدة على الأقل يوميًا. يكتشف فريق تطوير المشروع وجود أي مشاكل على أي منصة في أسوأ الحالات في صباح اليوم التالي بعد ظهور هذه المشكلة في المستودع.
يتطلب مثل هذا التردد من التجميعات والاختبارات اتباع نهج خاص لتحسين وقت التنفيذ.
- جميع يبني العملاء العادية هي تدريجية.
- أطالس التعبئة وإعداد الموارد هي أيضا تدريجي.
- التجميعات محببة: بعض الخطوات في تكوينات بناء منفصلة - وهذا يسمح لك بتنفيذها بشكل متواز ، وكذلك إعادة استخدام النتائج الوسيطة.
هذه لقطة كاملة تقريبًا لسلسلة التصميمات والاختبارات الخاصة بـ WildScapes. لا يمكن القيام بالكامل: فهو أكبر من ضعف الحجم.
اختبارات ثابتة
بعد التجميع ، يتم إجراء اختبار ثابت: نأخذ المجلد بالبناء ونجري مجموعة من الاختبارات لكل المحتوى الموجود. الرمز هو أيضًا محتوى ، لذلك التحليل الثابت (cppcheck + PVS-Studio) موجود أيضًا هنا.
على habr
كان هناك
مادة مفصلة حول كيفية تنفيذ اختبارات ثابتة ، أوصي به. أؤكد فقط أن الاختبارات الثابتة بعد الإنشاء وفي خطافات الالتزام المسبق يتم تنفيذها بنفس الكود. هذا يبسط إلى حد كبير دعم النظام.
اختبارات وقت التشغيل
إذا نجحت الاختبارات الثابتة ، يمكنك المضي قدمًا ومحاولة تشغيل الإنشاء المجمع. نحن نختبر الإنشاءات على جميع الأنظمة الأساسية باستثناء UWP ، أي Windows ، MacOs ، iOS ، Android. UWP - سيكون أيضا ، ولكن في وقت لاحق قليلا.
لماذا اختبار بنيات سطح المكتب إذا كانت تبدو ضرورية فقط في التطوير؟ الجواب على السؤال هو: من السيء أن يحصل فنان أو مصمم بمستوى على تصميم يتعطل عند بدء التشغيل لسبب مثير للسخرية. لذلك ، يتم إجراء اختبار Smoke-Test ، وهو الحد الأدنى لمجموعة من اختبارات القابلية للتشغيل واللعب الأساسي ، على كافة الأنظمة الأساسية.
كل ما تمت كتابته أعلاه عن عمليات الإنشاء ينطبق أيضًا على الاختبارات على الأجهزة - مرة واحدة على الأقل يوميًا. مع بعض الاستثناءات القليلة: هناك اختبارات طويلة للغاية لا يوجد لديها وقت لإكمالها في يوم واحد.
يتم تنفيذ اختبارات الدخان لكل التزام. يعد إكمال الاختبارات الأساسية بنجاح شرطًا أساسيًا للدخول في نظام التوزيع. عادة ما يكون من غير المنطقي منح شخص ما حق الوصول إلى بنية لا تعمل بشكل واضح. هنا يمكنك الاعتراض والتوصل إلى استثناءات. تحتوي المشاريع على حل بديل لإتاحة الوصول إلى بنية غير عاملة ، لكنها بالكاد تستخدمها.
ما هي الاختبارات الأخرى هناك:
- المعيار: نتحقق من الأداء على FPS والذاكرة في المواقف المختلفة وعلى جميع الأجهزة.
- اختبارات وحدة المطابقة 3: يتم اختبار كل عنصر وكل ميكانيكي على حدة وفي جميع مجموعات التفاعل.
- مرور اللعبة بأكملها من البداية إلى النهاية.
- اختبارات الانحدار المختلفة ، على سبيل المثال ، اختبارات التعريب ، أو فتح جميع نوافذ واجهة المستخدم بشكل صحيح ، أو تشغيل مشاهد fishdom في Fishdom دون أخطاء.
- كل نفس ، ولكن مع AddressSanitizer .
- اختبارات التوافق لإصدارات الألعاب: خذ المستخدم بحفظ الملف من الإصدارات السابقة ، وافتحه في الإصدار الجديد وتأكد من أن كل شيء على ما يرام.
- اختبارات مخصصة مختلفة تتعلق ميكانيكي مشروع معين.
لتشغيل الاختبارات ، نستخدم منصة الاختبار الخاصة بنا التي تعمل بنظام ios وأجهزة Android. هذا يتيح لنا تشغيل التطبيقات التي نحتاجها بمرونة على الأجهزة ، والتفاعل مع الجهاز من خلال الكود. لدينا سيطرة كاملة ، ومستوى موثوق من الموثوقية ، ونعرف ما هي المشاكل التي قد نواجهها والوقت الذي سوف يستغرقه حلها. لا تقدم أي من الخدمات السحابية التي توفر أجهزة الاختبار هذه الراحة.
CATS
يتم تنفيذ الاختبارات المذكورة أعلاه داخل رمز المشروع. يسمح هذا نظريًا بإجراء أي اختبار لأي تعقيد ، ولكنه يتطلب جهدًا وموارد من تطوير المشروع لتنفيذ هذه الاختبارات ودعمها. غالبًا ما تكون هذه الموارد غير متوفرة ، ويعد اختبار الانحدار المتعدد يدويًا صعبًا وغير ضروري. أردت حقًا أن يقوم المختبرون أنفسهم بأتمتة الاختبار. وقد توصلنا إلى إطار عمل خاص بهم - نظام اختبار أتمتة مستمر ، أو CATS.
ما هي الفكرة: لتمكين مؤلفي البرامج النصية للاختبار من التفاعل مع تطبيق الألعاب ، ولا يهتمون مطلقًا بكيفية عمل كل شيء. نكتب البرامج النصية في بيثون البدائية ، ونحن الوصول إلى التطبيق من خلال مجموعة من التجريدات. على سبيل المثال: "Homescapes ، افتح لي نافذة تسوق واشتري مثل هذا المنتج وكذا". تحقق النتيجة ، البنغو.
يتم إخفاء تنفيذ أوامر البرنامج النصي بالكامل وراء مجموعة من التجريدات. تتيح لك واجهة برمجة التطبيقات التي تنفذ التفاعل مع التطبيق القيام بأي إجراء بعدة طرق:
- إرسال طلب http إلى الخادم ، والذي تم تضمينه في محرك اللعبة ، مع وجود نوع من الأوامر. تتم معالجة هذا الأمر بواسطة رمز اللعبة. عادة ما يكون هذا نوعًا من الغش ، فقد يكون بسيطًا أو معقدًا بشكل تعسفي. على سبيل المثال ، "أعطني إحداثيات مركز الزر مع المعرف المحدد." أو "اجتياز اللعبة من هنا إلى المستوى مع الرقم المشار إليه."
- يمكننا فتح نافذة من خلال الغش أو معرفة إحداثيات الزر الذي تفتح من خلاله هذه النافذة ، يمكننا محاكاة النقر على هذا الزر ، يمكننا إجراء نقرة افتراضية عليه.
- أخيرًا ، يمكننا إجراء نقرة "حقيقية" على الإحداثيات المحددة كما لو كانت قد تمت بإصبع على الشاشة.
الطريقة الأخيرة تفتح المجال لخيال المختبرين الذين يرغبون غالبًا في اختبار بنيات "قتالية" ، حيث لا توجد غش. الحفاظ على مثل هذه السيناريوهات أكثر صعوبة ، ولكن "الإنشاء القتالي" هو بناء "قتالي".
اتضح أنه مناسب جدًا للعمل مع إحداثيات مركز الزر: تتغير الإحداثيات أحيانًا ، لكن معرفات الأزرار نادرة. أدى ذلك إلى خاصية مهمة أخرى للنظام: القدرة على كتابة نص اختبار واحد لجميع المنصات وجميع دقة الشاشة.
التسليم والتقارير والآثار
مع التسليم ، تبين أن كل شيء بسيط للغاية: نستخدم تخزينًا مشتركًا واحدًا لتصنيع القطع الأثرية والتخزين في نظام التوزيع. يأتي "التحميل" الخاص بالبناء لاستدعاء زوج من الطلبات إلى واجهة برمجة التطبيقات لتوزيع البناء ، ويتم تسجيله بشكل أساسي. وبهذه الطريقة ، وفرنا القليل من الوقت في ضخ بنيات والمال لتخزينها.
تذكر ، هل تحدثت عن تقليل الموارد اللازمة لإصلاح الأخطاء الموجودة في البنيات؟ التقارير والمسارات - فقط عن هذا:
- الإبلاغ عن مشكلة موجودة هي مهمة في Asana. من السهل التحكم فيه ، وتخصيصه للمطور المناسب ، ونقله إلى فريق CI إذا حدث خطأ ما في البنية التحتية.
- نجمع يبني لكل التزام. نحن نعرف مؤلف هذا الالتزام ، لذلك فقط هو سيرى هذه المهمة. لذا فنحن نوفر الوقت للمطورين الآخرين: لا يحتاجون إلى أن يصرف انتباههم المشكلات التي لا علاقة لهم بها ويساعدون في حلها ، على الأرجح ، لن يكونوا قادرين على ذلك.
- إذا كنت تبني بنية من الالتزام التالي ، فمن المرجح أنها لا تزال مقطوعة. سيكون هناك تعليق في المهمة: "البنية لا تزال مقطوعة" ، ولن يرى مؤلف الالتزام الجديد المهمة ولن يضيع الوقت في مشكلة شخص آخر.
- نرسل التقارير إلى سلاك. بالضرورة - شخصيًا للشخص الذي "كسر" البنية ، وإذا كان المشروع يريد ذلك - لقناة خاصة أو لأي موظف في Playrix. كل شيء مرن قدر الإمكان.
هناك حاجة إلى تتبعات حتى تتوفر في كل مكان معلومات كاملة عن البنية والتغييرات التي تم جمعها منها. من أجل عدم البحث عن أي شيء ، بحيث كان كل شيء في متناول اليد وليس هناك حاجة لقضاء بعض الوقت في البحث عن التفاصيل التي غالبا ما تكون ضرورية عند البحث عن مشكلة.
- يحتوي التقرير على ارتباط إلى الإنشاء ، وسجل الإنشاء ، ونص خطأ التحويل البرمجي الموجود ، وأسماء الاختبارات المقلوبة. غالبًا ما يمكن للمبرمج ، بعد تلقي مهمة تقرير ، تصحيح الخطأ على الفور: اسم الملف والخط ونص الخطأ موجودان في التقرير.
- تحتوي الرسالة الموجودة في Slack على رابط + للمهمة في Asana.
- في Teamcity ، رابط للمهمة. بناء المهندس يمكن أن تذهب على الفور في المهمة ، في نقرة واحدة ، لا تحتاج للبحث عن أي شيء.
- في github - الحالة مع رابط للبناء ، في التعليق على الالتزام - رابط للمهمة التي تم إنشاء هذا البناء لها. في المهمة - تعليق مع وصلة إلى الالتزام.
- في خدمة توزيع البناء: رابط البناء ، رابط الالتزام.
لا يوجد شيء يمكن تذكره ، لكنك فهمت الفكرة: روابط إلى كل شيء ، في كل مكان. هذا يسرع إلى حد كبير دراسة أي موقف غير مفهوم.
FARM
نقوم بجمع واختبار البنيات لجميع المنصات. لهذا نحن بحاجة إلى الكثير من العوامل المختلفة. تتبعها وصيانتها يدويًا طويل وصعب. يتم تحضير جميع الوكلاء تلقائيًا. نستخدم باكر و Ansible.
جميع سجلات جميع الوكلاء ، Teamcity ، جميع الخدمات الموجودة ، نوفر (في حالتنا - في ELK). تضيف جميع الخدمات ، التي تقوم بمعالجة بناء ، عدد هذه البنية إلى كل سطر من السجلات. يمكننا أن نرى في طلب واحد دورة حياة المبنى بأكملها من مظهرها في قائمة الانتظار إلى نهاية إرسال جميع التقارير.
قمنا بتطبيق آلية تحسين قائمة الانتظار الخاصة بنا. واحد في Teamcity لا يعمل بشكل جيد للغاية على أعدادنا. الحديث عن الأرقام:
- نحن نجمع حوالي 5000 يبني كل يوم. هذا حوالي 500 ساعة من العمل.
- وكان بناء ثلاثة ملايين قبل شهر.
- لدينا 50+ خوادم بناء في 10 مواقع مختلفة.
- 40+ الأجهزة المحمولة على مقاعد البدلاء اختبار.
- بالضبط 1 خادم Teamcity.
CI كخدمة
Playrix CI هي خدمة. هناك العديد من المشاريع ، العديد من الأفكار أيضا.
نعمل على تحسين الوقت من إدخال الإنشاء في قائمة الانتظار حتى نهاية تنفيذه ، لأن هذا هو بالضبط "وقت البناء" الذي يعتبره مستخدم الخدمة ، المطور. يسمح لنا ذلك بالبحث والعثور على توازن بين وقت البناء والوقت الذي يقضيه في قائمة الانتظار. يبدو من المنطقي أنه مع نمو الشركة وعدد المشاريع ، ستنمو مزرعة البناء التي تجمع هذه المشاريع. ولكن بفضل التحسينات ، فإن معدل نمو المزرعة هو أبعد بكثير عن معدل نمو الشركة.
يبدأ أي تحسين بمراقبة ، مع مجموعة منهجية من الإحصاءات. نحن نجمع الكثير من الإحصاءات ونعرف تمامًا كل شيء عن تصميماتنا. ولكن إلى جانب حجم مزرعة الإنشاءات ، هناك أيضًا فريق يدعم نظام CI ويجعله لا يحتاج أي شخص إلى التفكير في مصدره.
يعد تحسين العملية في هذا الفريق أيضًا عملية مثيرة ومسلية.
على سبيل المثال ، نكتب اختبارات لتعيين تكوينات للبنيات ، لأن هناك العديد من هذه التكوينات ، وبدون اختبارات مماثلة ، ليس من السهل العثور على جميع الأماكن التي تحتاج إلى تحرير. بالنسبة لأي تغييرات تقريبًا ، نكتب أولاً اختبارًا ، ثم نجريها ، أي في الواقع ، لدينا TDD. هناك العديد من العمليات المتعلقة بالواجب ، وإدارة الحوادث ، وجدولة تدفق المهام القادمة.يجب أن يركز المطورون على إنشاء ألعاب رائعة وناجحة دون الحاجة إلى القلق بشأن مصدرها. لهذا ، Playrix لديه CI. يجب أن يكون هناك هدف تريد تحقيقه من خلال التكامل المستمر ، وهي مشكلة تحتاج إلى حل. من المهم عدم الخروج بمشكلة ، أي العثور عليها. وعندما تجدها ، تذكر تجربتنا وقم بعمل أفضل. وتذكر:CI لا تنام أبداأراك!