Skip to main content
All CollectionsBest Practices
Best Practices for Tracking Deployments
Best Practices for Tracking Deployments

The best practices of tracking deployments for a scaling organization

Sagar Shewarmani avatar
Written by Sagar Shewarmani
Updated over 2 years ago

Knowing your deployment frequency helps understand the rate at which you're delivering value to customers. With the best teams deploying on a daily basis, this is a key North Star Metric to help keep your team on track and delivering.

One of the biggest challenges engineering teams encounter is tracking Deployments in a scalable, standardized method. This article will help you answer how to track deployments in a scalable and standardized method throughout your organization.

Initial Questions to Ask

  1. What action do you consider a 'deployment'?

  2. Do all teams adhere to this approach? Which teams don't?

  3. How consistent are your deployment processes across services?

Most teams will have some hybrid approach to deployments. Some services using a legacy system while others use a nice continuous deployment pipeline. While a standardised system is always preferable, here are some criteria to consider when selecting your choice of measurement.

Criteria to Consider

  1. What actions are immediately available to track deployments?

  2. What actions do we need to implement to track them more accurately?

We always suggest taking a step-by-step approach to tracking deployments. Try to identify the most common pattern for deployments and use that as a starting point. Once you have that in place you can begin to standardize and track more of your deployment processes (tips on how to do this below)

Calculating Deployment Frequency

There are a few methods you can calculate deployments:

  • Git tags containing 'X' text (Recommended)

  • Git tags

  • PR merged to 'X' branch

  • PR with 'X' label

  • PR contains 'X' text

These options are meant to be flexible enough to handle your needs and help you standardise your data into Github as your source of truth. You can also adjust your Deployment Frequency Tracking on a repository-by-repository basis to give you complete control over your hybrid system.

Best Approach: Git tags

At Haystack, we recommend using Git Tags as the standardized method of tracking your deployments. Git tags are a default attribute of git and have a few benefits over other methods:

  1. Git tags live together with your code. Finally, a source of truth.

  2. Easy to standardize across teams, projects, repositories.

  3. No data lock-in. Haystack doesn't own the data, you do!

  4. Easily integrated with CI tools like Jenkins, Github Actions, Circle CI, etc.

  5. Complete control. You control when, how, and what system tags your releases.

As long as the whole organization is using Git, it can be standardized across all teams regardless of the tools they use.

Note: Some teams prefer to tag CI builds as well as deployments. In that case we recommend adding a consistent keyword across all your repositories like v1.2.3-prod.

FAQ

Can it support different environments?

Git tags can be customized like v1.2.3-prod , v1.2.3-staging. You can then customize your deployment tracking to only count the tags you care about! In this case, the v*-prod tags.

Pro Tip: Flexibility is great, but makes it harder to standardize across teams. Even if different teams use different conventions, Haystack can support customized rules for each team allowing to track deployments accurately.

How much does it cost to implement the process?

Regardless of the organization's scale, the cost is minimal and generally considered best practice. You should tag your releases for easier deployment management, rollbacks, and more.

Manual Tagging: Use Github Releases, or CLI

Automated Tagging: Takes a few lines of code in your CI process.

What about mobile teams? Won't that be hard to track?

Mobile teams can sometimes be blocked by external factors such as App Store reviews/releases. In this case, your deployment frequency might be bi-weekly. In this case, you have two options:

  1. Tag Releases after App Store Release

  2. Tag Releases when merged into production

While mobile teams are blocked in their release cadence, iteration speed is still hugely important. From that respect, using merged into production as an alternative to App Store releases may give you a better indication of development velocity.

Next Steps

Haystack has worked with 100s of organizations from a few engineers to 1000s of engineers scale. We have seen git tags method working for all of their needs regardless of the size of the company.

We would recommend using git tags as a way to measure your deployments.

Check the following blogs:

Did this answer your question?