كيف صنعنا المحرك واللعبة عليه لمدة عام ونصف. الجزء الثاني البنية التحتية

أولاً ، بعض التعليقات على آثار المقال السابق. لقد اعتدنا حقًا العمل في Wargaming ، حيث طورنا محركًا يعرف باسم dava.framework أو dava.engine . لذلك ، يشارك العديد من الزملاء القدامى ، الذين لا نزال معهم في علاقات جيدة ، مشاركة نشطة في المناقشة.

هناك عدد من الناس لديهم شكوك: هل هذه هي التكنولوجيا نفسها أم لا؟ الإجابة: هذه تقنية جديدة مكتوبة من البداية.

كيف نجحنا في عام واحد فقط؟ فريقنا لديه خبرة واسعة. قام العديد منهم بتطوير محركات وألعاب لأكثر من 15 عامًا.

لماذا من الصفر ، إذا كنت تستطيع أن تأخذ محركنا القديم ، والذي يقع أيضًا في المصدر المفتوح؟ يبلغ من العمر حوالي 10 سنوات ، ومعظم الشفرة قديم. حتى أفضل أجزاء المحرك ، التي نفخر بها ، تحتوي أحيانًا على أجزاء من التعليمات البرمجية وبعض الأساسيات من 5 و 7 وأحيانًا حتى قبل 10 سنوات. تم تصميم العديد من الحلول المعمارية للأجهزة في ذلك الوقت - بدءًا من 3G iPhone. نركز الآن على iPad Air 1 وما شابه ذلك في أجهزة Android العاملة بالطاقة. تبعا لذلك ، تغيرت النهج إلى حد ما.

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

والآن إلى هذه النقطة: ما هي الأدوات والتقنيات التي ساعدتنا في إنجاز هذه المهمة الطموحة إلى حد ما في وقت قصير؟

البنية التحتية

لقد اخترنا Atlassian Bitbucket Server + جنكينز. يوجد في Bitbucket المستودع الرئيسي (الرئيسي) ، والذي يرتبط به جينكينز. كل مطور لديه شوكة خاصة به. لكل مهمة ، يتم إنشاء شوكة جديدة في الشوكة ، والتي يتم دمجها مرة أخرى من خلال طلب السحب. بشكل عام ، فإن المخطط هو المعيار جميلة. كل pullrequest يخضع لمراجعة إلزامية واختبارات تلقائية. وإذا نجحت ، يتم دمجها تلقائيًا في برنامج الماجستير.

جنكينز

لدى جينكينز العديد من أوجه القصور: فهو كمامة قديمة ، وليست سريعة للغاية ، وشراهة ، تبدو وكأنها بوابة إنترنت من التسعينيات. ومع ذلك ، فإن مرونتها وعدد كبير من الوحدات وخالية من الرسوم تجعلها خيارًا جيدًا حتى في عام 2019. بعد أن لعبت مع الوحدات والإعدادات ، يمكنك تحقيق مظهر سهل الهضم ، ووصف تعريفي لخطوط الأنابيب (الموجودة في المستودع). بالمناسبة ، يوجد الآن حوالي 40 خط أنابيب: الاختبارات ، المحررين ، لعبة لجميع المنصات ؛ العمل مع البنية التحتية للخادم و metagame. جمع كل شيء 20 buildagentov.

في المستقبل ، بالطبع ، أريد تجربة حلول محب حديثة ، على سبيل المثال GitLab أو TravisCI ذاتية الاستضافة. لا نعتبر الحلول السحابية بالكامل (Nevercode ، Bitrise ، CircleCI ، إلخ) بسبب الحجم الكبير لمستودعنا ، والأصول ، وبناءً على وقت بناء القطع الأثرية وحجمها.

بناء النظام

كان الشرط الرئيسي للنظام كما يلي: إنشاء مشروع لنظام التشغيل iOS و MacOS و Android و Windows و Linux بخط واحد. تمكنا من تجربة Premake ، SCons ، Bazel و CMake. لأسباب مختلفة ، توقفنا في CMake اختبارها من الزمن.

في السنوات الأخيرة ، أصبح CMake المعيار تقريبًا للمكتبات C ++. يمكن توصيل كل شيء تقريبًا بدءًا من Abseil إلى SDL بمشروع CMake الخاص بك في بضعة أسطر. هناك بالطبع استثناءات ، مثل OpenSSL أو V8 ، والتي كان علي أن أعرقها قليلاً. على رأس Zmeik عارية قمنا بتطوير إطار صغير (حوالي 3000 خطوط في المجموع). الميزات الرئيسية:
نمطية. تم تصميم الأجزاء الفردية للمحرك كوحدات. على سبيل المثال ، الصوت ، واجهة المستخدم ، الفيزياء ، الشبكة ، إلخ. يمكن أن يكون لكل وحدة أصولها الخاصة (على سبيل المثال ، تظليل) وقد يكون لها تبعيات على وحدات أخرى.

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

