Sonatype Nexus Repository Review

Hosting libraries that can be used across multiple teams helps improve productivity


What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

The core features are the most important: We can host libraries, upload them, and they can be used across multiple teams. The hosted repository is the primary feature we're using.

What needs improvement?

When it comes to the library uploads, for Java libraries it's very easy. You choose the .jar that is to be uploaded. But when it comes to uploading NPM libraries, JavaScript dependencies libraries, it is a little bit of a convoluted process. They need to improve uploading libraries for NPM-type repositories. There is good room for improvement there.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

It's pretty reliable. Again, just the way the organization is set up, we do not have access to the internet. We don't pull the libraries from outside, through the proxies. We are uploading them manually. But it has been pretty reliable. The only issue we had was our infrastructure setup. With the disk allocation, we have run out of space. That's the only problem we had. But as far as the reliability of the product goes, it is fine.

What do I think about the scalability of the solution?

It's scalable. For our organization's needs it's fine. We have not run into any issues where it caused performance degradation.

How are customer service and technical support?

There were a couple of issues that we needed help with, that we raised with Nexus customer care, but the response was pretty fast. It was an excellent experience.

If you previously used a different solution, which one did you use and why did you switch?

We did use Artifactory, it's a competitive product. Before, our division was part of a different organization and that organization had the ability to use outside, hosted repositories. So we could go to Maven hosted repositories outside of the network; truly open-source. Artifactory was only used certain solutions. It was a different scenario.

Nexus provides more capabilities when it comes to hosted and proxy repositories. This was the primary reason we switched.

How was the initial setup?

The initial setup was pretty straightforward. We worked with the Sonatype customer care team. I was not involved specifically in the installation process. Our infrastructure team and DevOps teams were involved in it. But it was fine. It was not a big issue. We had to use the Nexus setup, provided by default, and that was a good feature. As we matured our process, we brought it under our own security management system, as far as the management roles and responsibilities go.

I was involved in the implementation strategy, but not in the physical installation, running the files. I was involved in the selection of the product and the features that were going to be used and how it was going to be set up initially. Our DevOps and infrastructure teams took it from there.

What was our ROI?

It's all about productivity. There is tangible productivity there. The speed of development is faster.

Also, if you develop a new team and all of them need the same library, you don't want every developer going to get this library. It's uploaded once and it's being used everywhere.

Which other solutions did I evaluate?

There were not that many competitors in this space. It was between Nexus and Artifactory. It was a pretty straightforward decision.

What other advice do I have?

Try to leverage most of the feature set. The security scans are a great feature. When the open-source libraries are downloaded, Nexus can provide an automated solution to certify them for use. It might be a good idea, as well, to make this product part of the build pipeline, so you don't have to build every time.

In terms of managing binaries, build artifacts and release candidates across the DevOps pipeline, we are not using Nexus for checking our artifacts in the build pipeline. 

We do utilize Nexus if I create a utility library in a project and this library needs to be used across ten other projects, ten control systems. If it's code developed by us as a reusable component, then yes, we will develop the code so that it will be checked out by the source control system, and the produced .jar will be uploaded into Nexus. It will become available across the organization, but only as a reusable component. In that case, the reusable component becomes available as part of the build pipeline downstream system.

We don't use the solution for open-source governance.

Right now my role is an application architect so I'm part of the development team. In the capacity which we are using Nexus Repository it's doing the job. The area in which I was involved in as a developer, I needed certain libraries. I first had to check if they were in Nexus. If they weren't there I would have the problem that I need to get them in there.

Still, it's a good product. There are a lot of features our organization is not using. Many of them are security scans as you set up open-source governance. As you upload libraries, Nexus offers to scan them and certify the dependencies. We don't have that. But we're covering this by the static code analysis, outside of the Nexus. That's where we are compensating.

In our organization, about 100 people are using the solution. Most of them are developers. We have projects where we specify our Maven or NPM dependencies. Most of our people are clients of the system. Then we have our DevOps team which is comprised of five people who are actually managing the content that's being uploaded to Nexus. It requires very minimal maintenance, which is done by our DevOps team. And we have our infrastructure team that does the hosting. It's pretty stable and reliable and there is not much involved in the maintenance.

It's a great product. I give it a nine out of ten. There is always room for improvement.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Add a Comment
Guest

Sign Up with Email