Sonatype Nexus Repository Reviews

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.

The first good feature is the searching capability. They have recently really improved it. When I started using it, their search was quite slow. They have improved in that area very effectively, and I really like it.

The second valuable feature is that in a single tool we are managing multiple central repositories. The more support we have, the more the tool will be effective because we are able to manage multiple requirements from multiple domains in a single tool.

Initially, when I started using this tool, I was mainly using it for Java. Then I onboarded .NET, then I onboarded JS. And about six or eight months back, I onboarded Python. And I am about to onboard Docker. The availability of integrations allows me to do this.

Of course, we use this solution to manage binaries, build artifacts, and release candidates across the DevOps pipeline. I can't say how our company is doing so, that's company information, but we are using it to manage artifacts across our pipeline, starting from the lower environment and ending in production.

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.

First of all, we now have a well-documented process on where to find any build result produced within the last two years. This documentation has been made available to the whole company. Previously, we had several platforms. The results were sitting in some continuous integration system while build results for other teams were hosted on a shared drive, etc.

It has helped us reduce the effort in maintaining several systems. That is a huge benefit. We only have to maintain one system and we can use this system concisely across several locations. It has saved time tremendously. As a rough approximation, I would say we only use 20 percent of the administration time we used previously, so it's saving us 80 percent. And storage management has been simplified so we have been able to reduce hardware resources and backup processes. On the hardware side, as a guess, we have saved 30 to 40 percent compared to what we used previously. It's very substantial.

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.

The key benefit we get from it is speed to delivery. It has improved our overall time to get new applications out with new code. That's true whether from a platform perspective, where we are quickly deploying up-to-date Docker containers, or whether we are looking to deploy new code out to deliver a new application. That whole release cycle is vastly improved. The way we've automated a lot of our processing, particularly with us being very much a cloud-centric organization, it helps with our ability to deliver code and then scale out as we need to.

Initially, we did a deal with Sonatype to get a small number going to see what the general, intangible benefits were. The developers were certainly happy with the way our product was working. And then there was fact that we had more control of it, being on a computer on somebody's desk, that it was more centrally managed. I do have a really strong feeling that if we took it away, overall productivity would drop off. How much? I don't know but it certainly would drop off. We would probably lose people as well, since they like the tool.

We did a survey, a tool-chain analysis across the whole company, because we've got many different tools doing all sorts of similar things. At the top of the chart, in terms of people loving them, across the business — in particular the developers — were GitLab and Nexus. Nexus Repository is seen as a key, useful, strategic tool that we use here.

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.

Regarding Nexus Repository Manager, using the product has allowed us to have an official and strong repository that is able to store and to manage access rights regarding the sharing of our components among the different teams. We have teams spread across multiple sites in multiple countries.

Regarding Nexus IQ, it has helped us a lot with the management of our OSS licenses and with our knowledge of the licenses and the vulnerabilities. It has also helped us with knowledge of the libraries that are embedded in our products and to build a bill of materials for our projects. In this regard it has been very relevant for us.

We have found the tools integrate well with our existing DevOps tools. In fact, we built our DevOps tools over the last two or three years now and, as both Nexus Repository Manager and Nexus IQ were already available when we started to build our development chain, we had the opportunity to integrate them fully into our build generation. It's been of high value for us. We have gained a lot of time by avoiding old installations and all the sharing management is provided by Nexus Repository Manager. As we already used the tools, we built our DevOps around them.

In terms of open-source intelligence and policy enforcement across our SDLC, before using Nexus IQ in particular, we were struggling to provide a bill of materials for our products. It was up to the development team to maintain the list of dependencies that were embedded in the projects. We know that, with the human factor, sometimes some libraries were forgotten in the list. We also had some problems identifying the licenses of the difference embedded libraries that were in our products. That could have resulted in legal problems when we deployed our products because we had some licensing problems. Since deploying Nexus IQ, we have deployed and customized the policies for our company.

We had a big gap, and then a big increase, in knowledge of our tools and also in our knowledge of the licenses that are embedded in our products. We have all the knowledge needed to be able to waive all the policies and programs that we may have on our products. It's really a big benefit for us deploying Nexus IQ.

Finally, it has increased developer productivity across several projects on the order of ten to 15 percent.

Our primary use case of this solution is for our CICD pipeline, to build and store our artifacts in the repository. I'm the principal engineer and we are customers of Sonatype. 

We previously used a clunky system that required logging on to AWS IAM before reaching out to the CodeArtifacts and it would then expire after 12 hours. This required additional maintenance for developers so we were looking for a more efficient solution. Nexus provides a single sign-on that doesn't expire unless you change your password. The developer logs in once for the entire day which increases efficiency and helps the developer to more easily maintain the workflow.

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.

It has really sanitized our development lifecycle because we know where people will store their software, and we have a clear naming convention for this. Before that, people would store software in various places, on network drives, on random computers, and it was not obvious where things would be.

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.

On the hosted repository, if a team inserts a version of a library, say a Spring library, it becomes available across the organization. If our organization has between ten and 20 development teams, if you upload one library it becomes available to everyone. That helps the speed of development.

Or, for example, with the infrastructure, we have to bring our software version to a certain level. Let's say decision a decision has been made that every everybody is moving to Spring version 5.0. Our DevOps team uploads the library to Nexus and then it's available across the organization.

It improves productivity.

Our primary tool is Sonatype Nexus Repository Manager. We use it for NPM, Maven, and Docker repositories. Additionally, we utilize Nexus Firewall for repository governance. Looking ahead, I'm considering implementing Nexus Repository Manager 3 as an alternative. This would help us manage packages from Nexus IQ Server and support various package formats such as NPM, Maven, and Docker.

We rely on Sonatype Nexus Repository Manager as our main tool, employing it for NPM, Maven, and Docker repositories. In addition, Nexus Firewall plays a crucial role in our repository governance. As we plan for the future, I'm exploring the option of incorporating Nexus Repository Manager 3. This move would enhance our ability to manage packages from Nexus IQ Server and cater to different package formats like NPM, Maven, and Docker.

Primarily, the extensive support for a wide range of packages is a crucial factor. The effectiveness of new-age package managers is often determined by the breadth of packages they can handle. In this regard, Nexus Repository Manager 3 stands out for its comprehensive coverage, accommodating a vast array of packages widely utilized across the globe. This inclusivity enables easy access to a diverse range of packages, making it a pivotal aspect of its functionality.