We will need to transform the data from Crashlytics into a similar form and store it in Tramline.
Figure out the query required to get this data. Make sure to filter by the correct version code and version name.
Fetch frequency can be lower than Bugsnag (every 30 minutes?).
Once the data is fetched and stored, the rest of the health rule application logic remains the same. So, all that is needed from this issue to fetch, transform and store the release health metrics data.
Crashlytics is special because there's not direct API to get this data. We expect a Firebase to be connected to the user's account and we would make calls to the BQ dataset instead. Link to sample BQ data exported to a spreadsheet.
Requirements
Write an API layer and integration layer for Crashlytics
Ensure the interfaces adhere to the common functions, see Bugsnag integration
Acceptance Criteria
UI change required only in connecting the integration, the rest should work seamlessly.
Hook up the APIs and integration layer
Unit tests & some API-mocked fixture-driven tests
Ensure things work as closely to Bugsnag. Test thoroughly manually.
Find an estimate of the costs associated with each query. This will help us tweak polling rate and help communicate the unprecedented costs (if any) to our users.
Additional Notes
Here's a sample BQ query that can be used as a starting point for all the other queries to be written:
SELECT
COUNT(DISTINCT event_id) AS number_of_crashes,
FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
`decoded-theme-355014.firebase_crashlytics.com_tramline_ueno_ANDROID_REALTIME`
GROUP BY
date_of_crashes
ORDER BY
date_of_crashes DESC
LIMIT 30;
Context
This is the current set of health metics data stored by Tramline:
We will need to transform the data from Crashlytics into a similar form and store it in Tramline.
Figure out the query required to get this data. Make sure to filter by the correct version code and version name.
Fetch frequency can be lower than Bugsnag (every 30 minutes?).
Once the data is fetched and stored, the rest of the health rule application logic remains the same. So, all that is needed from this issue to fetch, transform and store the release health metrics data.
Crashlytics is special because there's not direct API to get this data. We expect a Firebase to be connected to the user's account and we would make calls to the BQ dataset instead. Link to sample BQ data exported to a spreadsheet.
Requirements
Acceptance Criteria
Additional Notes
Here's a sample BQ query that can be used as a starting point for all the other queries to be written: