Release Readiness Dashboard
Running with the Train
Simply put, the release readiness dashboard is an overview of various versions of Mozillian products Firefox, Fennec, and Firefox OS. It provides a trend (or current number) of the various kinds of bugs that the release management team cares about when determining whether or not a particular version is on track to be ready before the scheduled release date. The product versions appearing on the dashboard are displayed automatically by following the train model described in the rapid release calendar.
My first attempt to capture the train model in the dashboard’s database worked but was very inefficient and had serious redundancy issues. The following tables and fields are a part of the initial database schema:
- product – id, title
- version – id, title, product_id, central, aurora, beta, release, deprecate
For example, if the
version that is currently on central is wanted then
current timestamp is checked for being in between
version.aurora, which are both
timestamp data. Based on that logic, the scripts are able to automatically identify currently active versions.
However, this means an awful lot of timestamp comparisons and also a lot of the same dates being stored (in different coloumns of succeeding rows). How to better capture the train model so that the database is not storing redundant data?
After some brainstorming and discussions with both Bhavana and Lukas, a solution for a normalized data schema was found. See the above for the finalized solution in the form of an ER diagram.
On every reasonable period, a CRON job will be run. In the script, we check for a new train cycle by reading from an external data source. If a new cycle is found, it is insert as a new row in the
cycle table. Following that, new rows are made in the
version table for each product that will have a version entering the central channel. Now, the mapping begins. The newly created versions are mapped to the newly created cycle as being in the
central channel. Previous versions are also bumped up a channel and mapped to the newly created cycle. The rows in the
version_channel_cycle can be interpreted in English as the particular version that is in the particular channel for a particular cycle.
When retrieving data, this means that we only have to do
in between timestamp comparisons once in the
cycle table, then we get the
cycle.id which is used for the other database queries. Convenient. In terms of storing data, this also means inserting rows every time a new cycle is entered, as opposed to updating
version rows over and over again, which can get messy. The same dates are also stored only once now, so the redundancy is gone.
All things considered I’m quite happy with the new database schema. Big thanks to Lukas for pushing me to rethink my initial design and walking me through when I was lost.
Perhaps at some point in future I will write more about the other aspects of the database that deal with the storage and use of
queries. This project just keeps getting more awesome. Excited to see it go live.