All Collections
Athenian Training
Get started on Velocity!
Release Time
Release Time

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

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

Release is the last activity in the merge sequence. The Release Time is the time it takes for an item to progress from the moment it’s merged until it’s released.

Release Time = Release Event - Merge Done

Release Event = Merge to Branch, or Tag Created, or API Call

You can configure this setting to meet your own standards of what counts as a “release” for an item. With the default setting, Athenian will automatically try and identify any released items. But you can configure release events to include specific tags, branches, or events.

How to use Athenian to improve the release process

Release Dashboard

The main release dashboard shows you the distribution of Pull Request Cycle Times, and a timeline showing how the amount of time your teams have spent on to release Pull Requests 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 on releasing in your chosen date range.

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

  • The number of Pull Requests released in your chosen date range, plus the number of repositories where releases were made.

Release Time Metrics and Insights

Scroll down and you can see the following insights:

  • Number of releases over time for your chosen date range, an average release frequency figure, and the day of the week with the highest average release frequency.

  • Distribution of releases pre repository. This includes a count of the repositories that are releasing on a daily basis, and the repository with the highest release frequency.

  • The total number of Pull Requests that are currently waiting to release, broken down by their respective repositories.

  • The risk of the releases, Release Size Distribution, in terms of the number of Pull Requests vs size of the Pull Requests.

  • You can filter the Pull Request data to see where items stand. Which items have been released, items that were never released, and items that are currently waiting for release.

🔎 What you to look for?

  • Do you have multiple Pull Requests waiting to be released?

  • Why are we releasing so many Pull Requests at the same time? What’s the risk of doing that versus releasing smaller units?

  • Which repositories have the biggest Release Time?

  • What is blocking us from releasing more times per day?

  • Are similar components taking different times to release? Why is that?

  • Remember to think about context, and about how your developers interact with your systems. So check which day of the week has the highest average release frequency, and think about what might be contributing to this.

🚀 Actions to improve

  • Filter the Pull Request data to what items are currently waiting for release. Check why they cannot be released.

  • Automate the release process – try to ensure Pull Requests can be released in an autonomous manner.

  • Feature flag – ensure code is delivered even if the feature is not ready, by hiding it under a flag or another architectural pattern.

  • Optimize tests – improve the efficiency of the test process. Cross reference your release time with other testing activities or validations your team needs to perform.

  • Break down components – ensure you have smaller releasable units. Not only will this help you streamline the release process, it can also help you minimize risk.

Did this answer your question?