الافراج عن تطبيقات الهاتف المتحرك زر واحد

مرحبا! اسمي ميخائيل بولجاكوف (لا ، ليس قريبًا) ، أعمل كمهندس تحرير في Badoo. منذ خمس سنوات ، بدأت أتمتة إصدارات تطبيقات iOS ، التي وصفتها بالتفصيل في هذه المقالة . ثم تناول تطبيقات Android.



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



لمزيد من التفاصيل - مرحبًا بك في الخفاء!

ماذا وراء إصدار الهاتف المحمول

يتكون إصدار التطبيق على Badoo من ثلاث مراحل:

1. تطوير.
2. : , — , App Store Google Play.
3. , -.

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



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



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



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



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

الخطوات الأولى نحو الأتمتة: تحميل البيانات الوصفية

كيف كان يعمل في البداية: لكل إصدار ، تم إنشاء جدول في جداول بيانات Google ، حيث ملأ مدير المنتج النص الرئيسي الذي تم التحقق منه باللغة الإنجليزية ، وبعد ذلك قام المترجمون بتعديله لبلد معين ولهجة وجمهور ، ثم نقل مهندس الإصدار جميع المعلومات من هذا الجدول في App Store أو Google Play.



كانت الخطوة الأولى نحو الأتمتة التي اتخذناها هي دمج ترجمة النصوص في عملية الترجمة الشاملة لدينا. لن أطيل في الحديث عن هذا - هذا نظام كبير منفصل ، يمكنك أن تقرأ عنه في مقالتنا الأخيرة... النقطة الرئيسية هي أن المترجمين لا يضيعون الوقت على الأجهزة اللوحية ويعملون مع الواجهة للتحميل المريح باليد (اقرأ: ctrl + c ctrl + v) من الخيارات المترجمة في الصفحة. بالإضافة إلى ذلك ، هناك ميزات للإصدار وأساس البنية التحتية ككود.



في الوقت نفسه ، أضفنا إلغاء تحميل الترجمات الجاهزة من قاعدة البيانات وتضمينها في ملف IPA الذي تم جمعه (ملحق ملف تطبيق iOS). نحن نبني التطبيق في TeamCity. وبالتالي ، كان لكل إصدار من التطبيق دائمًا ترجمة جديدة دون تدخل يدوي في عملية التجميع.



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





واقعنا اعتبارًا من عام 2015



في المتوسط ​​، استغرق إصدار تطبيق واحد مع الإصدار الحالي من لقطات الشاشة حوالي ساعة ونصف إلى ساعتين من عمل مهندس الإصدار في حالة iOS وحوالي نصف ساعة في حالة Android. يرجع الفرق إلى حقيقة أن تطبيقات iOS يجب أن تمر بما يسمى المعالجة ، الأمر الذي يستغرق بعض الوقت (من المستحيل إرسال التطبيق إلى المراجعة قبل الانتهاء بنجاح من المعالجة). بالإضافة إلى ذلك ، كان App Store نفسه ، في معظم العمليات في ذلك الوقت ، أبطأ بكثير من Google Play.



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



سأقول بضع كلمات عنه لتوضيح ما سيتم مناقشته أكثر.

Fastlane في لمحة

اليوم Fastlane هو منتج يمكنه أتمتة جميع الإجراءات تقريبًا من لحظة اكتمال التطوير إلى إصدار التطبيق في App Store و Google Play. ولا يتعلق الأمر فقط بتنزيل النصوص ولقطات الشاشة والتطبيق نفسه - إليك إدارة الشهادات والاختبار التجريبي وتوقيع التعليمات البرمجية والمزيد.



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



كما أنه يبعث على الثقة في أن Google مؤسس شركة Fastlane والمطور الرئيسي لها: والآن لا يدعم المكون المجتمع فحسب ، بل يدعم نفسه أيضًا.



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

أتمتة الإصدار IOS

نظرًا لأن Google Play أكثر ملاءمة للمطورين ، لم يستغرق الأمر وقتًا طويلاً لإصدار تطبيق Android: بضع دقائق دون تحديث النصوص ومقاطع الفيديو ولقطات الشاشة. وبالتالي عدم الحاجة إلى الأتمتة. ولكن مع App Store ، كانت المشكلة ملموسة للغاية: استغرق إرسال التطبيقات إلى المراجعة وقتًا طويلاً. لذلك ، تقرر بدء التشغيل الآلي مع iOS.



فكرنا في تشابه نظامنا لأتمتة التفاعل مع App Store (وحتى صنع نماذج أولية) ، ولكن لم يكن لدينا الموارد لإنهاء وتحديث. أيضًا ، لم يكن هناك واجهة برمجة تطبيقات كافية أو أقل من Apple. حسنًا ، كان آخر مسمار في نعش حلنا المخصص مدفوعًا بالتحديثات المنتظمة لمتجر التطبيقات وآلياته. بشكل عام ، قررنا تجربة Fastlane - ثم إصدار آخر من عام 2015.



كانت الخطوة الأولى هي كتابة آلية لتحميل النصوص المترجمة للتطبيقات إلى الهيكل المطلوب كعنصر في نظامنا الداخلي المشترك AIDA (مساعد النشر التفاعلي الآلي). هذا النظام هو نوع من المحور ، حلقة وصل بين جميع الأنظمة والتقنيات والمكونات المستخدمة في Badoo. وهو يعمل على نظام قائمة انتظار مكتوب ذاتيًا يتم تنفيذه في Golang و MySQL. يقوم قسم هندسة الإصدار بتحسينه وتحسينه. تحدثنا عنه بمزيد من التفصيل في مقال في عام 2013 ، منذ ذلك الحين تغير الكثير. ونعد بأن نخبرك بذلك مرة أخرى - إن AIDA رائعة!



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



