It's important to know that the solution will not be able to fit perfectly with your use case and other tools will be required.

I would rate this solution nine out of 10. 

Talk to Sonatype about how flexible they can be around their licensing. We did purchase 500 licenses, but initially we were around 20. Rather than paying for the whole thing, I would say, "If we commit to the 500 over a particular period of time..." and have that conversation about what a realistic ramp-up would be. See if you can be charged for the number of users you have, rather than paying for 500 users but only using 20, which is what we did. It wasn't an effective use of money at that point. If I was doing it again, I'd have a better commercial conversation with them around how we could ramp up the costs over a defined period of time.

One of the biggest lessons we have learned is don't underestimate how much developers will potentially like the product. As soon as we started testing it, we had developers all over our organization really wanting to be part of it. And that's why we ramped up so quickly. We wondered whether we would cause all-out war at one point. We had a few minor speed bumps along the way but nothing really critical. A lot of it was about account permissions and those kinds of things. But other than that, it went really smoothly. The lesson learned is to make sure that you keep a touchpoint with your account management team.

And as part of any type of initial project, I would certainly get one of Sonatype's technical guys on point. We got somebody to work with us to give us that initial induction training and supporting us by checking out the solution definitions that we put together to deploy Nexus Repository across our own structure. We worked really closely with them and that is one thing I would recommend, unless you've got some great Nexus skills in your organization. We didn't look at other systems integrators to work with us. We went straight to Sonatype.

Initially, we had the open-source, freeware version and we had lots of different things like Docker repos around it. We've consolidated that down. We've got the enterprise version of Nexus now. We use it as a consolidated product for all teams across the business. We use Nexus IQ as well to provide that layer of security around it. We're not averse to using open-source repositories and pulling them down. But due to the level of requirements in the organization, we have to have adequate security controls in place, so we use that. I'm not a security tech expert by any stretch but it helps us when we use open-source.

In terms of the solution integrating well with our existing DevOps tools, I would say it does, but with a bit of caution as well. It's getting better. In terms of our pipeline that we use to deploy applications out there, we have integrated with Jenkins to help deploy through some kind of built pipeline. It takes a little bit of developing on our side to get that working properly and effectively.

As for maintenance, we keep things up to date. It sits inside what we call an infrastructure cloud tooling team. That team consists of about six engineers but it doesn't take six engineers full-time to maintain it. It takes about one day a month's worth of time to maintain at most. It's not high maintenance at all. It's when things fail then that it becomes a bit more intense. But overall, when things are running really nicely, then it's hardly any effort at all.

I would rate Nexus Repository at eight out of ten. Once we move it to one of our own internal databases, as opposed to using the proprietary database structure, that will probably move to a nine or a ten. It's an excellent product overall.

I would rate Sonatype Nexus Repository an eight out of ten.

I can confidently recommend this solution. The main reason is its stability. In comparison to other competitors, especially when I consider alternatives like Project X, Nexus stands out as a stable and reliable choice. This reliability is a key factor that makes me feel comfortable recommending it to other users. Based on its performance, I would rate it 8 out of 10. 

I recommend examining your processes to determine if they align with this tool, as its history is heavily concentrated on Maven. If your operations involve Maven, this solution is likely the most suitable. 

As we primarily focus on Java and Maven, I would give this solution a rating of nine out of ten in such cases. 

However, if your emphasis shifts towards NPM products or NuGet, using Nexus is still feasible but may require more effort. The tool is more centered around Maven, making it a bit challenging to seamlessly integrate with NPM. 

In such scenarios, opting for a different product might be more favorable. Nevertheless, if your environment revolves around Java or related technologies, Nexus stands out as a top-notch product in the market.

Before deploying Nexus Repository Manager, really focus on the architecture that will be deployed. It will impact all the users who will have to use Repository Manager, especially if they are quite far from the central server. Think about deploying Nexus Repository Manager locally in order to help. Local users get their information faster and in a more efficient way. Regarding Nexus IQ, I would say the opposite: Try to be as central as possible and to have the fewest Nexus IQ servers to meet your needs, because the more you have, the more you will spread the information, and the less you'll be able to capitalize on it in only one server.

I would advise different ways of deploying them. For Nexus Repository Manager it is preferable to deploy a lot of servers locally to help the teams work faster, while for Nexus IQ, preferable to deploy only a few central servers.

For us, it's really difficult to say if the solution has improved the time it takes to release secure apps to the market. What is important is the cost of the quality, or the cost of the lack of quality, in a product. Calculating it would require calculating the cost of the maintenance of the different projects if we hadn't deployed the application. It's really difficult to put a number to this question.

