June 15, 2022

How to build the ideal dev team dashboard

Slack is great for communicating changes and events across a development team, but what’s missing is that ‘snapshot’ of the current state of play.

Sure, you can switch between tabs for Jira, GitHub, your CI/CD tool and monitoring tools, but a dashboard that brings this all together makes it much easier for the whole team to quickly get a shared understanding of what’s happening. A dashboard can also be used to share status outside of the team – with managers who may not have access to all of the underlying tools or don’t have the time to go digging.

In this blog we’ll take a look at how we can use the SquaredUp observability portal to build a dashboard showing the backlog, open PRs, CI/CD releases and application health, all in one place.

Here’s a quick look at the dashboard we'll build:

The team we’re building a dashboard for develops on AWS using Lambda and DynamoDB and deploys using Azure DevOps. They leverage GitHub for their code repo, JIRA for issue management, and AWS CloudWatch for monitoring.

Here’s what the team wants to show on the dashboard, and where that data comes from:

Backlog (JIRA)
Open PRs (GitHub)
Release pipelines to prod (Azure DevOps)
Application health (AWS CloudWatch)

SquaredUp has plugins for all of these data sources (and plenty more), which makes this dashboard easy to build without getting into any coding.

There are plugins that cover other CI/CD tools (AWS CodePipelines, CircleCI) and other monitoring tools (Azure Monitor, Prometheus, Datadog and so on) so it should be possible to build this dashboard for most dev teams—whatever tooling or stack is used.

Let’s get started. If you don’t already have SquaredUp, you can sign-up for a free account here.

A good way to start with building a dashboard is putting together a ‘mock-up’ dashboard that has all the right tiles in place, but no data. If you prefer to get stuck into the data and play around, that works too! It’s easy enough to rearrange the tiles once you start building.

Here’s the mock-up for our team dashboard:

This dashboard is created in a new SquaredUp ‘workspace’ for the dev team. Having a workspace makes it easy for the team to add other related dashboards and use the workspace-based access control to take ownership of their own dashboards, independently of other dashboards in SquaredUp.

At this point, we want to get real data plugged in and start filling in the blanks.

We won’t go through each tile and data source here (once you’ve done one, the rest are more or less the same). Let’s walk through the Jira plug-in—if you’re reading this, then there’s a good chance you use Jira.

First, we hit ‘configure’ on one of the tiles—if you've created the mock-up above, choose the "backlog" tile.

If you’re just getting started with SquaredUp, you may only have the Sample Data plugin configured, so we’ll need to add the Jira plugin. You only have to configure a plugin once to use it across all of your dashboards.

Click ‘Add plugin’, which opens the plugin browser. You can also get to this via Settings > Plugins.

When we choose Jira (under "Issue Tracking" in the plugins selector), we see the available data streams and the objects that are imported into the observability graph. More on this later.

Next up is the important bit – we need to configure the plugin with the details it needs to connect to the Jira API.

At this point, we need to hop over to our Jira account and get those details. Enter those on the previous Jira plugin config screen, and we’re done!

Now we can start using any data from our Jira account in our dashboard!

Typically, your Jira account will probably have a bunch of different projects and be used by multiple teams. The plugin makes it easy to find the right data by importing ‘objects’ from Jira into the SquaredUp graph (a database of objects and their relationships). We can now browse those objects directly in the tile editor to find the data we want. In SquaredUp, this is called a scope.

With the Jira plugin, the easiest way to scope our dashboard is to select one of the ‘Filters’ objects that the plugin has imported from Jira. These are the filters we have already configured in Jira that we use for our Kanban and backlog views.

Next, we choose the data we want to show. SquaredUp calls these "data streams" because the data is pulled directly from the data source when it’s needed, instead of copying it into a local database (a bit like TV streaming vs download).

Let’s choose ‘Issues / All (anytime)’. And that automatically defaults to a table view, which is what we wanted.

Click save and close—and that’s it, we're done with our Jira tile.

The other tiles work in the same way, except the plugin configuration, which differs slightly between tools. The AWS CloudWatch tiles are a bit more interesting because the data can be visualized in line graphs and other ways, but the process is much the same!

And here’s the finished dashboard. It looks just the same as the mock-up but with real data!

This dashboard is now a quick place for anyone on the dev team to go when they need to see what’s happening - from who’s working on what, to deploy into production and the health of the app.

Building this dashboard was simple and very effective, but in a way, it’s just the start of what you can do. Here are some ideas for other ways this can be used:

Slack integration to add links to this dashboard for routine team notifications. We can also set up alerting and rules on the dashboard to post to Slack when interesting things happen (unusual number of failed builds, open PR queue gets too long, etc.).
Sharing this dashboard with others in the organization - e.g. product managers and support teams. The best option might be to create a second, simpler, dashboard that’s external-facing, and keep this one specific to what the team needs to see.
More specific monitoring using AWS CloudWatch logs - e.g. configuring rules to watch for known log entries indicating problems.