عملية التنمية

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

في المتوسط ​​، نضيف أكثر من 20 طلب سحب يوميًا. هذا يعني أنه من المحتمل أن يتم كسر السيد 20 مرة في اليوم. لحسن الحظ ، في عام 1991 ، توصلوا إلى تقنية التكامل المستمر. ماذا وصلنا؟

التكامل المستمر

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

1. اختبارات وحدة لجميع المنصات (ويندوز ، لينكس ، ماكوس ، دائرة الرقابة الداخلية ، الروبوت). يتم استخدام Googletest كأساس ، ويتم استخدام OpenCppCoverage ، والذي يتم التحقق من تقريره بواسطة برنامج نصي بيثون إضافي ، للتحقق من نسبة التغطية. إذا كانت نسبة التغطية لملف معين أقل من 75 ٪ ، يعتبر الاختبار فاشلاً. وبالتالي ، قمنا بتغطية معظم فئات المحركات ذات المستوى المنخفض مع الاختبارات.
2. Codeformatter. لرمز C ++ نستخدم صيغة clang. يحدث تنسيق الكود الذي تم تغييره أولاً تلقائيًا عند الالتزام بجهاز المطور ، ثم يتم فحصه في الاختبار. لجافا سكريبت ، والذي يستخدم كلغة برمجة ، يتم استخدام npm linter.
3. اختبارات الأصول. مجموعة كبيرة إلى حد ما من الاختبارات: من التحقق من صحة تنسيقات الملفات إلى التحقق من التبعيات (على سبيل المثال ، التحقق من وجود النسيج المستخدم في مستوى اللعبة).
4. وحدة واختبارات وظيفية للمحرر. يعد المحرر جزءًا لا يتجزأ من المحرك ، حيث يتم إنشاء وتحرير مستويات اللعبة والأصول الأخرى. بالإضافة إلى اختبارات الوحدة ، يتم استخدام froglogic Squish لـ Qt ، وهي أداة مساعدة لاختبار واجهة المستخدم الرسومية التلقائي ، لاختبار المحرر. كل هذا يسمح لنا بالاستغناء عن الاختبار اليدوي للمحرر. علاوة على ذلك ، وفقًا لاستعراضات الفنانين ومصممي المستوى ، فإن مستوى جودته واستقراره أعلى منه في الشركة السابقة ، عندما كان لدينا فريق مكون من خمسة اختبارين. في الوقت نفسه ، تحدث الإصدارات يوميًا ، ومع الاختبارات اليدوية ، تحدث الإصدارات كل أسبوعين.
5. الاختبارات الوظيفية للعبة. من الواضح أنني أريد استخدام اختبارات وظيفية تلقائية للعبة. لذلك ، بدأنا تطوير النظام التالي:

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

يتم جمع معظم المشاريع للاختبارات مع تشغيل علامة "تعامل التحذيرات مع وجود أخطاء" ، وعلى نظام MacOS مع تشغيل clang AddressSanitizer بالإضافة إلى ذلك ، مما يتيح لك اكتشاف المزيد من الأخطاء في مرحلة إعداد طلب السحب.

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

حتى الآن ، تم إنشاء 6600 مهمة سحب وتم إجراؤها بهذه الطريقة.

تسليم مستمر

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

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

• المحررين لنظام التشغيل MacOS و Windows. وهكذا ، كل صباح كل شخص لديه نسخة جديدة من الأدوات. وبفضل الاختبارات التلقائية ، نحن واثقون من جودتها واستقرارها.
• لعبة العميل والخادم لجميع المنصات. يتم تحميل عميل iOS إلى TestFlight ، لنظام Android - إلى Google Play ، والأنظمة الأخرى - إلى JFrog Artifactory وخوادم الألعاب والخدمات الأخرى - إلى السحابة. هذا هو ، كل صباح لدينا نسخة جديدة من اللعبة ، جاهزة للاختبار واختبارات اللعب.

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

1. مضيف المستوى الأول. تراقب استقرار الاختبارات في المستودع الرئيسي.
2. المصاحبة المستوى 2 على اللعبة. إصلاح لعبة البق.
3. حاضر المستوى الثاني على المحررين. إصلاح أخطاء التحرير ، وتقديم المشورة للمستخدمين (الفنانين ، والمصممين على مستوى ، ومصممي اللعبة).

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



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

أن تستمر ...

الجزء الأول: habr.com/en/post/461623