Hey everyone! I’m trying to figure out how to track the change lead time for our projects. You know, that important DevOps metric that shows how long it takes from when we create a ticket to when the code actually hits production.
Here’s what I’m thinking:
We’d use a Jira plugin to catch when a ticket is created and send that info to our data storage.
We’d consider a feature done when its code makes it through our pipeline to production.
The tricky part is figuring out which commits are part of the latest push. I can see all the git history, but I’m not sure how to isolate just the new stuff.
Here’s a rough idea of the process:
def track_lead_time(jira_ticket, git_commits, jenkins_pipeline):
ticket_creation = jira_ticket.creation_date
production_deployment = None
for commit in git_commits:
if jira_ticket.id in commit.message:
if jenkins_pipeline.is_successful(commit):
production_deployment = jenkins_pipeline.prod_deploy_time
break
if production_deployment:
lead_time = production_deployment - ticket_creation
return lead_time
else:
return None
Any ideas on how to get those new commits? Or maybe a better way to approach this whole thing? Thanks!
Your approach to measuring change lead time is on the right track, but there are a few considerations to keep in mind. Instead of relying solely on commit messages for ticket association, consider using branch naming conventions or integrating Jira with your version control system. This can provide a more reliable link between tickets and code changes.
For isolating new commits, you could use Git’s built-in functionality to compare the current production branch with the previous release tag. Something like ‘git log prev_tag…HEAD’ would show you all new commits since the last deployment.
Another important aspect is accounting for different workflows. Some teams might have multiple stages between ticket creation and production deployment, like code review or staging environments. Ensuring your tracking system accounts for these intermediate steps can provide a more accurate representation of your development process.
Lastly, consider implementing automated tagging in your CI/CD pipeline to mark successful deployments. This can simplify the process of identifying when code actually reaches production.
hey sophia, have u considered using git tags for tracking deployments? it’s pretty simple. just tag each successful deploy with a timestamp. then u can easily compare the latest tag with the ticket creation time. no need to mess with individual commits. plus, it’s way faster to query tags than digging thru commit history. just my 2 cents!
I’ve been down this road before, and here’s what worked for us. Instead of relying on commit messages, we integrated our issue tracker directly with our CI/CD pipeline. This way, we could automatically link deployments to specific issues.
We set up a webhook that triggered whenever a deployment hit prod. This webhook would ping our tracking system with the deployment info and the associated issue IDs. Then, we’d calculate the lead time by comparing the deployment timestamp to the issue creation date.
One thing to watch out for: sometimes issues get reopened or have multiple associated deployments. We ended up tracking the first deployment for lead time, but also kept tabs on subsequent ones for our own insights.
This approach saved us a ton of headaches trying to parse commit messages or git logs. It’s more reliable and gives you a clearer picture of your actual workflow. Just make sure your integration is solid, or you’ll end up with gaps in your data.