We are currently in the process of onboarding our self-developed applications and are very unsure about how we should organize them. In most cases, our applications consist of a frontend (npm) and a backend (Java). These share a common Git repository (Azure DevOps). Frontend and backend are each deployed in their own Docker containers, with a DockerCompose in the root of the repository that starts the components together. We use pipelines in AzureDevOps for CI/CD.
The structure of the code repository for a project is approximately like this:
– code / package.json / dockerfile / …
– code / pom.xml / dockerfile / …
We are looking for a best practice to reflect this structure in the Nexus IQ Server. We would like to be able to see the scan results separately for the frontend and backend. That’s why we started with this structure in Nexus IQ:
- App1 (org)
– App1_Frontend (App)
– App1_Backend (App)
The first question would be: Is this a correct approach? Should we rather onboard the entire application in one app?
With the separation, we currently have the problem that we cannot represent it via the SCM integration. We have not found a way to perform monitoring on the sources only on individual subfolders or file types. So currently, in the source stage, we would receive the scan results for all components. Is there a possibility for this?