For the time being we are not using grandfathering because we just upgraded to release 64 a few days ago. In addition, the Success Metrics are used by projects. I know that they are quite useful, but I have no feedback on this as I'm responsible for the deployment and the routine maintenance and support of the application. I'm not directly involved with the project lifecycle. The solution does not yet block undesirable open-source components from entering our development lifecycle because we do not use the auditor feature. We may use it in the future if we manage to have stronger policies regarding our OSS libraries. We are not yet at the stage of automating open-source components. We are still doing it manually, but we are working to make automation available soon with other tools such as JIRA, etc., to raise and to address all of the management policies that we have to handle in our products.

For Nexus IQ we have purchased 250 licenses and we currently we have about 200 users worldwide. We have purchased 450 licenses of Nexus Pro and, for the time being, we have about 200 users. For Nexus OSS, taking into account all the users, we have about 2,000 or 2,500 users. We are currently increasing our infrastructure worldwide for Nexus Repository Manager. And for Nexus IQ, we may have to increase our number of licenses in the coming years to be able to address all the needs of the team. Nexus IQ has more and more success because it's very relevant and the team is more and more eager to use it in their day-to-day jobs.

For deployment and maintenance, I am in charge. I am helped by our infrastructure provider, which has a team that is dedicated to all our applications. For about 90 percent of the job I'm the one, and when I need to do upgrades or involved maintenance, there are two people.

I would rate both Nexus Repository Manager and Nexus IQ at seven out of ten. We're still missing some features in Nexus IQ which would really benefit us. In Nexus Repository Manager there are some features and some repository formats that are still not supported by Nexus, but which could be supported by Nexus. That would help us a lot in our development. That's why I don't rate them at eight or nine out of ten.

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.

Our company is about 25 years old. When we started developing stuff in Java, we didn't have much tool support and, as we are a company that integrates other systems, we basically built our own tools. That's quite nice if you can do it, but it is always a burden to maintain. That was another aspect we had in mind. We wanted to reduce the maintenance of self-created systems and to get our administrators to use a standardized toolchain. That really helped to reduce their efforts and keeps us up to date with current developments in the business.

As you know, software development is something that is changing every now and then, so every month you have to be up to date with some new framework. It's really hard to keep that up if you try to build your own build-and-development chain. So it's very nice to have several things that are already done by other companies. The storing and distributing of artifacts was really one burden that didn't provide any practical business value but required loads of effort. This is one thing that the Nexus Repository Manager addresses very well.

We use Nexus Repository to manage binaries, build artifacts, and release candidates across the pipeline. We used to do it with Nexus Repository Management 2, using their staging system. Nexus Repository 3 didn't introduce staging until one of the most recent releases, so we started off with a staging repository where we would publish our "to be released" artifacts, and then provide a release repository so that we could push them using some continuous integration pipeline configured in Jenkins CI system. I'm going to be using the tagging feature they added recently to provide the staging functionality we used to have in Nexus 2.

We don't use it right now for open-source governance because that would require us to rely on the IQ Server and we do not have any licenses for the IQ Server. I do some manual filtering - based on CVE advisories. I exclude some packages from being downloaded, ones I'm aware of that are vulnerable, but that's more or less a manual effort to configure those right now. The governance part is not fully automated, right now, but we are working on that.

We currently run with about 240 accounts on Nexus. There are several developers and several system accounts, but we have a daily login rate of about 160 users.

We are currently trying to force more teams to use the system. There are still some older systems relying on very old infrastructure, which are currently not connected to the CI pipeline. This should change within the next one to two years, and then we will have no system that's not connected when using any dependencies for Maven or NuGet or NPM or Docker. They are the four repository types we are currently running. There is a business rule that no system shall get its artifacts directly from the web. Everything shall be proxied by Nexus. Eventually, everybody in the company will be forced to use the Nexus.

Overall I would rate it at nine-plus out of ten. I'm very pleased using Nexus Repository Manager. And I'm also looking forward, based on the experience that I have had with them and their technical and business department, to adding to our toolchain regarding IQ Server and lifecycle products. That is something I have to sell internally, but I think this will come eventually.

It should be integrated and become a part of your pipeline as soon as possible. The earlier you start, the better.

I would rate Sonatype Nexus Repository an eight out of ten. A score of eight, because, the multifactor is critical. That's why it loses a couple of points.

My advice to others wanting to implement the Sonatype Nexus Repository is to make sure that it supports the language they are developing in. If you're a .NET developer, that would be a difficult language to use. However, if you want to do docker images, make sure you know what kind of docker to do.

I rate Sonatype Nexus Repository an eight out of ten.

I rate Sonatype Nexus Repository an eight out of ten. I advise others to update the business continuity plan for components regularly, i.e., semi-annually or quarterly. Use container images for the next migration or maintenance update. They should secure the user interface. Additionally, they should ensure a good storage process and plan a retention policy for all attacks.

