كيف نحافظ على استقرار تطبيق Lamoda

مرحبا بالجميع!

اسمي فيتالي بنديك. أنا قائد الفريق لتطوير تطبيقات أندرويد في لامودا. في عام 2018 ، تحدثت في Mosdroid Aluminium مع تقرير ، نصه أرغب في مشاركته.



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

سأقول في التقرير:

1. ما نعنيه استقرار التطبيق ؛
2. حول بنية تطبيق المحمول لدينا.
3. حول العمليات والممارسات والأدوات التي نستخدمها.

لذلك ، ما هو تطبيق مستقر بالنسبة لنا؟ هذا هو التطبيق الذي لا يتعطل ، لا يتعطل ويعمل بشكل متوقع. عندما أقول أنه لا يسقط ، أعني أنه لا يقع في ما لا يقل عن 95 ٪ -99 ٪ من المستخدمين.

هندسة معمارية

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

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




صفحة المنتج. أمثلة عناصر القطعة

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



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

كومة

- نكتب كل الكود الجديد في Kotlin ، ونستخدم Moxy كتطبيق MVP.
- كما نستخدم Dagger2 .
- للعمل مع الشبكة - التحديثية .
- للعمل مع الصور - الإنزلاق .
- نضيف حوادث إلى بقايا جديدة .
- نحن نستخدم أيضا لوتي .
- في الوقت الحالي ، نحن نستخدم Kotlin Coroutines بنشاط.

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

نحن نلتزم بتدفق Git ، أي ، يتم تنفيذ كل ميزة في فرع ميزة منفصل ، والذي ، بعد مراجعة الكود ، يتم تقديمه للاختبار.

بعد الانتهاء من الاختبار بنجاح ، وقررنا الإصدار الذي ستنتقل إليه هذه الميزة ، يتم دمجها في برنامج الماجستير.

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



بالنسبة إلى CI / CD ، نظرًا لأننا نستخدم مكدس Atlassian ، يعمل Bamboo كخادم بناء.

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

إذا بدأ اختبار التجميع من أجل اختبار الميزة ، ثم يتم تحميل apk أيضا في HockeyApp.

لنشر الإصدار على Google Play Beta ، يبدأ مدير التسليم المهمة المقابلة على Bamboo ، التي تدير نفس التدفق ، ولكن أيضًا تقوم بتحميل الإصدار إلى Google Play Beta.

الممارسات التطبيقية

قبل الإصدار بناء

في البداية ، كان لدينا نوعان من التجميع ، مثل العديد من:

إنشاء تصحيح حيث تم تعطيل ProGuard و SSL Pinning.
إنشاء الإصدار الذي تم تضمين ProGuard و SSL Pinning فيه.
بدت العملية على هذا النحو: ينتهي المطور من العمل على الميزة ويعطيها للاختبار. يقوم المختبر بجمع مجموعة Debug واختبار حالات الاختبار عليها والتحقق من صحة التحليلات المرسلة من قبل التطبيق. إذا كان كل شيء على ما يرام ، ثم يرسل المهمة إلى Ready for release ، وتنتظر اللحظة التي نبدأ فيها بتجميع الإصدار.

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

لهذا السبب ، أنشأنا بناءً ما قبل الإصدار يتم فيه تشغيل ProGuard وإيقاف SSL Pinning. يسمح هذا للمُختبرين بالتحقق من صحة التحليلات المقدمة (كان هذا هو السبب في عدم قيام المُختبرين في البداية بإنشاء إصدار الإصدار).
الآن ، تقوم QAs ببناء إصدار ما قبل النشر. هذا يتيح لهم الفرصة لاختبار التحليلات ومواجهة المشاكل التي تسببها ProGuard في أقرب وقت ممكن.

المواصفات أولا

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



في البداية ، كان لدينا واجهة برمجة تطبيقات لم يكن عملائها مجرد تطبيقات للهواتف المحمولة. أساليب API لم تكن متسقة مع بعضها البعض ، مما جعل التغييرات في كثير من الأحيان صعبة.

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



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



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



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

