All Collections
Athenian Training
Get started on Velocity!
Merge Time and Continuous Integration
Merge Time and Continuous Integration

How to discover bottlenecks in the merge process and how to turn that into something actionable

José Caldeira avatar
Written by José Caldeira
Updated over a week ago

Merge is the time between an item’s final approved review and the first merger activity – that is, whenever someone presses the “merge” button on a Pull Request.

Merge Time = Merge Action - Last Approval Time

How to use Athenian to improve the merge process

Merge Dashboard

The main merge dashboard shows you the distribution of Pull Request Cycle Times and a timeline showing how the amount of time your teams have spent on merging has changed across your chosen date range.

You’ll be able to see, at a glance:

  • The overall amount of time your team has spent to merge Pull Requests in your chosen date range;

  • The total proportion of your Pull Request Cycle Time taken up by teams working to merge Pull Requests;

  • The number of Pull Requests merged in your chosen date range, plus the number of mergers and repositories shown in the data;

Scroll down and you’ll see how each of your repositories is influencing the overall merge time.

If your merge time is increasing you probably want to check your test processes, looking at either manual or automatic tests.

Continuous Integration

The Continuous Integration (CI) section of the Athenian dashboard lets you view the overall runtime of your test-suite, plus the number of times it’s run across your chosen time period.

The Success Ratio metric tells you the number of successes and failures you had for each test.

Drilling down, you can see your test suite’s average run time per Pull Request, and the run time per repository. This will tell you which of your repositories required the most time to go through the test suite process.

You can also view the GitHub Checks data to see the underlying data that Athenian uses to generate its dashboards, similar to what we do with Pull Requests.

🔎 What you to look for?

  • How many items are currently in the merge process? You should aim to make this number as low as possible, as too many items in the merge queue can have a snowball effect due to possible code dependencies or conflicts.

  • Are tests blocking the merge process? Cross reference the merge insights with the data from the CI section.

  • Is the CI system slow? Why is that? Check which repositories are undergoing the most tests, to give you an idea of where to look for improvement.

  • Are you running too many tests? And has the test failure rate increased or decreased?

  • Are you missing automations or running manual activities before merge?

  • Are your teams afraid of merging because release is fully automated? Cross reference the Merge insights with the Release insights. As you optimize the Release process, it may make your teams increasingly wary of releasing their Pull Requests, as anything they release will automatically move to production.

🚀 Actions to improve

  • Merge Pull Requests as soon as you have them ready to be merged, minimizing the risk of future conflicts.

  • Optimize tests – improve the efficiency of the test process and reduce flakiness.

  • Break down components – ensure you have smaller merging units.

  • If you cannot spot a pattern between the merge time and Continuous Integration, then it might indicate that some of your developers are simply wary of merging, as they’re not yet confident with the code. Discuss this with your team – they may be performing manual code reviews before they feel confident in releasing the code.

  • There may be opportunities to automate more of the merge process, to ensure your developers can merge with less manual effort, thus decreasing risk.

Did this answer your question?