How do people actually manage versions in Dependency-Track?

[jakub-bochenski]

First of all sorry, for making this an issue.
I tried to open a discussion but apparently it's not possible for me in this repository.

My ask isn't directly related to the Jenkins plugin, just to D-T usage, but I thought this would be the place to find people familiar with running D-T on CI.

My problem is I don't see an easy way to use D-T when you are actually doing CD, meaning that each commit would be a new version.

I've made a detailed post at D-T repo DependencyTrack/dependency-track#4856
but got no replies so far, so I thought maybe I'd try here.

There seems to already be a discussion that touches on this topic: #142

Yet I see a problem with the approach presented there. Namely if you remove a component from your library/service etc it will stay on D-T, because the BOM upload is additive.

I'm curious how other people mange a CI/CD setup with D-T

[sephiroth-j]

I tried to open a discussion but apparently it's not possible for me in this repository.

That's strange, everyone should be able to open a new discussion.

The problem is that each BOM upload is additive.
So if I remove a component from my service DT will still think it's included in the service, and report vulnerabilities etc.

If you upload a new BOM with different/less components to an existing DT project, i.e. with the same name and version, only the components from the new BOM will be part of the project. Of course, the old components remain in DT, but are no longer linked to the project.

I'm curious how other people mange a CI/CD setup with D-T

I have seen two variants:

1. using the stage as version
2. a kind of "SNAPSHOT" version representing the main/master branch and specific versions for releases. Additionally, when a specific version goes into production, some housekeeping is done: all active previous versions (according to semantic versioning) are marked as inactive.

[jakub-bochenski]

Thanks for the feedback!

If you upload a new BOM with different/less components to an existing DT project, i.e. with the same name and version, only the components from the new BOM will be part of the project. Of course, the old components remain in DT, but are no longer linked to the project.

Yes, this was a misunderstanding on my part

a kind of "SNAPSHOT" version representing the main/master branch and specific versions for releases. Additionally, when a specific version goes into production, some housekeeping is done: all active previous versions (according to semantic versioning) are marked as inactive.

If I understand correctly in this setup there would only be one semantic version marked as active, and this is how I find what is in production?

I assume the housekeeping is some external cron/trigger, which is doable but adds to the complexity and there is room for bugs in the logic.
This can get complicated if you have to handle rollbacks or have different production zones that you rollout independently.

It seems that the "using the stage as version" approach would fit my needs, the only drawback I see is that the actual version is not recorded in D-T, so you cannot double check it against production etc.

[jakub-bochenski]

That's strange, everyone should be able to open a new discussion.

I just don't see the button, could this be a permission issue?

There is a control at the organization level which can limit Discussions so that only those with triage+ permissions can open new discussions. Anyone can still comment on an existing/opened discussion.

https://github.com/orgs/community/discussions/29

[sephiroth-j]

If I understand correctly in this setup there would only be one semantic version marked as active, and this is how I find what is in production?

How many active version you have depends on your use-case. There is usually one for each stage. For example: "SNAPSHOT" for your main branch, 1.2.3 in pre-production (because it was a release build that is a candidate for production) and 1.1.0 in production. The "SNAPSHOT" version is always the same and reflects the status of your current code, from which you could create a new release. Each time you perform a build of the main branch, you would publish a BOM as version "SNAPSHOT".

I assume the housekeeping is some external cron/trigger, which is doable but adds to the complexity and there is room for bugs in the logic. This can get complicated if you have to handle rollbacks or have different production zones that you rollout independently.

Yes, it's external. And again, it depends on your use-case. It could be part of your deployment process. And it could also be part of the rollback process to reactivate a previously inactive version. If you have more than one version active in production, you should find a way that meets your requirements. Instead of simply marking all older versions as inactive, they could be checked prior to this to ensure that they are not part of another production zone (for example via a CMDB).