ارائه نسخه جدید اپلیکیشن موبایل به مرحله تولید، یکی از هیجانانگیزترین بخشهای توسعه اپلیکیشن است، اما میتواند یکی از استرسزاترین آنها نیز باشد! تیم شما باید میزان جذب نسخه، اشکالات جدید و تأثیر این اشکالات، مقایسه با نسخههای قبلی و موارد دیگر را پیگیری کند.
این صفحه چندین ابزار ارائه شده توسط Firebase را برای نظارت بر دادههایی که برای اطمینان از انتشار برنامه تلفن همراه خود نیاز دارید، شرح میدهد.
از داشبورد نظارت بر انتشار برای بررسی دادههای مربوط به انتشار خود استفاده کنید
داشبورد نظارت بر انتشار در کنسول Firebase توسط Firebase Crashlytics پشتیبانی میشود. این یک داشبورد واحد برای نظارت بر جدیدترین نسخه تولیدی شماست. این داشبورد تقریباً به صورت بلادرنگ بهروزرسانی میشود و به شما یک نمای سطح بالا از مهمترین معیارهای انتشار، از جمله معیارهای بدون خرابی، میزان جذب نسخه، مقایسه با نسخههای قبلی و هرگونه مشکل جدید برای انتشار، ارائه میدهد.
این داشبورد جدید، صفحه «آخرین نسخه» در کنسول را بهبود میبخشد. در مقایسه با آن صفحه، داشبورد «نظارت بر انتشار» اطلاعات بیشتری اضافه میکند، دادههای مفیدی را بدون نیاز به گوگل آنالیتیکس نمایش میدهد و سریعتر بارگذاری میشود.
ویژگیهای داشبورد
گزارشدهی بلادرنگ
تمام نمودارها تقریباً به صورت آنی بهروزرسانی میشوند. کمی پس از استقرار آخرین نسخه، میتوانید شاهد شروع تعامل کاربران با آن نسخه باشید. اگر برخی از این کاربران دچار خرابی شوند، فوراً از طریق نمودارهای معیارهای بدون خرابی ، تأثیر آن را خواهید دید.مقایسه و بنچمارک بر اساس نسخههای قبلی
شما میتوانید پایداری آخرین نسخه خود را در مقایسه با نسخههای قبلی مشاهده کنید. داشبورد به شما امکان میدهد معیارهای زنده آخرین نسخه و حداکثر دو نسخه از نسخههای قبلی خود را مقایسه کنید.شمارههای جدید برتر
شما میتوانید خرابیهای جدید آخرین نسخه خود را به محض رسیدن مشاهده کنید. در جدول «مشکلات جدید برتر» ، میتوانید تأثیر مشکلاتی را که برای اولین بار در آخرین نسخه شما شناسایی شدهاند، رصد کنید و به شما این امکان را میدهد که به سرعت در مورد توقف یا بازگرداندن نسخه به نسخه قبلی تصمیم بگیرید.
الزامات مربوط به داشبورد
برای مشاهده آخرین نسخه خود در داشبورد نظارت بر انتشار ، موارد زیر را انجام دهید:
مطمئن شوید که برنامه شما حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+نسخه جدیدی از برنامه را در محیط عملیاتی منتشر کنید تا تعداد کافی از کاربران با آخرین نسخه شما تعامل داشته باشند.
سوالات متداول در مورد داشبورد
برای اینکه یک نسخه در داشبورد ظاهر شود، باید حداقل از نسخههای زیر از Crashlytics SDK استفاده کند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+
توجه داشته باشید که این نسخههای SDK اغلب به عنوان نسخههای SDK با قابلیت session شناخته میشوند، زیرا قادر به ارسال دادههای session به Crashlytics هستند که برای بسیاری از ویژگیهای جدید Crashlytics ، مانند داشبورد Release Monitoring ، مورد نیاز است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
داشبورد نظارت بر انتشار، با هدف کمک به شما در انتشار نسخههای عملیاتی، یعنی نسخههایی که تعداد قابل توجهی کاربر دارند، طراحی شده است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
(برای برنامههایی که از طریق Google Play توزیع شدهاند) اگر برنامهای لینک Google Play داشته باشد، داشبورد تمام نسخههای موجود در لیست Play Prod را نشان میدهد، حتی اگر Crashlytics هیچ گزارش نشستی دریافت نکرده باشد یا کاربران فعالی را برای آن نسخه شناسایی نکرده باشد.
توجه داشته باشید که برای مشاهده دادهها در داشبورد برای مقایسه یا درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات قبلی را برآورده کنند.
اول از همه، درک برخی از اصطلاحات مربوط به نمودار کاربران فعال مفید است:
یک جلسه (session) یک دوره زمانی مداوم است که کاربر با یک برنامه درگیر است. یک جلسه جدید زمانی شروع میشود که برنامه به صورت سرد (cold-started) شروع به کار کند یا برنامه پس از حداقل 30 دقیقه فعالیت در پسزمینه، در حالت آماده به کار (forgrounded) قرار گیرد.
کاربران فعال برای یک ساخت خاص، تعداد کاربرانی هستند که با استفاده از آن ساخت، جلسهای را آغاز کردهاند و بر اساس ساعت گروهبندی شدهاند.
کل کاربران (فعال) تعداد کاربرانی است که در هر نسخه از برنامه که از نسخه SDK با قابلیت session استفاده میکند، یک جلسه را شروع کردهاند و بر اساس ساعت گروهبندی شدهاند.
در نمودار کاربران فعال ، مقدار درصد و تعداد کاربران فعال که همیشه در نمودار نمایش داده میشوند، مربوط به ۶۰ دقیقه گذشته هستند (یا اگر در ۶۰ دقیقه گذشته هیچ کاربر فعالی وجود نداشته است، دوره زمانی یک ساعته گذشته که داده داشته است). برای مثال، در تصویر نمونه، در ۶۰ دقیقه گذشته ۹۰ کاربر فعال برای نسخه 6.0.0 (600) وجود داشته است که ۲۲.۱٪ از کل کاربران (فعال) برنامه را تشکیل میدهد.
وقتی ماوس را روی خطوط نمودار کاربران فعال نگه میدارید، درصد کاربران فعال از تعداد کاربران فعال در دوره ساعتی که ماوس را روی آن نگه داشتهاید محاسبه میشود.
توجه داشته باشید که برای مشاهده درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات شرح داده شده در سوالات متداول «کدام نسخهها را میتوان در داشبورد نظارت بر انتشار مشاهده کرد؟» را برآورده کنند .
درصد کاربران فعال بر اساس دادههای دریافتی از جلسات محاسبه میشود، نه بر اساس دادههای دیگر (مانند دادههای Google Play یا گزارشهای خرابی).
اگر این اولین باری است که برنامه خود را با نسخه سازگار Crashlytics SDK منتشر میکنید، Crashlytics هیچ دادهای از جلسات قبلی برای مقایسه ندارد.
تنظیم هشدارها
چندین محصول Firebase، از جمله Crashlytics ، میتوانند به دلایل مختلف مربوط به محصول، هشدار ارسال کنند. برای دریافت هشدارها ، باید مجوزهای لازم را داشته باشید.
برای نظارت بر پایداری آخرین نسخه خود، میتوانید هشدارهایی را هم از Performance Monitoring و هم Crashlytics تنظیم کنید. به طور خاص برای Crashlytics ، میتوانید هشدارهای زیر را تنظیم کنید:
از هشدارهای سرعت استفاده کنید تا در صورت عبور هر مشکل خاص در برنامهتان از آستانهای که در کنسول Firebase تعریف کردهاید، به تیم خود اطلاع دهید.
هشدارهای مربوط به مشکلات جدید یا رفعشده را به کانال اعلان دلخواه خود ارسال کنید:
از یکپارچهسازیهای هشدار پیکربندیشده توسط Firebase-console برای Slack ، Jira و PagerDuty استفاده کنید.
با استفاده Cloud Functions for Firebase ، هشدار پیشرفته برای سرویسهای شخص ثالث تنظیم کنید.
قبل از رهاسازی، از رهاسازی روان آن اطمینان حاصل کنید
قبل از انتشار آخرین نسخه، استفاده از برخی از سرویسها و ویژگیهای زیر را برای اطمینان از انتشار روان در نظر بگیرید.
از سرویسهای تست قبل از انتشار استفاده کنید
فایربیس دو محصول ارائه میدهد که میتوانند به آزمایش قبل از انتشار کمک کنند: Test Lab و App Distribution . هر دوی این سرویسها میتوانند در جریانهای CI/CD شما ادغام شوند.
Firebase Test Lab یک زیرساخت تست اپلیکیشن مبتنی بر ابر است که به شما امکان میدهد اپلیکیشن خود را روی طیف وسیعی از دستگاهها و پیکربندیها آزمایش کنید، بنابراین میتوانید درک اولیهای از نحوه عملکرد آن در دست کاربران واقعی داشته باشید.
و وقتی آماده شدید که آخرین نسخه ساخته شده خود را به دست آزمایشکنندگان انسانی مورد اعتماد بسپارید، از Firebase App Distribution استفاده کنید. میتوانید توزیعهای پیشانتشار پلتفرم اپل و اندروید خود را از یک جا مدیریت کنید.
از سرویسهای آزمایشی گسترده و محدود استفاده کنید
از Firebase Remote Config برای راهاندازی ویژگیهای جدید با مکانیزم انتشار درصدی یا آزمایش آن ویژگیها در یک گروه آزمایشی محدود استفاده کنید.
فایربیس همچنین A/B Testing ارائه میدهد تا بتوانید تغییرات در رابط کاربری، ویژگیها یا کمپینهای تعامل برنامه خود را آزمایش کنید تا ببینید که چگونه بر معیارهای کلیدی شما (مانند درآمد و حفظ مشتری) تأثیر میگذارند، قبل از اینکه آنها را به طور گسترده اعمال کنید.
،ارائه نسخه جدید اپلیکیشن موبایل به مرحله تولید، یکی از هیجانانگیزترین بخشهای توسعه اپلیکیشن است، اما میتواند یکی از استرسزاترین آنها نیز باشد! تیم شما باید میزان جذب نسخه، اشکالات جدید و تأثیر این اشکالات، مقایسه با نسخههای قبلی و موارد دیگر را پیگیری کند.
این صفحه چندین ابزار ارائه شده توسط Firebase را برای نظارت بر دادههایی که برای اطمینان از انتشار برنامه تلفن همراه خود نیاز دارید، شرح میدهد.
از داشبورد نظارت بر انتشار برای بررسی دادههای مربوط به انتشار خود استفاده کنید
داشبورد نظارت بر انتشار در کنسول Firebase توسط Firebase Crashlytics پشتیبانی میشود. این یک داشبورد واحد برای نظارت بر جدیدترین نسخه تولیدی شماست. این داشبورد تقریباً به صورت بلادرنگ بهروزرسانی میشود و به شما یک نمای سطح بالا از مهمترین معیارهای انتشار، از جمله معیارهای بدون خرابی، میزان جذب نسخه، مقایسه با نسخههای قبلی و هرگونه مشکل جدید برای انتشار، ارائه میدهد.
این داشبورد جدید، صفحه «آخرین نسخه» در کنسول را بهبود میبخشد. در مقایسه با آن صفحه، داشبورد «نظارت بر انتشار» اطلاعات بیشتری اضافه میکند، دادههای مفیدی را بدون نیاز به گوگل آنالیتیکس نمایش میدهد و سریعتر بارگذاری میشود.
ویژگیهای داشبورد
گزارشدهی بلادرنگ
تمام نمودارها تقریباً به صورت آنی بهروزرسانی میشوند. کمی پس از استقرار آخرین نسخه، میتوانید شاهد شروع تعامل کاربران با آن نسخه باشید. اگر برخی از این کاربران دچار خرابی شوند، فوراً از طریق نمودارهای معیارهای بدون خرابی ، تأثیر آن را خواهید دید.مقایسه و بنچمارک بر اساس نسخههای قبلی
شما میتوانید پایداری آخرین نسخه خود را در مقایسه با نسخههای قبلی مشاهده کنید. داشبورد به شما امکان میدهد معیارهای زنده آخرین نسخه و حداکثر دو نسخه از نسخههای قبلی خود را مقایسه کنید.شمارههای جدید برتر
شما میتوانید خرابیهای جدید آخرین نسخه خود را به محض رسیدن مشاهده کنید. در جدول «مشکلات جدید برتر» ، میتوانید تأثیر مشکلاتی را که برای اولین بار در آخرین نسخه شما شناسایی شدهاند، رصد کنید و به شما این امکان را میدهد که به سرعت در مورد توقف یا بازگرداندن نسخه به نسخه قبلی تصمیم بگیرید.
الزامات مربوط به داشبورد
برای مشاهده آخرین نسخه خود در داشبورد نظارت بر انتشار ، موارد زیر را انجام دهید:
مطمئن شوید که برنامه شما حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+نسخه جدیدی از برنامه را در محیط عملیاتی منتشر کنید تا تعداد کافی از کاربران با آخرین نسخه شما تعامل داشته باشند.
سوالات متداول در مورد داشبورد
برای اینکه یک نسخه در داشبورد ظاهر شود، باید حداقل از نسخههای زیر از Crashlytics SDK استفاده کند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+
توجه داشته باشید که این نسخههای SDK اغلب به عنوان نسخههای SDK با قابلیت session شناخته میشوند، زیرا قادر به ارسال دادههای session به Crashlytics هستند که برای بسیاری از ویژگیهای جدید Crashlytics ، مانند داشبورد Release Monitoring ، مورد نیاز است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
داشبورد نظارت بر انتشار، با هدف کمک به شما در انتشار نسخههای عملیاتی، یعنی نسخههایی که تعداد قابل توجهی کاربر دارند، طراحی شده است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
(برای برنامههایی که از طریق Google Play توزیع شدهاند) اگر برنامهای لینک Google Play داشته باشد، داشبورد تمام نسخههای موجود در لیست Play Prod را نشان میدهد، حتی اگر Crashlytics هیچ گزارش نشستی دریافت نکرده باشد یا کاربران فعالی را برای آن نسخه شناسایی نکرده باشد.
توجه داشته باشید که برای مشاهده دادهها در داشبورد برای مقایسه یا درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات قبلی را برآورده کنند.
اول از همه، درک برخی از اصطلاحات مربوط به نمودار کاربران فعال مفید است:
یک جلسه (session) یک دوره زمانی مداوم است که کاربر با یک برنامه درگیر است. یک جلسه جدید زمانی شروع میشود که برنامه به صورت سرد (cold-started) شروع به کار کند یا برنامه پس از حداقل 30 دقیقه فعالیت در پسزمینه، در حالت آماده به کار (forgrounded) قرار گیرد.
کاربران فعال برای یک ساخت خاص، تعداد کاربرانی هستند که با استفاده از آن ساخت، جلسهای را آغاز کردهاند و بر اساس ساعت گروهبندی شدهاند.
کل کاربران (فعال) تعداد کاربرانی است که در هر نسخه از برنامه که از نسخه SDK با قابلیت session استفاده میکند، یک جلسه را شروع کردهاند و بر اساس ساعت گروهبندی شدهاند.
در نمودار کاربران فعال ، مقدار درصد و تعداد کاربران فعال که همیشه در نمودار نمایش داده میشوند، مربوط به ۶۰ دقیقه گذشته هستند (یا اگر در ۶۰ دقیقه گذشته هیچ کاربر فعالی وجود نداشته است، دوره زمانی یک ساعته گذشته که داده داشته است). برای مثال، در تصویر نمونه، در ۶۰ دقیقه گذشته ۹۰ کاربر فعال برای نسخه 6.0.0 (600) وجود داشته است که ۲۲.۱٪ از کل کاربران (فعال) برنامه را تشکیل میدهد.
وقتی ماوس را روی خطوط نمودار کاربران فعال نگه میدارید، درصد کاربران فعال از تعداد کاربران فعال در دوره ساعتی که ماوس را روی آن نگه داشتهاید محاسبه میشود.
توجه داشته باشید که برای مشاهده درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات شرح داده شده در سوالات متداول «کدام نسخهها را میتوان در داشبورد نظارت بر انتشار مشاهده کرد؟» را برآورده کنند .
درصد کاربران فعال بر اساس دادههای دریافتی از جلسات محاسبه میشود، نه بر اساس دادههای دیگر (مانند دادههای Google Play یا گزارشهای خرابی).
اگر این اولین باری است که برنامه خود را با نسخه سازگار Crashlytics SDK منتشر میکنید، Crashlytics هیچ دادهای از جلسات قبلی برای مقایسه ندارد.
تنظیم هشدارها
چندین محصول Firebase، از جمله Crashlytics ، میتوانند به دلایل مختلف مربوط به محصول، هشدار ارسال کنند. برای دریافت هشدارها ، باید مجوزهای لازم را داشته باشید.
برای نظارت بر پایداری آخرین نسخه خود، میتوانید هشدارهایی را هم از Performance Monitoring و هم Crashlytics تنظیم کنید. به طور خاص برای Crashlytics ، میتوانید هشدارهای زیر را تنظیم کنید:
از هشدارهای سرعت استفاده کنید تا در صورت عبور هر مشکل خاص در برنامهتان از آستانهای که در کنسول Firebase تعریف کردهاید، به تیم خود اطلاع دهید.
هشدارهای مربوط به مشکلات جدید یا رفعشده را به کانال اعلان دلخواه خود ارسال کنید:
از یکپارچهسازیهای هشدار پیکربندیشده توسط Firebase-console برای Slack ، Jira و PagerDuty استفاده کنید.
با استفاده Cloud Functions for Firebase ، هشدار پیشرفته برای سرویسهای شخص ثالث تنظیم کنید.
قبل از رهاسازی، از رهاسازی روان آن اطمینان حاصل کنید
قبل از انتشار آخرین نسخه، استفاده از برخی از سرویسها و ویژگیهای زیر را برای اطمینان از انتشار روان در نظر بگیرید.
از سرویسهای تست قبل از انتشار استفاده کنید
فایربیس دو محصول ارائه میدهد که میتوانند به آزمایش قبل از انتشار کمک کنند: Test Lab و App Distribution . هر دوی این سرویسها میتوانند در جریانهای CI/CD شما ادغام شوند.
Firebase Test Lab یک زیرساخت تست اپلیکیشن مبتنی بر ابر است که به شما امکان میدهد اپلیکیشن خود را روی طیف وسیعی از دستگاهها و پیکربندیها آزمایش کنید، بنابراین میتوانید درک اولیهای از نحوه عملکرد آن در دست کاربران واقعی داشته باشید.
و وقتی آماده شدید که آخرین نسخه ساخته شده خود را به دست آزمایشکنندگان انسانی مورد اعتماد بسپارید، از Firebase App Distribution استفاده کنید. میتوانید توزیعهای پیشانتشار پلتفرم اپل و اندروید خود را از یک جا مدیریت کنید.
از سرویسهای آزمایشی گسترده و محدود استفاده کنید
از Firebase Remote Config برای راهاندازی ویژگیهای جدید با مکانیزم انتشار درصدی یا آزمایش آن ویژگیها در یک گروه آزمایشی محدود استفاده کنید.
فایربیس همچنین A/B Testing ارائه میدهد تا بتوانید تغییرات در رابط کاربری، ویژگیها یا کمپینهای تعامل برنامه خود را آزمایش کنید تا ببینید که چگونه بر معیارهای کلیدی شما (مانند درآمد و حفظ مشتری) تأثیر میگذارند، قبل از اینکه آنها را به طور گسترده اعمال کنید.
،ارائه نسخه جدید اپلیکیشن موبایل به مرحله تولید، یکی از هیجانانگیزترین بخشهای توسعه اپلیکیشن است، اما میتواند یکی از استرسزاترین آنها نیز باشد! تیم شما باید میزان جذب نسخه، اشکالات جدید و تأثیر این اشکالات، مقایسه با نسخههای قبلی و موارد دیگر را پیگیری کند.
این صفحه چندین ابزار ارائه شده توسط Firebase را برای نظارت بر دادههایی که برای اطمینان از انتشار برنامه تلفن همراه خود نیاز دارید، شرح میدهد.
از داشبورد نظارت بر انتشار برای بررسی دادههای مربوط به انتشار خود استفاده کنید
داشبورد نظارت بر انتشار در کنسول Firebase توسط Firebase Crashlytics پشتیبانی میشود. این یک داشبورد واحد برای نظارت بر جدیدترین نسخه تولیدی شماست. این داشبورد تقریباً به صورت بلادرنگ بهروزرسانی میشود و به شما یک نمای سطح بالا از مهمترین معیارهای انتشار، از جمله معیارهای بدون خرابی، میزان جذب نسخه، مقایسه با نسخههای قبلی و هرگونه مشکل جدید برای انتشار، ارائه میدهد.
این داشبورد جدید، صفحه «آخرین نسخه» در کنسول را بهبود میبخشد. در مقایسه با آن صفحه، داشبورد «نظارت بر انتشار» اطلاعات بیشتری اضافه میکند، دادههای مفیدی را بدون نیاز به گوگل آنالیتیکس نمایش میدهد و سریعتر بارگذاری میشود.
ویژگیهای داشبورد
گزارشدهی بلادرنگ
تمام نمودارها تقریباً به صورت آنی بهروزرسانی میشوند. کمی پس از استقرار آخرین نسخه، میتوانید شاهد شروع تعامل کاربران با آن نسخه باشید. اگر برخی از این کاربران دچار خرابی شوند، فوراً از طریق نمودارهای معیارهای بدون خرابی ، تأثیر آن را خواهید دید.مقایسه و بنچمارک بر اساس نسخههای قبلی
شما میتوانید پایداری آخرین نسخه خود را در مقایسه با نسخههای قبلی مشاهده کنید. داشبورد به شما امکان میدهد معیارهای زنده آخرین نسخه و حداکثر دو نسخه از نسخههای قبلی خود را مقایسه کنید.شمارههای جدید برتر
شما میتوانید خرابیهای جدید آخرین نسخه خود را به محض رسیدن مشاهده کنید. در جدول «مشکلات جدید برتر» ، میتوانید تأثیر مشکلاتی را که برای اولین بار در آخرین نسخه شما شناسایی شدهاند، رصد کنید و به شما این امکان را میدهد که به سرعت در مورد توقف یا بازگرداندن نسخه به نسخه قبلی تصمیم بگیرید.
الزامات مربوط به داشبورد
برای مشاهده آخرین نسخه خود در داشبورد نظارت بر انتشار ، موارد زیر را انجام دهید:
مطمئن شوید که برنامه شما حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+نسخه جدیدی از برنامه را در محیط عملیاتی منتشر کنید تا تعداد کافی از کاربران با آخرین نسخه شما تعامل داشته باشند.
سوالات متداول در مورد داشبورد
برای اینکه یک نسخه در داشبورد ظاهر شود، باید حداقل از نسخههای زیر از Crashlytics SDK استفاده کند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+
توجه داشته باشید که این نسخههای SDK اغلب به عنوان نسخههای SDK با قابلیت session شناخته میشوند، زیرا قادر به ارسال دادههای session به Crashlytics هستند که برای بسیاری از ویژگیهای جدید Crashlytics ، مانند داشبورد Release Monitoring ، مورد نیاز است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
داشبورد نظارت بر انتشار، با هدف کمک به شما در انتشار نسخههای عملیاتی، یعنی نسخههایی که تعداد قابل توجهی کاربر دارند، طراحی شده است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
(برای برنامههایی که از طریق Google Play توزیع شدهاند) اگر برنامهای لینک Google Play داشته باشد، داشبورد تمام نسخههای موجود در لیست Play Prod را نشان میدهد، حتی اگر Crashlytics هیچ گزارش نشستی دریافت نکرده باشد یا کاربران فعالی را برای آن نسخه شناسایی نکرده باشد.
توجه داشته باشید که برای مشاهده دادهها در داشبورد برای مقایسه یا درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات قبلی را برآورده کنند.
اول از همه، درک برخی از اصطلاحات مربوط به نمودار کاربران فعال مفید است:
یک جلسه (session) یک دوره زمانی مداوم است که کاربر با یک برنامه درگیر است. یک جلسه جدید زمانی شروع میشود که برنامه به صورت سرد (cold-started) شروع به کار کند یا برنامه پس از حداقل 30 دقیقه فعالیت در پسزمینه، در حالت آماده به کار (forgrounded) قرار گیرد.
کاربران فعال برای یک ساخت خاص، تعداد کاربرانی هستند که با استفاده از آن ساخت، جلسهای را آغاز کردهاند و بر اساس ساعت گروهبندی شدهاند.
کل کاربران (فعال) تعداد کاربرانی است که در هر نسخه از برنامه که از نسخه SDK با قابلیت session استفاده میکند، یک جلسه را شروع کردهاند و بر اساس ساعت گروهبندی شدهاند.
در نمودار کاربران فعال ، مقدار درصد و تعداد کاربران فعال که همیشه در نمودار نمایش داده میشوند، مربوط به ۶۰ دقیقه گذشته هستند (یا اگر در ۶۰ دقیقه گذشته هیچ کاربر فعالی وجود نداشته است، دوره زمانی یک ساعته گذشته که داده داشته است). برای مثال، در تصویر نمونه، در ۶۰ دقیقه گذشته ۹۰ کاربر فعال برای نسخه 6.0.0 (600) وجود داشته است که ۲۲.۱٪ از کل کاربران (فعال) برنامه را تشکیل میدهد.
وقتی ماوس را روی خطوط نمودار کاربران فعال نگه میدارید، درصد کاربران فعال از تعداد کاربران فعال در دوره ساعتی که ماوس را روی آن نگه داشتهاید محاسبه میشود.
توجه داشته باشید که برای مشاهده درصد کاربران فعال، باید حداقل دو نسخه منتشر کرده باشید که الزامات شرح داده شده در سوالات متداول «کدام نسخهها را میتوان در داشبورد نظارت بر انتشار مشاهده کرد؟» را برآورده کنند .
درصد کاربران فعال بر اساس دادههای دریافتی از جلسات محاسبه میشود، نه بر اساس دادههای دیگر (مانند دادههای Google Play یا گزارشهای خرابی).
اگر این اولین باری است که برنامه خود را با نسخه سازگار Crashlytics SDK منتشر میکنید، Crashlytics هیچ دادهای از جلسات قبلی برای مقایسه ندارد.
تنظیم هشدارها
چندین محصول Firebase، از جمله Crashlytics ، میتوانند به دلایل مختلف مربوط به محصول، هشدار ارسال کنند. برای دریافت هشدارها ، باید مجوزهای لازم را داشته باشید.
برای نظارت بر پایداری آخرین نسخه خود، میتوانید هشدارهایی را هم از Performance Monitoring و هم Crashlytics تنظیم کنید. به طور خاص برای Crashlytics ، میتوانید هشدارهای زیر را تنظیم کنید:
از هشدارهای سرعت استفاده کنید تا در صورت عبور هر مشکل خاص در برنامهتان از آستانهای که در کنسول Firebase تعریف کردهاید، به تیم خود اطلاع دهید.
هشدارهای مربوط به مشکلات جدید یا رفعشده را به کانال اعلان دلخواه خود ارسال کنید:
از یکپارچهسازیهای هشدار پیکربندیشده توسط Firebase-console برای Slack ، Jira و PagerDuty استفاده کنید.
با استفاده Cloud Functions for Firebase ، هشدار پیشرفته برای سرویسهای شخص ثالث تنظیم کنید.
قبل از رهاسازی، از رهاسازی روان آن اطمینان حاصل کنید
قبل از انتشار آخرین نسخه، استفاده از برخی از سرویسها و ویژگیهای زیر را برای اطمینان از انتشار روان در نظر بگیرید.
از سرویسهای تست قبل از انتشار استفاده کنید
فایربیس دو محصول ارائه میدهد که میتوانند به آزمایش قبل از انتشار کمک کنند: Test Lab و App Distribution . هر دوی این سرویسها میتوانند در جریانهای CI/CD شما ادغام شوند.
Firebase Test Lab یک زیرساخت تست اپلیکیشن مبتنی بر ابر است که به شما امکان میدهد اپلیکیشن خود را روی طیف وسیعی از دستگاهها و پیکربندیها آزمایش کنید، بنابراین میتوانید درک اولیهای از نحوه عملکرد آن در دست کاربران واقعی داشته باشید.
و وقتی آماده شدید که آخرین نسخه ساخته شده خود را به دست آزمایشکنندگان انسانی مورد اعتماد بسپارید، از Firebase App Distribution استفاده کنید. میتوانید توزیعهای پیشانتشار پلتفرم اپل و اندروید خود را از یک جا مدیریت کنید.
از سرویسهای آزمایشی گسترده و محدود استفاده کنید
از Firebase Remote Config برای راهاندازی ویژگیهای جدید با مکانیزم انتشار درصدی یا آزمایش آن ویژگیها در یک گروه آزمایشی محدود استفاده کنید.
فایربیس همچنین A/B Testing ارائه میدهد تا بتوانید تغییرات در رابط کاربری، ویژگیها یا کمپینهای تعامل برنامه خود را آزمایش کنید تا ببینید که چگونه بر معیارهای کلیدی شما (مانند درآمد و حفظ مشتری) تأثیر میگذارند، قبل از اینکه آنها را به طور گسترده اعمال کنید.
،ارائه نسخه جدید اپلیکیشن موبایل به مرحله تولید، یکی از هیجانانگیزترین بخشهای توسعه اپلیکیشن است، اما میتواند یکی از استرسزاترین آنها نیز باشد! تیم شما باید میزان جذب نسخه، اشکالات جدید و تأثیر این اشکالات، مقایسه با نسخههای قبلی و موارد دیگر را پیگیری کند.
این صفحه چندین ابزار ارائه شده توسط Firebase را برای نظارت بر دادههایی که برای اطمینان از انتشار برنامه تلفن همراه خود نیاز دارید، شرح میدهد.
از داشبورد نظارت بر انتشار برای بررسی دادههای مربوط به انتشار خود استفاده کنید
داشبورد نظارت بر انتشار در کنسول Firebase توسط Firebase Crashlytics پشتیبانی میشود. این یک داشبورد واحد برای نظارت بر جدیدترین نسخه تولیدی شماست. این داشبورد تقریباً به صورت بلادرنگ بهروزرسانی میشود و به شما یک نمای سطح بالا از مهمترین معیارهای انتشار، از جمله معیارهای بدون خرابی، میزان جذب نسخه، مقایسه با نسخههای قبلی و هرگونه مشکل جدید برای انتشار، ارائه میدهد.
این داشبورد جدید، صفحه «آخرین نسخه» در کنسول را بهبود میبخشد. در مقایسه با آن صفحه، داشبورد «نظارت بر انتشار» اطلاعات بیشتری اضافه میکند، دادههای مفیدی را بدون نیاز به گوگل آنالیتیکس نمایش میدهد و سریعتر بارگذاری میشود.
ویژگیهای داشبورد
گزارشدهی بلادرنگ
تمام نمودارها تقریباً به صورت آنی بهروزرسانی میشوند. کمی پس از استقرار آخرین نسخه، میتوانید شاهد شروع تعامل کاربران با آن نسخه باشید. اگر برخی از این کاربران دچار خرابی شوند، فوراً از طریق نمودارهای معیارهای بدون خرابی ، تأثیر آن را خواهید دید.مقایسه و بنچمارک بر اساس نسخههای قبلی
شما میتوانید پایداری آخرین نسخه خود را در مقایسه با نسخههای قبلی مشاهده کنید. داشبورد به شما امکان میدهد معیارهای زنده آخرین نسخه و حداکثر دو نسخه از نسخههای قبلی خود را مقایسه کنید.شمارههای جدید برتر
شما میتوانید خرابیهای جدید آخرین نسخه خود را به محض رسیدن مشاهده کنید. در جدول «مشکلات جدید برتر» ، میتوانید تأثیر مشکلاتی را که برای اولین بار در آخرین نسخه شما شناسایی شدهاند، رصد کنید و به شما این امکان را میدهد که به سرعت در مورد توقف یا بازگرداندن نسخه به نسخه قبلی تصمیم بگیرید.
الزامات مربوط به داشبورد
برای مشاهده آخرین نسخه خود در داشبورد نظارت بر انتشار ، موارد زیر را انجام دهید:
مطمئن شوید که برنامه شما حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+نسخه جدیدی از برنامه را در محیط عملیاتی منتشر کنید تا تعداد کافی از کاربران با آخرین نسخه شما تعامل داشته باشند.
سوالات متداول در مورد داشبورد
برای اینکه یک نسخه در داشبورد ظاهر شود، باید حداقل از نسخههای زیر از Crashlytics SDK استفاده کند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+
توجه داشته باشید که این نسخههای SDK اغلب به عنوان نسخههای SDK با قابلیت session شناخته میشوند، زیرا قادر به ارسال دادههای session به Crashlytics هستند که برای بسیاری از ویژگیهای جدید Crashlytics ، مانند داشبورد Release Monitoring ، مورد نیاز است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
داشبورد نظارت بر انتشار، با هدف کمک به شما در انتشار نسخههای عملیاتی، یعنی نسخههایی که تعداد قابل توجهی کاربر دارند، طراحی شده است.
برای اینکه یک ساختار در داشبورد ظاهر شود، باید تمام شرایط زیر را داشته باشد:
این نسخه حداقل از نسخههای زیر از Crashlytics SDK استفاده میکند:
پلتفرمهای اپل: نسخه ۱۰.۸.۰+ | اندروید: نسخه ۱۸.۶.۰+ ( BoM نسخه ۳۲.۶.۰+) | فلاتر: نسخه ۳.۴.۵+ | یونیتی: ۱۱.۷.۰+این نسخه در ۳ روز گذشته تعداد کافی کاربر داشته است:
این ساخت باید حداقل ۵۰۰ کاربر منحصر به فرد داشته باشد یا
این ساخت حداقل ۱٪ از کل کاربران را دارد و حداقل ۲ کاربر منحصر به فرد دارد.
(For apps distributed through Google Play ) If an app has a Google Play link , the dashboard shows all the builds listed in the Play Prod track, even if Crashlytics hasn't received any sessions logs or detected active users for that build.
Note that to view data in the dashboard for comparisons or active users percentage, you need to have released at least two builds that meet the preceding requirements.
First, it's helpful to understand some of the terminology involved with the Active users chart:
A session is a continuous period of time when a user is engaged with an application. A new session starts when the app is cold-started or the app is foregrounded after at least 30 minutes of backgrounding.
Active users for a specific build are the number of users who started a session using that build, grouped by hour.
Total (active) users are the number of users who started a session in any build of the app that uses a sessions-capable SDK version , grouped by hour.
In the Active users chart, the percentage value and count of active users that are always displayed on the chart are from the last 60 minutes (or if there haven't been any active users in the past 60 minutes, the past hour period that did have data). For example, in the example screenshot, there were 90 active users for the 6.0.0 (600) build in the past 60 minutes, which accounts for 22.1% of the total (active) users for the app.
When you hold the mouse over the lines in the Active users chart, the active user percentage is calculated from the active users count from the hour period you're hovering over.
Note that to see the active users percentage, you need to have released at least two builds that meet the requirements described in the FAQ "Which builds can be viewed on the Release Monitoring dashboard?" .
The active users percentage is based on received session data not on any other data (like Google Play data or crash reports).
If this is the first time that you've released your app with a compatible Crashlytics SDK version , then Crashlytics has no previous session data to compare against.
تنظیم هشدارها
Several Firebase products, including Crashlytics , can send alerts for various product-specific reasons. In order to receive alerts , you must have the required permissions.
To monitor the stability of your latest release, you can set up alerts from both Performance Monitoring and Crashlytics . For Crashlytics specifically, you can set up the following alerts:
Use velocity alerts to notify your team if any individual issue in your app crosses a threshold that you define in the Firebase console.
Send alerts about new or regressed issues to your preferred notification channel:
Use the Firebase-console configured alert integrations for Slack , Jira , and PagerDuty .
Set up advanced alerting to third-party services using Cloud Functions for Firebase .
Ensure a smooth release before you release
Before you release your latest version, consider using some of the following services and features to help ensure a smooth release.
Use pre-release testing services
Firebase offers two products that can help with pre-release testing: Test Lab and App Distribution . Both these services can be integrated into your CI/CD flows.
Firebase Test Lab is a cloud-based app testing infrastructure that lets you test your app on a range of devices and configurations, so you can get an early understanding of how it will perform in the hands of live users.
And when you're ready to put your latest build in the hands of trusted human testers, use Firebase App Distribution . You can manage both your Apple platform and Android pre-release distributions from the same place.
Use roll out and limited testing services
Use Firebase Remote Config to launch new features with a percentage rollout mechanism or test those features on a limited testing group .
Firebase also offers A/B Testing so that you can test changes to your app's UI, features, or engagement campaigns to see how they impact your key metrics (like revenue and retention) before you roll them out widely.