Deployment frequency appears in two different locations under value stream analytics and under CI/CD Analytics - they are both using the same API
Proposal
In CI/CD Analytics, it would be nice to add the deployment frequency and number of deployments tiles to the deployment frequency tab, like this:
Things to note:
A license check should be performed (for Ultimate) if using the VSA API, so it would be better to use the DORA API because that is already restricted to Ultimate.
The tiles should represent the same interval that is displayed on the CI/CD Analytics page.
CI/CD Analytics shows only deployment to production environments - deployment frequency in VSA shows?
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Dan Jensenchanged title from Add VSA deployment tiles to deployment frequency tab (ci/cd) to CI/CD Analytics: Add VSA deployment tiles to deployment frequency tab
changed title from Add VSA deployment tiles to deployment frequency tab (ci/cd) to CI/CD Analytics: Add VSA deployment tiles to deployment frequency tab
@ahegyi@djensen Following up from our conversation we had during the planning.
These metrics are only available for GitLab Premium and "GitLab Ultimate" , right? If we use the DORA API, then this available for"GitLab Ultimate" only.
What's your suggestion - which API should we be using and do we need additional backend work here (for license checks, etc)?
Since the deployment data (counts) are already loaded via the DORA API calls on the page, we could calculate the metrics on the frontend. The downside is that now we'll have 2 implementations: VSA (ruby) and JS based calculation.
Load the summary endpoint from VSA. It loads more data that we need (issue count, commit count etc)
Load the summary endpoint from VSA. It loads more data that we need (issue count, commit count etc)
That's what I'm leaning towards but I believe we cannot filter the relevant metric on the frontend. Metrics currently don't have a unique identifier, see:
Maybe we should spend a bit more time on this and port the summary endpoint to GraphQL. That would allow us to request a specific combination of metrics.
Maybe we should spend a bit more time on this and port the summary endpoint to GraphQL. That would allow us to request a specific combination of metrics.
I think that's a great idea. Do we have capacity to port the endpoint to GraphQL? If this is too time consuming, we could go with the pragmatic approach for now and just add identifiers?
@ogolowinski What's the priority for this issue? Depending on this, we can either go with a pragmatic approach or wait until we have more backend capacity to port the existing REST API (summary endpoints) to GraphQL as suggested by @ahegyi.
@ahegyi@djensen So how about we add an identifier to the existing summary endpoint and then frontend can use them to filter by Deploys and Deployment Frequency? That should be something that frontend can work on in %14.6. WDYT?
A license check should be performed (for Ultimate) if using the VSA API, so it would be better to use the DORA API because that is already restricted to Ultimate.
@wortschi, I totally missed that. The VSA API is available in Premium and Ultimate, it's a JSON endpoint, you can call it from any page.
If the Deployment Frequency tab within CI/CD Analytics already does the Ultimate license check (404 when opening on a premium group) then I don't think using the API is a license violation. WDYT?
If the Deployment Frequency tab within CI/CD Analytics already does the Ultimate license check (404 when opening on a premium group) then I don't think using the API is a license violation. WDYT?
Is that the current behavior or would we need to implement this as part of #349880 (closed) (or some other issue)?
Either way, this sounds good to. @ogolowinski would that be a reasonable approach, WDYT?
@ahegyi Thank you! If I understand correctly, we are already doing the following:
if the user has a valid DORA4 license: we show all the charts, i.e., including deployment-frequency and lead time
if the user has no valid DORA4 license: we only render the basic charts, i.e., without the deployment-frequency and lead-time. In this case, the tabs won't be even visible/rendered
One more question: When calling the JSON endpoint for a group or a project with the created_after query parameter, is it okay to use the full ISO string, including the time portion?
summary?created_after=2021-12-15T00:00:00%2B0000
or do we need to remove the time and just send the date part?
@wortschi, in VSA we're expecting dates. I tried to pass timestamps using your example and it seems to be working. Since we call Date.parse() I'm not sure if it will work for all kinds of timestamps.
Looks great @wortschi - can you add a comma separator (internationalized) to improve readability of 4 digit numbers?
Technically this is possible but we would need to check if we there's already a utility function that takes care of this or if this still needs to be implemented. I'd suggest to look into this in a follow-up issue.
We'll be re-using the metrics component from VSA here. I realized that this will also show the dashboard link. In VSA the link will redirect to the CI/CD Analytics page but I feel is not relevant in the context o CI/CD Analytics as we are already on this page. So I would suggest to simply remove the Dashboard link here. Does that make sense?
@npost Unfortunately, that is something we currently cannot do. The links are currently hard-coded (irrespective of the context). So this would be another backend change that we could work on in a follow-up iteration.
Happy to create a separate issue for this as I think that this would be a useful change. /cc @ahegyi
We might need to rethink how we expose and store the links. It looks like the links depend on the context (where we're on the UI) which is not an API responsibility.