Grab می‌گوید استفاده گسترده‌تر از دستیارهای کدنویسی AI، سرعت توسعه و حجم تغییرات هر انتشار را افزایش داده و فرصت بیشتری برای بروز خطا و crash ایجاد کرده است. پاسخ این شرکت، دفاعی چندلایه برای پیشگیری، شناسایی و مهار crash در مراحل توسعه و انتشار app موبایل است.
در مقیاس Grab، هر هفته تعداد زیادی merge request از تیم‌های مختلف وارد می‌شود. بسیاری از قابلیت‌ها نیز پشت feature flag قرار دارند و مستقل از انتشار نسخه فعال می‌شوند. به گفته این شرکت، crash علاوه بر آسیب به تجربه کاربر و کاهش نرخ sessionهای بدون crash، بر رتبه app در Google Play اثر می‌گذارد. همچنین چون همه کاربران به‌روزرسانی خودکار را فعال نمی‌کنند، نسخه دارای crash ممکن است مدت بیشتری روی دستگاه بماند.
لایه نخست بر رویکرد Shift Left تکیه دارد: پیدا کردن مشکل در زودترین مرحله ممکن. پیش از merge و ورود به production، تیم‌ها از Android Lint و SwiftLint با ruleهای مخصوص پلتفرم، جامعه توسعه‌دهندگان و ruleهای سفارشی استفاده می‌کنند. unit test، UI test و بررسی‌های دستی QA نیز بخشی از این مرحله‌اند. در Grab Early Access یا GEA، buildهای اولیه بین کاربران داخلی توزیع و از نظر crash پایش می‌شوند. Grab تأکید می‌کند مشکلی که فقط چند کاربر داخلی می‌بینند، در مقیاس production می‌تواند به جهش نرخ crash و حتی نیاز به اصلاح فوری منجر شود.
هنگام انتشار، staged rollout نسخه جدید را ابتدا فقط به درصد کوچکی از کاربران می‌رساند. اگر نرخ غیرعادی crash دیده شود، تیم می‌تواند ادامه انتشار را متوقف کند. feature flag نیز امکان فعال‌سازی تدریجی قابلیت‌ها را فراهم می‌کند؛ اگر نرخ crash از آستانه تعیین‌شده عبور کند، قابلیت بدون انتشار نسخه تازه غیرفعال می‌شود.
پس از انتشار، Firebase Crashlytics و BigQuery برای پایش لحظه‌ای و شناسایی وضعیت غیرعادی به کار می‌روند. دسته‌بندی خودکار و اطلاعات تشخیصی تکمیلی، metadata و stack trace مربوط به crash را گردآوری می‌کنند تا تیم‌ها مشکل را به PR مشخص مرتبط کنند. در نهایت، بازخوردها و تحلیل پس از رخداد برای گسترش lint ruleها و پوشش test به مراحل پیشین برمی‌گردند.
