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
{{ message }}
Repository navigation
[Feature][framework] CI/CD Domain Layer Entities Design & Development #2537
I had searched in the issues and found no similar feature requirement.
Description
Where we at
The following status is how we support the CI/CD data analysis :
We collect Gitlab Pipeline data into Tool Layer as _tool_gitlab_pipeline
We collect Jenkins data into both Tool Layer and Domain Layer as _tool_jenkins_jobs_tool_jenkins_buildsjobs and builds
In another word, we modeled the CI/CD Domain Layer Tables based on Jenkins, and the Gitlab Pipeline data never get into Domain Layer because they are quite different in terms of modeling. This is also true for other kinds of CI/CD systems.
Why we need it
However, CI/CD plays an important role during the R&D process, metrics like Build Success Rate, etc (@Startrekzky please add more examples) depend on it.
What is the problem
CI/CD modeling varies in different platforms, there is no de facto modeling. It is hard to design a sensible model for CI/CD Domain Layer Data.
How should we approach
I propose that we address the problem by the following step:
Set up a couple of designated charts depending on CI/CD data that we would like to have @Startrekzky
Assign a Veteran Developer to investigate the modeling of the most popular platforms, such as Github/Gitlab/Jenkins/ArgoCD, and propose a CI/CD Domain Layer Table design
The design shall be evaluated by the PPMC members in 3 workdays while all Committers could share their opinions
A Data-Oriented PoC (a set of tables with data from different platforms) should be presented for the Analyst (@Startrekzky @leglar @hezyin) to evaluate
And then we implement
Use case
We may create Standard CI/CD charts based on Unified Domain Layer Tables
Users may exploit the Unified CI/CD Domain Layer Tables to create customized charts
I created three issues for separate CI/CD tools.
We will investigate those tools first, and after a new discussion, we will implement the collector and extractor of the plugins.
Change Failure Ratehttps://linearb.io/blog/dora-engineering-metrics/#change-failure-rate (Depending on the definition of a change and failure, it may be the failing percentage of “build” that meets specific conditions. Normally, this metric is calculated by counting the number of times a deployment results in a failure and dividing by the number of total deployments to get an average number. A lower average is better.)
Analysis Dimensions to be considered:
time: e.g. measure the average build duration over the calendar date
job: e.g. compare the average build duration under different jobs
repo (code base): e.g. compare the average build duration triggered by different repos
In addition, the naming of tables should avoid confusion for users of any CI/CD tools, such as Jenkins, GitLabCI, GitHub Actions or CircleCI. For example, job means different entity in GitLabCI and Jenkins, thus we should consider not to use it in the domain layer.
We also need to consider Azure DevOps/CircleCI/Travis CI/AWS CodePipeline
Activity
Startrekzky commentedon Jul 19, 2022
CI/CD Metrics:
change, it may be a “build” that meets specific conditions.)recovery, it may start when a “bug” is created, and end when it's fixed.)changeandfailure, it may be the failing percentage of “build” that meets specific conditions.)Analysis Dimensions
warren830 commentedon Jul 22, 2022
I created three issues for separate CI/CD tools.
We will investigate those tools first, and after a new discussion, we will implement the collector and extractor of the plugins.
warren830 commentedon Jul 25, 2022
According to our discussion from mailing list,
Metricsto be considered:Analysis Dimensions to be considered:
In addition, the naming of tables should avoid confusion for users of any CI/CD tools, such as Jenkins, GitLabCI, GitHub Actions or CircleCI. For example,
jobmeans different entity in GitLabCI and Jenkins, thus we should consider not to use it in the domain layer.We also need to consider Azure DevOps/CircleCI/Travis CI/AWS CodePipeline
warren830 commentedon Aug 25, 2022
This ticket can be closed for now