[Feature][Version Management] Track the distinct versions across customers and the lead time for the customers to upgrade to the latest version

[Startrekzky]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Use case

This is a use case contributed by a DevLake user:

They release a new "cluster chart" at regular intervals, but enterprise customers, each with unique change requirements and schedules, may not upgrade immediately.

As shown in the diagram, they serve multiple customers. Each customer may have one or more management clusters, primarily for georeplication. Each management cluster oversees multiple workload clusters (corresponding to different development stages like dev, staging, prod).

This DevLake user's primary concern is to minimize the number of distinct cluster chart versions in circulation to reduce maintenance costs. They track the time from a new cluster chart release to its deployment across most workload clusters. Additionally, they need to segment deployment data by customer, management cluster name, type (WAS, Azure, VMware, bare metal), and workload cluster name.

To measure the percentage of workload clusters on a specific release version, we need to know how many workload clusters are there in total. We can approximate this number using the total number of workload clusters we have seen in the past.

Description

No response

Related issues

#6959

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[d4x1]

To accomplish this feature. I think these things must be done:

1. Fetch upcoming and historical releases automatically. For example, if users are using GitHub to manage releases, then we can fetch release via GitHub's API (https://docs.github.com/en/graphql/reference/objects#release).
   Optional: Add a new webhook which can be used to post releases by users.
2. add a new table called cicd_deployment_attributes, use it to store the deployments additional attributes. It has three columns deployment_id attribute_name and attribute_value at least.

With these changes, we can calculate deployments's metrics group by custom attributes.