Possibility to calculate DORA metric Lead time for change - Mendix Forum

Possibility to calculate DORA metric Lead time for change

7

Hi.

 

we are looking into the DORA metrics, to see if we can use them to monitor our development performance.

 

First metric is Lead time for change. In short it's the time between when a change is committed and when it's deployed to production.

 

The easy part is knowing when something is committed, because you can easily lookup all the commit messages using the App repository API.

The difficult part is to know what changes are in the version of the app that is deployed. If all changes where committed in the main line it's still possible to do so, just by checking the revision of the deployment package and checking wich revisions where made prior to that revision.

Often though changes are done in branches, and we cannot figure out how to check if a branch is merged into deployed branch.

 

Therefore i would like to suggest, that it is possible that all revisions are visible for a given branch. So not only revisions that are done in that branch, but also revisions that are merged from other branches.

 

Another option could be, that the repository api would show when a branch was merged.

asked
3 answers

Hi Tom, 

 

To clarify, we want to be able to track a commit via an API so we can determine whether a commit is included in the specific package deployed on an environment. We want to calculate and display the LTC in our own tooling for over 120 apps.

 

Imagine a repository with 10 commits. the main branch and two side branches contribute to these 10 commits as follows:

  1. commit 1: initial commit on the main branch.
  2. commit 2: a regular commit on the main branch.

now, from commit 2, two branches are created:

  • the feature branch has: a. commit 3: a change made on the feature branch. b. commit 4: another change on the feature branch.

  • the bugfix branch has: a. commit 5: a change made on the bugfix branch. b. commit 6: another change on the bugfix branch.

back on the main branch, the branches are merged:

  1. commit 7: a merge commit where the feature branch (with commits 3 and 4) is merged into main.
  2. commit 8: a merge commit where the bugfix branch (with commits 5 and 6) is merged into main.

finally, further changes are made on main:

  1. commit 9: a new commit on the main branch (this is the commit deployed to production).
  2. commit 10: an additional commit on main (not deployed yet).

In production, only commits up to commit 9 are deployed. although commit 9 is directly visible on the main branch, the changes from commits 3, 4, 5, and 6 are bundled inside merge commits 7 and 8. if the repository api only returns the main branch’s direct commit list (commits 1, 2, 7, 8, 9, and 10), it becomes difficult to determine if a specific commit from a side branch—say, commit 4—is included in the production deployment at commit 9.

the proposed solution is to enhance the api so that it:

  • shows all revisions for a given branch (including commits from merged branches)
  • indicates when and from which branch a merge occurred

this additional detail would allow teams to trace a commit (for example, commit 4 on the feature branch) through its merge into the main branch and confirm that it is indeed part of the package deployed on production (commit 9).

Created

Can you clarify what you mean with Visibility of All Revisions in a Branch?

In Git you always see the history of all commits, regardless of whether they were merged or created directly on that branch. This is the case for the overview of commits in the Mendix Portal, as well as in Studio Pro and local 3rd party tooling. I have not checked this yet with the repository API.

Created

To further clarify the idea.

 

Problem

To effectively calculate the Lead Time for Change (LTC)—a key DORA metric that measures the time between when a change is committed and when it is deployed to production—developers need to identify whether specific commits are included in a deployment package. While it's straightforward to identify commits in the main branch using the App Repository API, tracking commits from branches that have been merged into the main branch poses a significant challenge. Currently, the api does not include version control history, making it difficult to determine if a specific commit is part of the deployed version.

 

Proposed Solution:

To address these challenges, we propose the following enhancements to the Mendix App Repository API:

  1. Visibility of All Revisions in a Branch:

    • Extend the repository API to show all revisions for a given branch, including revisions that originated in other branches but were merged into the target branch. This would provide a complete history of changes in the branch, making it easier to track merged commits.

  2. Branch Merge Tracking:

    • Add functionality to the repository API to indicate when a branch was merged into another branch. This metadata would allow teams to trace which commits were introduced into the main branch via merged branches and whether they are included in the deployed version.

Use Cases:

  1. Lead Time for Change Calculation:

    • We want to be able to determine the lead time for change an API, as we want to calculate and display the metric in our own tooling.

  2. Audit and Traceability:

    • Ensure traceability of commits included in a deployment package for compliance or debugging purposes.

  3. Automated Reporting:

    • Simplify integration with DevOps tools by providing detailed deployment metadata for automated reporting and insights.

Expected Impact:

  • Improved DORA Metrics Tracking: Teams will have the necessary tools to monitor LTC accurately.

Request for Feedback:

This feature request aims to bridge the gap in tracking commits across branches and deployments via an API. We would appreciate feedback from the Mendix product team and community on the feasibility and potential implementation of these API enhancements.

Created