ميزة تبديل

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

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

مراقبة المستخدم الحقيقي

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

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

1. استهلاك الذاكرة.
2. استهلاك وحدة المعالجة المركزية.
3. ما حدث على التيار الرئيسي ؛
4. ما تم تحميله من الشبكة ؛
5. ما حدث في المواضيع الأخرى.

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

استرداد الديون الفنية

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

بعد إصدار الإصدار ، نقوم بتوزيعه حسب النسبة المئوية ، ونراقب المؤشرات المهمة ونرد على الحوادث في حالة حدوثها. للتداول التدريجي ، نستخدم Google Play Console. يتم تنفيذ الدرفلة على النحو التالي: يتم إخراجها بنسبة 5٪ ، نراقب المؤشر ؛ إذا كان كل شيء على ما يرام ، فاستمر. في حالة حدوث شيء ما ، قم بإجراء الإصلاح العاجل وطرحه بالفعل. بعد ذلك ، نقوم بالمتداول بنسبة 10 ٪ و 20 ٪ و 50 ٪.

ما هي الأماكن الهامة التي نراقبها ؟

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

الأدوات

• أداة A / B
• NewRelic دورة في الدقيقة
• رؤى NewRelic.

أداة A / B هي آلية لإجراء التجارب وآلية لمتغيرات المتداول ، نفس تبديل الميزات. هذا تطور داخلي ، لذا فهو مدمج جيدًا في العديد من الأنظمة: في تطبيقات الهاتف المحمول ، على الموقع ، في النهاية الخلفية. يسمح لك بنقل تكوين ميزة التبديل - ليس في طلب منفصل خلفه ، ولكن في رؤوس الردود على الطلبات التي يقوم بها التطبيق.

هذا يعطينا الفرصة:

• طرح تجارب على المكتب عندما نريد اختبار بعض الميزات داخل مكتبنا.
• طرح تجربة ، وكذلك ميزة التبديل لمستخدم معين.

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

NewRelic هي أداة تسمح لك بمراقبة الكثير من المؤشرات المختلفة في الوقت الفعلي. من بين مجموعة متنوعة من ميزات New Relic ، نستخدم ، على سبيل المثال ، أجهزة الكود الآلي. هذا هو الذي يسمح لنا بمراقبة طلبات الشبكة ليس فقط على الواجهة الخلفية لدينا ، ولكن أيضًا جميع الباقي (بما في ذلك مكتبات الجهات الخارجية). يدعم NewRelic مجموعة معينة من العملاء القياسيين للعمل مع الشبكة. كما يسمح لك بجمع المعلومات:

1. عن استهلاك الذاكرة ؛
2. عن استهلاك وحدة المعالجة المركزية.
3. حول العمليات المتعلقة JSON ؛
4. حول العمليات المتعلقة SQlite.

بالإضافة إلى ذلك ، نستخدم NewRelic لجمع تقارير الأعطال ، ولجمع الاستثناءات التي يتم التعامل معها ولتفاعلات المستخدم - وهذا هو بالضبط نفس مراقبة المستخدم الحقيقي . قمنا بتنفيذها من خلال آلية تفاعلات المستخدم NewRelic.

ولكن ماذا عن الاستقرار؟

لدينا مؤشر مثل معدل التصادم. في السابق ، طرحنا الإصلاح العاجل عندما كان مؤشره في حدود 0.3٪ إلى 0.5٪. من الأهمية بمكان أن تصبح قيمته أكثر من 0.5٪ ، والآن نقوم بتطبيق الإصلاح العاجل عندما يكون معدل الأعطال في حدود 0.1٪ إلى 0.3٪. تبلغ القيمة الحرجة أكثر من 0.3٪ ، وإذا كان متوسط ​​معدل الأعطال في طلبنا سابقًا هو 0.1٪ ، فقد أصبح الآن 0.05٪.



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