أدى هذا إلى تقليل وقت التحضير للإصدار من ساعتين إلى حوالي 30 دقيقة ، منها دقيقة ونصف فقط يجب أن تتم يدويًا! بقية الوقت هو الانتظار. انتظر حتى نهاية المعالجة. كانت الآلية اختراقة في ذلك الوقت على وجه التحديد لأنها حفظتنا بالكامل تقريبًا من العمل اليدوي عند إعداد AppStore للإصدار. أنشأنا مستودعًا للنص البرمجي ، والذي منحنا إمكانية الوصول إليه للأشخاص المرتبطين مباشرةً بالإصدارات (مديري المشاريع ، مهندسي الإصدار).



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



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

1. كان علينا أن نذهب إلى TeamCity لبناء جديد ، تنزيل ملف IPA من هناك ، وتحميله إلى App Store من خلال مدير التطبيقات.
2. ثم انتقل إلى الواجهة التي تحتوي على ترجمات في AIDA ، وتحقق مما إذا كانت جميع الترجمات جاهزة ، وقم بتشغيل البرنامج النصي ، وتأكد من أنها تعمل بشكل صحيح (بعد كل شيء ، كان Fastlane لا يزال رطبًا في ذلك الوقت).
3. App Store , Processing.
4. Review.

وهكذا مع كل تطبيق. دعني أذكرك بأنه في ذلك الوقت كان لدينا ثمانية.



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



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





AIDA أحسنت ، كن مثل AIDA!



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



بالإضافة إلى ذلك ، تم رسم واجهة بسيطة: كلنا نحب النقر فوق.





لذا ، تبويب بعلامة تبويب ، Ctrl + C Ctrl + V ...

أتمتة الإصدار الروبوت

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

1. انتقل إلى وحدة تحكم Google Play للتأكد من طرح الإصدار السابق على 100٪ من المستخدمين أو تجميده.
2. قم بإنشاء نسخة جديدة من الإصدار بنصوص ولقطات شاشة محدثة (إن وجدت).
3. تحميل ملف APK (حزمة Android) ، تحميل ملف الخرائط.
4. انتقل إلى HockeyApp (المستخدم لتسجيل الأعطال في ذلك الوقت) ، وقم بتحميل ملف APK وملف التعيين هناك.
5. انتقل إلى الدردشة وقم بإلغاء الاشتراك حول حالة الإصدار.

وهكذا مع كل تطبيق.



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



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



كان Fastlane مسؤولًا عن تحميل ملفات APK وخرائط إلى Google Play. يجب أن أقول أنه من الأسهل بكثير اتباع المسار المطروق: تم تنفيذه بسرعة كافية بأقل قدر من الجهد.



في مرحلة معينة من تنفيذ الأتمتة ، كان هناك انتقال من أرشيف APK إلى AAB (Android App Bundle). مرة أخرى ، كنا محظوظين لأنه في المطاردة الساخنة اتضح بسرعة كبيرة لإصلاح كل شيء ، ولكن تمت إضافة "الترفيه" فيما يتعلق بهذا الانتقال. على سبيل المثال ، أفسد HockeyApp ، الذي لم يكن يعرف كيفية استخدام أرشيفات AAB فيما يتعلق بالتحضير للنشر الذاتي. لذلك من أجل الاستمرار في استخدامه بشكل مريح ، بعد تجميع AAB ، كان من الضروري تفكيك الأرشيف المجمع ، والحصول على ملف التعيين من هناك ، والذي سيطير إلى HockeyApp ، ومن AAB كان من الضروري جمع ملف APK بشكل منفصل ثم تحميله إلى نفس HockeyApp فقط. يبدو ممتع. في الوقت نفسه ، يقوم Google Play نفسه بتحليل AAB بشكل مثالي ، ويزيل ملف التعيين من هناك ويدرجه عند الحاجة. لذلك تخلصنا من خطوة واحدة وأضفنا القليل منها ، ولكن لم يكن هناك أي تحايل عليها.



تمت كتابة واجهة (مرة أخرى ، على غرار iOS) ، والتي كانت قادرة على تنزيل إصدار جديد ، والتحقق من الإصدار على طول وعبر ، وإدارة الإصدار النشط الحالي (على سبيل المثال ، زيادة نسبة الطرح). في هذا النموذج ، قدمناها لأعضاء فريق Android QA المسؤول عن الإصدارات ، وبدأنا في جمع التعليقات ، وإصلاح الأخطاء ، وتحسين المنطق (وماذا يحدث بعد الإصدار 1.0؟).



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

توحيد تدفق الإصدارات المتنقلة

بحلول وقت التشغيل التلقائي لإصدارات Android ، تعلمت Fastlane أخيرًا كيفية إرسال إصدارات من تطبيقات iOS للمراجعة. وقد قمنا بتحسين طفيف لنظام التحكم في الإصدار في AIDA.



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



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





حسنًا ، جميلة؟



لقد أحببنا فكرة القالب كثيرًا لدرجة أننا قررنا صنع فكرة مماثلة لإصدارات Android. في حين أن لدينا تطبيقًا مكتوبًا بالكامل في React Native ، وفريق QA للتطبيق مسؤول عن كل من إصدارات iOS و Android.



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

انتاج |

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



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



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



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



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