Spectra —A Portal for developer productivity metrics and feedback

Dinesh C
Dinesh C
Feb 7 · 3 min read

The background

As mobile teams scale, there are couple of challenges that come in the way. Some of those are

  1. Huge number of merge requests
  2. Lots of code reviews
  3. Umpteen number of code review comments
  4. Build breakages
  5. Performance impact in terms of memory,app size
  6. Different team dynamics and velocities
  7. Feedback to developers in a timely manner

Why we needed this?

  1. Developers need constant feedback in terms of their tech metrics. It would help developers to keep track of their tech metrices over a period of time and do a self evaluation of how their tech metrics have fared over time.
  2. Tech teams need to know bottle necks and read areas for them to optimize processess and tools

Ex: There are some metrices that would give meaningful feedback to developers and help them improve over time

  1. The number of lint errors/warnings recorded in the code submitted by a developer
  2. The number of build failures caused
  3. The quality of commit messages
  4. The adhearance to design quality and standards
  5. The size of images used

What we desired?

We wanted to have an open portal where developers or any one can look at team/individual metrics. The portal would have various graphs which would give feedback on how different metrics have fared over time.

How we built the portal?

The data : To build a portal, we needed the data on different metrics

The Source of data : CI System. CI pipelines is where all the information originates.

  1. Gitlab runners
  2. Jenkins
  3. Python scripts → Any validation scripts were written on Python.

Ex : We wanted to have a way to check if a merge request was certified by QA, Product Teams and Design Teams. JIRA had all this information. So we wrote a python script which can contact the JIRA system and check all the above statuses and trigger certain signals

The above 3 formed the power lifters who would power the entire system.

Example of data sources : The CI system would know all about

  1. Build failures → Success or failure
  2. Lint results → How many errors and how many warnings
  3. Static code analysis tool results
  4. Qulity of commit messages

The data storage: All the signals generated in the CI pipelines viz, build success, build failures, the stage in which a failure happened, the commit message quality, the lint results, the number of tests that passed and failed, would be sent to a data store. In our case Elastic.

The portal/dashboard: ELK Stack

Why elastic?

In addition to having a NoSQL data store, ELK stack provides dashboarding in the form of Kibana. All basic dashboarding charts like Pie, Graphs, Meters are pretty much out of the box.

Spectra System data flow

Once data is ingested into elastic and indexed, we could easily mix match indices and create delightful dashboards.

A simple dasboard for build failures and the causes looks like this

Conclusion :

Spectra has started proving its mettle by giving some measurable insights.

As teams scale, tracking metrices would help in identifying bottle necks and help in optimizing dev processess

Co authored by Ayush

Designs by Abhi

Image credit : Photo by Carlos Muza on Unsplash

redBus India Blog

    Dinesh C

    Written by

    Dinesh C

    redbus India Blog
    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade