The deployment is straightforward and the solution is very easy to set up. If the solution is only for a lab playground, everything will run in one container, and that's easy. If additional configuration is required for production usage in a high availability area then deployment will be more complex. We have in-house engineers who do this for us. 

The complexity behind the initial setup was due to the infrastructure that we had in place. The overall tool wasn't so bad. It was just adapting the Nexus product to be deployable across our internal cloud platform.

In terms of starting the project, getting it ready for deployment took about six to eight weeks overall. Getting people onboard and using it took a lot longer; to get people migrated across. But getting the platform up and running, from my point of view, didn't take that much time at all in terms of doing all the testing, disaster-recovery testing — everything that we have to do before we can commission a product to enter live service.

We've got it deployed across multiple data centers. Even though we use our internal cloud, we've got three data centers in the UK and one in Gibraltar. We have high-availability across all areas. It only operates out of one data center at any one time, but we've got the facility set up so that if we need to bring it up in another data center, we can.

In terms of the support we got from Nexus, they helped set things off and they did so mammothly. I use the word "training," but it wasn't like, "Come train us." It was more of an educational process. They took us through some scenarios of how we could migrate solutions across, how we would work in it. That was good.

The setup was relatively easy and did not take a long time.

It is easy and I would rate it 8 out of 10.The entire deployment process, including installation, manual testing, and all implementation phases, typically takes around one week but only one person is usually sufficient to handle the entire deployment efficiently.

The initial setup was not challenging. We've changed from Nexus 2, which we have used earlier. So, this was a migration process, which was just a simple turn-on. Just that system is a step on, but however, it worked fine. So there was no real problem. 

The initial setup was really straightforward. The first setup of the product was done by me. We did some tests on a server and I was able to do it quite easily. Then I wrote an operating model to be able to repeat it and we provided it to our infrastructure provider. He was able, really easily, to provide a production server with our operating model. It's really straightforward and easy to set up.

For Nexus Repository Manager the process was done via a number of steps. First, we deployed a Nexus OSS and then we deployed Nexus Pro. For both steps, it took about one year to deploy it for the whole company. Regarding Nexus IQ, it also took about one year to be deployed because we started by selecting the tool from among the different tools that were available in the market. Once we decided on the tool, we took some time to test it deeply and then we deployed it.

We use a bottom-up implementation approach. We address the requests made by the business and R&D teams. Our implementation was done following this process, meaning that the development team raised a new requirement to be able to manage and share components. We then studied the different products that were available in the market. After the research, the implementation was to do it in an integration server to be sure that the application could be set up with our constraints and used properly by the teams. Once there was approval that the application could be used by all the teams, it was deployed into production. The implementation was the same for both Nexus Repository Manager and Nexus IQ.

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.

When I started with Nexus, I thought the setup was complex, but nowadays I think it's quite straightforward.

When I first implemented it, I really needed to gather the basic idea of the repository server, and the guys at Sonatype were quite supportive, getting the system set up initially. Now that I know the mechanics, it was quite easy to first perform the migration from version 2 to 3, and I'm really confident that it wouldn't be that hard to perform another setup or to even get any other operator here in our company. I'm really confident in the use and setup of the system.

The initial deployment started off with reading the documentation and then getting things done. It took about two to three days to get to production-ready deployment, including getting all the machines running here our company and IT requests, which were simply waiting time.

When we upgraded from 2 to 3, it was a journey of three hours or so.

For the initial deployment, our strategy was to first have it in our main location. We wanted to provide a demo setup with one instance and this became the de facto leading, master repository. Later on, we recognized that due to some inefficiencies and VPN problems, it would be better to create local instances of the Nexus installation. We then ported the leading system to the other locations and provided a proxy between all those instances. Right now we have three separate instances in different locations and they all proxy each other, so if one of the VPN connection fails, the other two should still be available.

The deployment required me, as the application owner and, for some operational stuff, like repository creation and artifact maintenance, about four backup persons who are capable of replacing me.

The maintenance takes about two hours a month. Upgrading from one version to another takes a few minutes. I really would appreciate a live update with zero downtime, but that's currently not on the roadmap, as far as I know. It will be there eventually.

The initial setup is straightforward.

The complexity of the setup varies depending on the type. The LFS type was essentially a three. Other repo types were a ten.

The deployment process was very simple, taking only a few hours.

The initial installation of the Sonatype Nexus Repository is straightforward.

The initial setup is simple if you have access to container images. It is a seamless process for upgrading as well. Everything is well documented on the vendor’s official site. They form regular maintenance to comply with organizational requirements. They have a good maintenance process for updating and addressing issues. We have a team of 100 executives working on the current project to maintain components.

The setup was very easy. The deployment took somewhere between 30 minutes and one hour. The install takes about 30 minutes and the rest is the upgrade process. The time for upgrading depends on the data, if there have been multiple changes. But the deployment process should not take more than a half hour, and that's on the high side.

The initial setup is simple if you are a small organization, if you're setting up one instance.

If you want to make this reproducible, for instance, you want to make templates to be able to offer the ability for an entire community to deploy their own instances on demand, then it becomes much more complex. One of my colleagues had to deal with this, and he has written a paper about the problems that he encountered that he wouldn't have encountered with other products like GitLab or other commercial products. 

For a single instance, it's a perfectly easy and comfortable process. If you want to scale up it's more difficult.

Our deployment took a year, but it was not due to technical problems. It was more like scheduling delays and organizational changes. In total, it took three or four weeks to get something working and be ready to offer it to the organization.

In terms of an implementation strategy, we rely on OpenShift. It's a Red Hat product, and now I think it has been acquired by IBM. But it enables your community to request a new service on demand. Our strategy was to make a template out of Nexus 3 for OpenShift, so that we could then make it available to all our users and developers for their own purposes. Then we had to ensure that it integrated well with our enterprise resources, authentication servers, or single sign-on facility. That took some effort.

After that, when we talk about strategy, OpenShift dictates, more or less, the strategy you have to adopt to make it available to your users. You're quite well-guided by OpenShift to on what to do next. Now the template is available to all users. They can just go to the catalog of templates, click on Nexus 3, and they get an open-source instance.

I wasn't here when they did the initial setup, but they did it in a slow manner. They started off with a proof of concept. It took at least a year. It was easy to install on the servers, but the politics and building up users took six months.

It looked like the implementation strategy they came up with was to do the proof of concept, then get some projects to start, and grow it slowly until the value was seen. And then they forced everybody, so they had no choice but to use it.

Nexus is pretty straightforward. It's not complex. We didn't have any issues. The deployment took a couple of hours from start to end.

In terms of an implementation strategy, we started off pretty simply, just setting up a server, making sure that the server was connected to the internet. We then pulled everything from down from the internet and set up the Nexus server. We then gave proper access to the developers who wanted to use it.