You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
To accomplish this feature. I think these things must be done:
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.
add a new table called cicd_deployment_attributes, use it to store the deployments additional attributes. It has three columns deployment_idattribute_name and attribute_value at least.
With these changes, we can calculate deployments's metrics group by custom attributes.
Search before asking
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?
Code of Conduct
The text was updated successfully, but these errors were encountered: