Measuring GitLab activity, community and performance with GrimoireLab

Software development analytics plays an important role in decision making for many data-driven firms. Being able to provide support for a wide range of different data sources to measure any project (so you can aggregate more than just one type of data) and manage different identities and affiliations among several data sources, is something we believe that can lead to a better understanding of the project as a whole.

Our services keep improving, and from now on, GrimoireLab and Bitergia begin to support GitLab (we also track 30 more data sources ). For those who are not aware of, GitLab is a Git repository manager who offers continuous integration process, issue tracking and wiki. At this moment, GrimoireLab analyzes merge requests (review process), issues and commits (Git repositories). We’re planing to support wiki and continuous integration as well in the near future.

In this post, we will see the different metrics we can obtain when analyzing GitLab infrastructure in terms of activity, community and performance, and what kind of questions we solve with these metrics.

Measuring GitLab activity and community

Main metrics that can be measured in terms of activity and community within a project are related with questions such as:

  • How much code, tests, communication or reviews does my project have?
  • When is the project getting more activity? Identify patterns, time zones and trends
  • Where is this activity? Filter activity by module company, etc
  • How many developers are participating in the project? Filter authors by company or organization, role, experience
  • How important are each of my developers? Identify the core, regular and casual developers (funnel approach)

As we already mentioned, GrimoireLab is able to generate metrics that answer these questions based on merge requests, issues and commits analysis. The following are some examples.

Total GitLab issues, submitters and authors over a period of time

We can do the same with total GitLab Merge requests. Moreover, we can even go one step further, and filter the number of issues and merges that comes from a specific organization to easily visualize how much does each organization contribute to a project.

GitLab Issues basic stats from gitlab.biterg.io
GitLab Issues basic stats about GitLab EE project from gitlab.biterg.io

Number of core, casual and regular developers over a period of time

This allows us to see the level of engagement each community member has within the project.

gitlab issues (core, casual and regular developers)
Number of core, casual and regular developers per quarter within a community

How do we identify our core, casual and regular developers? At Bitergia, we define core developers as those who have done 80% of the contributions for a certain period of time, regular as those who have done a 15% and casual developers as those who have done just a 5%. We call it the onion model.

How developers interact in the community

By analyzing how many authors interact with different repositories thanks to the network analysis visualization:

gitLab in grimoirelab
Network analysis visualization: Dots represent the different authors and blue boxes the different repositories in which authors contribute over a period of time. Dot size is the amount of activity authors are making

Measuring performance on GitLab

Bitergia can answer questions in terms of performance such as:

  • How long is it taking to fix bugs or attend to new contributions?
  • Does my project have bottlenecks? Where?

By analyzing the median time open of merge request and issues, we can know the estimated time to close merge request and issues over a period of time.

Efficiency closing GitLab issues charts
Efficiency closing GitLab issues charts

Not only that, we can also filter by organization (Let’s say the company, foundation or organization you’re member of) and see how long does it take external contributors from other companies to close merge requests and/or issues  and see if there is a difference between the external authors and my company’s authors.

dot&dot visualization
Median time open issues (X-axis) and number of open issues (Y- axis) filtered by organizations. Dot size shows the amount of authors within each organization

How to analyze projects hosted on GitLab

Basically the procedure is quite similar to analyzing projects hosted in GitHub. You need to add projects resources links in the projects.json file and some parameters like your GitLab API token in the setup.cfg. If you need more info about these files, you read the SirMordred section in the GrimoireLab tutorial.

But, what about those projects hosted in dedicated GitLab instances? For example, GNOME is hosting their projects in gitlab.gnome.org.

Let’s say we want to analyze git, GitLab issues and merge requests, and mailing lists activity, community and processes for Nautilus, GIMP and gnome-shell projects. The projects.json file looks like this:


{
    "Nautilus": {
        "git": ["https://gitlab.gnome.org/GNOME/nautilus.git"],
        "gitlab:issue": ["https://gitlab.gnome.org/GNOME/nautilus"],
        "gitlab:merge": ["https://gitlab.gnome.org/GNOME/nautilus"],
        "pipermail":["https://mail.gnome.org/archives/nautilus-list/"]
    },
    "GIMP": {
        "git": ["https://gitlab.gnome.org/GNOME/gimp.git"],
        "gitlab:issue": ["https://gitlab.gnome.org/GNOME/gimp"],
        "gitlab:merge": ["https://gitlab.gnome.org/GNOME/gimp"],
        "pipermail": [
            "https://mail.gnome.org/archives/gimp-developer-list/",
            "https://mail.gnome.org/archives/gimp-docs-list/",
            "https://mail.gnome.org/archives/gimp-gui-list/",
            "https://mail.gnome.org/archives/gimp-user-list/",
            "https://mail.gnome.org/archives/gimp-web-list/"
        ]
    },
    "gnome-shell": {
        "git": ["https://gitlab.gnome.org/GNOME/gnome-shell.git"],
        "gitlab:issue": ["https://gitlab.gnome.org/GNOME/gnome-shell"],
        "gitlab:merge": ["https://gitlab.gnome.org/GNOME/gnome-shell"],
        "pipermail": ["https://mail.gnome.org/archives/gnome-shell-list/"]
    }
}

And the relevant sections in the setup.cfg looks like this:


[gitlab:issue]
api-token = ********************
raw_index = gitlab_issues_demo_raw
enriched_index = gitlab_issues_demo_enriched
no-archive = true
enterprise-url = https://gitlab.gnome.org
sleep-for-rate = true

[gitlab:merge]
api-token = *********************
raw_index = gitlab_merges_demo_raw
enriched_index = gitlab_merges_demo_enriched
no-archive = true
enterprise-url = https://gitlab.gnome.org
category = merge_request
sleep-for-rate = true

As you can see, the enterprise-url parameter is the one used to set up the access to the GitLab instance, as it’s done for GitHub Enterprise when using GrimoireLab to analyze projects hosted in the dedicated GitHub Enterprise instance.

Last but not least…

What do you think about this way to measure GitLab? Do you find useful to track activity, community and performance within projects in software development? Leave us a comment below or contact us if you want to know more about Bitergia services!

Leave a Reply

Powered by WordPress.com.

Up ↑

%d bloggers like this: