How do you or your organization use this solution?
Please share with us so that your peers can learn from your experiences.
We happily use containers as a way of scaling out microservices so we use Nexus Repository for the management of containers, as a kind of repository. That's about 50 percent of what we use it for. The other side is that it is used for application and development artifacts. We use it to track artifacts in a repository so we can deploy software code. It's not a code library because we GitLab as well. It's more for the compartmentalized aspect that fits in and we can redeploy those on-demand. The way we deploy it is private cloud, ultimately. We have an internal cloud infrastructure that we operate and the Nexus platform sits inside it. We are looking at ideas around integrating this into AWS right now, because we are doing a huge kind of transformation project to move a lot of our on-prem services into public cloud. We're looking at that whole "bridge" between the cloud and on-prem and how we deal with that. That's something of a stepping-stone before we can take everything back into the cloud. I think Nexus Repository will eventually end up there.
We are primarily using Nexus Repository Manager to store the components we are building and to share them among our teams. We are also using it to get a cache from older, available public repositories which we need to build our projects. Regarding Nexus IQ, we are using it mainly to scan our projects to see the security vulnerabilities that may be occurring in our products.
We are using this tool for our Java, .NET, AngularJS and Node.js. Apart from that, we have recently built a solution to utilize this tool for Docker images as well.
We are using Nexus Repository as a Java repository for our libraries. We cannot host proxy libraries because we don't have access to the internet. We're downloading libraries manually and then uploading them to our Nexus repositories. That's the current approach. We not only upload open-source libraries but also our own libraries that we developed.
Our primary use case is as a manager and storage location for open-source software components. We utilize the Nexus repository to store safe open-source components that our developers can utilize in their applications, as opposed to their going out to the internet and getting potentially unsafe versions of the open-source components. We use it to manage binaries both in the IMR and in staging. Our biggest use of the software, as stated before, is to store open-source software components for user applications. The second biggest use is as a staging repository. We'll stage binaries for changes that are ready for deployment across to a production environment. We'll stage them there so we know they're centrally located. If we want to do any scans we can do them right there before they're deployed to our enterprise.
The primary use case is to store good artifacts our company has produced and proxy external artifacts to help reduce the outgoing traffic and to filter specific components which are known to be vulnerable.
We use it as a repository for build artifacts. We have 300 developers and most of them use Nexus Repository to do their builds. They are mostly stream-mode applications, as well as front-end Angular applications. We definitely pull down most of the main dependencies, binaries, build artifacts, and release candidates.
At the moment we use it as storage, as a repository, the proxy to internet repositories, and for internal storage of our binaries. But we are looking seriously into using it for compliance to policy, for open-source dependencies that may have security issues or contradictory license usage. If certain dependencies do not comply with our licensing policies, then we want to be able to identify them. We are very interested in it to ensure the traceability of our open-source dependencies, to make sure that we are not using dependencies that could cause problems in the future, that could cause intellectual-property issues with the rest of our software. I wouldn't stretch it as far as calling it open-source governance. It's more of a safety check, to make sure that we don't make any mistakes that could cause legal problems later.