Accelerate with Gerrit DevOps Analytics

Accelerating your time to market while delivering high-quality products is vital for any company of any size. This fast pacing and always evolving world relies on getting quicker and better in building the production pipeline of products. The whole DevOps and Lean methodologies help to achieve the speed and quality needed by continuously improving the process in a so-called feedback loop. The faster the cycle, the quicker is the ability to achieve competitive advantages to outperform and beat the competition.

It is fundamental to have a scientific approach and put metrics in place to measure and monitor the progress of the different actors in the whole software lifecycle and delivery pipeline.

We need data to build metrics to design our continuous improvement lifecycle around it. We need to juice information from all the components we use, directly or indirectly, on a daily basis:

– SCM: how many commits are going through the pipeline?

– Code Review: what’s the lead time for a piece of code to get validated?  How are people interacting around the code?

– Issue tracker: how long does it take the end-to-end lifecycle outside the development, from idea to production?

– … and many more

To anticipate delays in deliveries and make changes in the organization to accelerate the teams’ productivity is fundamental getting logs from these sources and understanding what they are telling us. That is not an easy task.

It becomes important for everybody involved in the software lifecycle (Engineers, Project Managers, Head of Engineering), to have an easy way to measure meaningful KPIs.

What is Gerrit?

Gerrit is an OpenSource code review tool, built on top of the Git version control system.

What is Gerrit DevOps Analytics (GDA)

Gerrit DevOps Analytics (aka GDA) is an OpenSource solution for collecting data, aggregating them based on different dimensions and expose meaningful metrics in a timely fashion.

GDA is part of the Gerrit Code Review ecosystem and has been presented during the last Gerrit User Summit 2018 at Cloudera HQ in Palo Alto. However, GDA is not limited to Gerrit and is aiming at integrating and processing any information coming from other version control and code-review systems, including GitLab, GitHub and BitBucket.

Case study: GDA applied to the Gerrit Code Review project

One of the golden rules of Lean and DevOps is continuous improvement: “eating your dog food” is the perfect way to measure the progress of the solution by using its outcome in our daily life of developing GDA.

GDA is part of Gerrit Code Review ecosystem, which I have been contributing to during all this time.

Gerrit is not just the code review tool itself, but also its plugins ecosystem, hence you need to include them as well into any collection and processing of analytics data.

Let’s take some trivial examples of KPIs we can measure with GDA for different roles normally involved in a Software delivery team.

Scenario 1: Release Manager

Question: How can I measure the risk of my release?

Let’s see which metrics are provided by GDA:

We can see some interesting numbers which might help us:

• Number of commits for a given release
• Number of repositories involved in a Gerrit version (i.e., a project has to be evaluated by its core code, but also by its ecosystem of plugins )
• Average number of changes per commit

All these metrics can be used to define the risk of a release, hence define some KPIs to monitor in real-time.

Scenario 2: Delivery Manager

Question: How can I measure the collaboration/contribution in my team?

There are a couple of graphs that might be of interest in that regard. The first graph (Commits per author) represents the number of Commits per author over a period of time (As a side note, see the “Other” slice in the below graph? It is interestingly telling us that the major contributor to Gerrit Code Review is…the community!).

The second one (Collaboration graph) represents the interaction among the teammates:

• Each dot is a contributor
• The size of the dot is the number of contributions (i.e.: review comments, votes, etc)
• The links represent an interaction between 2 contributors
• The link size represents the number of contributions between 2 contributors

What you want to avoid is a low bus-factor. Trying to have a uniform distribution of the commits in the Commits per author graph and a well-connected Collaboration graph is what you are aiming to as Delivery Manager.

One of the key concepts of Lean and Agile is allowing self-organizing Teams; and there is no better way than visualize the effective collaboration that exists between people and encourages a natural formation of tribes and squads of highly cooperative individuals, rather than top-down hierarchical structures.

Scenary 3: System engineer

Question: can I improve the usage of my resources?

If you are responsible for keeping the system up-and-running and respect SLAs, you need to know *in advance* that something isn’t working or somebody or some project starts overutilizing your resources.

The traditional “top-down enterprise” with a command-and-control paradigm would resolve the problem by setting quotas and a strict bureaucracy and governance in place: that would have a catastrophic effect of slowing down the ability of the entire organization to deliver.

A Lean organization, instead, would allow the people to choose the tools they make productive as much as they need. GDA can then extract the system utilization metrics and give to the system engineer the insights to keep the system healthy, prevent rather than solve problems and design the horizontal and vertical scalability growth that keep your Teams always producing. I wrote a blog post about what you can find out, for example, looking at metrics like Human Vs Bot and SSH Vs HTTP traffic:

DO try this at home

The above graphs were just some examples of how GDA can be beneficial for any role in the company. As mentioned at the beginning the data I used is coming from the Gerrit Code Review OpenSource project.

Talk is cheap, show me the code!

The code to build the analytics is OpenSource as the whole stack we used. Because of the setups of all components can be tricky, I have also worked to build a wizard you can use if you want to try a vanilla version of the dashboards on your projects.

Don’t believe it? Try it yourself.

No more excuses to delay the future: jump on GDA and start accelerating now to become a top-performer!