If you have the ability to implement this tool within your team by yourself, go with the open-source solution that they have, rather than going ahead with the paid solution.

I started with the 2.2 version but two weeks back I upgraded to 3.15. Before that, I was using 3.14 and prior to that I was on 3.9.

The clean-up policies have been improved: How we manage our changes, how we manage our artifacts, how much we need to keep, and how much we want to remove. That has effectively improved. In addition, slowly they have onboarded multiple technologies. As I mentioned, I started just with Java and I am now supporting six technologies on this. Three of them have been onboarded in the last one-and-a-half years.

They are improving a lot in almost all areas. With every release they have made a couple of changes. Searching was the main capability that they needed to improve and, recently, with the latest upgrade that I did done one month back, they improved it a lot. They have really made the search very fast.

We have a license for about 200 users and we have around 100 to 150 users. We have a spare of fifty so that if we increase we can cater to that. I am not able to share the roles of our users. Usage is quite extensive and is increasing day by day, as more and more technologies are being onboarded.

We are amazingly maintaining it within my team, which consists of six people. But a single person is maintaining it, not the entire team. We have multiple instances of this tool running in our company. Most of the instances are open-source. One instance is a paid instance and that is being managed by my team. That instance is a benchmark for the entire company. The rest of the teams are utilizing the open-source version.

I would rate this solution at seven out of ten. It needs the ability to be available across DCs, across geographies. In addition, it needs the capability to do an auto-sync between the between different centers or there should be some automated trigger for that. They need the capability to move repositories from one instance to the other instance, as well. Last but not least, they should have a bit lower pricing.

My advice would be to think about the scalability. I would really advise everybody to go for it, to go for having repositories in their organization, to make their software and even hardware development more organized. Go for it, adopt one.

We are using the latest version of Nexus 2. We are in the process of rolling out Nexus 3 on a much wider scale.

In terms of using the solution to manage binaries, build artifacts, and release candidates across the DevOps pipeline, I would say yes, we're doing so. We're not as well-developed in terms of DevOps as other organizations, but we are certainly working that direction, and we use it for the DevOps lifecycle.

We use GitLab and we also use Jenkins CI, and with these two products we are able to very simply deploy to Nexus Pro and perform staging operations, to make sure that, before we release to production, we can ascertain the quality of our software. We don't necessarily automate the deployment to production now, it's still a manual process. But we are working very hard to complete the DevOps loop.

In terms of open-source governance, we should be much more proactive. Nexus is definitely a tool that makes this possible in an organization - to be proactive about your open-source choices. It's less critical in our organization because all our research is open. We try to stay away from intellectual-property problems. But on occasion we still have to pay attention to that and Nexus, with its advanced governance features, would have been a real time-saver if we had it at the time, so we are looking into it now.

The number of developers using it right now is about 200 to 300, but because we're rolling it out to the rest of the organization, making it a much more easy service to afford with OpenShift. The audience could be up to a couple of thousands of developers.

In terms of deployment and maintenance, for a single instance, we need about 10 percent of a full-time person. There are moments where it's very quiet and others where we encounter a problem and we have to take some action. But I it's a very lightweight solution compared to what other commercial products or open-source products could cost, in terms of maintenance.

I'd give Nexus Repository a nine out of ten. A perfect ten would have better support for configuration, for templating on the cloud infrastructure.

Make sure you know how you want to use it, and set up your rules, processes, and policies before you implement it.

Their customer service is pretty good. Their software does what it says it does. They've got another component add-on we're looking to purchase that will assist us. Sonatype has business relationships with other companies which sell their software, and their name is known in the DevOps world. They're a stable company and have a stable product.

In terms of the number of users using our Nexus Repository, just about every developer who programs in Java has to use one portion of it, and we have about 500 of them. At least 300 users in the IT community use it. For deployment and maintenance of the solution I've got three people. One of whom is on contract. They're involved in maintaining the software, keeping it up to date, configuring it for better security, training users, etc.

We are looking to increase usage up to 500 people when we get the next component.

I'd give the product an eight out of ten. If they want a ten, they should cut their price in half and they should increase the security capabilities out-of-the-box.

It's definitely worth looking into as a DevOps tool, which can be integrated into the build pipelines.

We use the Nexus Repository but now we are definitely planning to increase the usage.  We are looking at the Lifecycle and Firewall products as well. This is the first time we have started looking into this aspect of Dev Lifecycle Ops. That's in the process of evaluation and, once all the evaluation is done, we will consider it. The build Repository is definitely the main application but to make sure whatever we do is secure and compliant, the Lifecycle is looking to be more important.

I rate the product at eight out of ten. The two points are because it's still somewhat unknown, we haven't used it intensively.