Features and major changes
We’ve made two changes to how we calculate Lead time for changes to better represent changesets between deployment git tags and non-deployment git tags, and git tags in multiple branches. This is a one-time change and may result in your Lead time for changes metric changing.
First, in situations where you have git tags on multiple branches and want Flow to count all the tags toward your deployment metrics in Flow, we’ve updated our calculations to avoid double-counting duplicate commits. This will have the result of reducing the total number of commits counting toward Lead time for changes.
Second, in situations where you’ve excluded git tags from counting toward deployments in Flow, we’ve updated our calculations to include all commits from excluded deployments so they count toward the next deployment in the repo. This will increase the number of commits counting toward deployments and increasing the Lead time for changes for deployments in this situation.
The exact change you can expect to see in your Lead time for changes metric depends on what workflows and tagging structures you use in your organization.
Where do I start? There’s no action needed from you here. Just be aware that historical Lead time for changes data will change. These changes to your metric are intentional and should provide you with a more accurate Lead time for changes value going forward.
If you need help, please contact Pluralsight Support.