الافراج عن القطار. تقرير ياندكس

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


- مرحبًا بالجميع ، أنا ديميتري بولياكوف ، مطور Android لتطبيقات الجوّال التي أتناولها.



الآن في فريقين - تطوير Android و iOS - 13 شخصًا لكل منهما. وهذا يتيح لنا القيام بالعديد من المهام الرائعة بالتوازي ولفها بسرعة للمستخدمين. في التقرير سأخبرنا كيف تعلمنا العمل مع git والعيش في مستودع واحد.

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

تدفق البوابة

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

كيف يعمل معنا؟ Epic هو الفرع الجذر لميزتك ، لبعض الوظائف الرائعة. لجعل الأمر أكثر وضوحًا ، فلنلق نظرة على الفور على مثال المنتج.



يأتي المدير ويقول - المطور ، يجعلنا وظائف قائمة الرغبات مع المنتجات المحددة في التطبيق. يبدأ المطور ملحمة فرع جديدة ويطلق عليها قائمة الأمنيات.



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

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

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



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



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

إن تطويرنا هو مثل هذا الفرع الذي تزوره فيه الشفرة التي تم اختبارها بالفعل ، لأنه في المرحلة الملحمية يتم اختبارها ويمر الرمز عبر طلب التجمع.



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

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

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



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

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

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



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

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



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



نظرًا لأننا أضفنا تطوير الملحمة ، يجب إضافة الملحمة لنفس الأسباب إلى ميزتك.



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



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



ماجستير وتطوير هي فروع تعيش باستمرار في مستودعنا. بمجرد إنشاء والعيش. لذلك ، يتم تسميتها بإيجاز.

هذه هي الطريقة التي نعيش بها. الآن نحن مرتاحون ومريحون.

الافراج عن القطار

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

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

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



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

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



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

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



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

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

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

بعد ذلك ، سأخبرك بكيفية ترتيب المنشورات من خلال Google Play ، لأن لدينا نسبة كبيرة جدًا من المستخدمين هناك. وفي Huawei AppGallery ، غادرنا مؤخرًا وما زلنا نحاول فهم كيفية ترتيب كل شيء هناك.

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



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



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

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

إذا كانت المراجعات مرتبة ، وخالية من التعطل طبيعية أيضًا ولم تتدهور مقاييس المنتج ، فنحن بالفعل نطرحها بنسبة 20٪.



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

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

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

هذه هي عمليتنا ، لذلك نركب كل أسبوع ونحاول ألا نضيع.


ما هي الأدوات الأخرى التي لدينا لدعم الحياة الجيدة للمستخدم من جانبه؟ هذه هي تحديث القوة والتحديث المرن والتبديل بين الميزات.



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

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



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

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

سمح لنا Soft Update بتقليل ذيل الإصدارات بشكل كبير ، ويتم تنفيذه ببساطة وفقًا للتوثيق. جربه إذا كان لديك العديد من الإصدارات.



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

لنتحدث عن كيفية عمل Feature Toggle على مثال تطبيق تابع لجهة خارجية - مركبة. في البداية ، يمتلك المطورون مثل هذه الدراجة ، والتي تحتوي بالفعل على ميزة تبديل اثنين: محرك وحجم كبير. يستخدم العملاء الدراجة ، ثم يقول فريق الاختبار: اختبرنا المحرك ، يعمل ، يقود ، بارد ، دعنا نشغلها للمستخدم.



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

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



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

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



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

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



الآن ، كما قلت بالفعل ، لدينا 13 شخصًا في كل من فرق تطوير Android و iOS. نحن نعمل على Git Flow ، في مستودع واحد ، نقوم بإعداد عملية الإصدار المخطط لها ، وقللنا من وقتنا في التسوق والركوب كل أسبوع. قمنا مؤخرًا بإصدار Huawei AppGallery وإلقاء نظرة على المتاجر الأخرى. لقد تعلمنا كيفية تغيير تطبيقات المستخدم بدون تحديثات بسبب ميزة Toggle. شكرا للانتباه.