Ning

Company profile

Industry: Internet Software and Services
Location: Palo Alto, CA
Web address: www.ning.com

Customer Logo Ning

Moving Ning Development Infrastructure from Artifactory to Nexus Professional

By Kate Ebneter

Who:

Kate Ebneter is a Build Engineer at Ning, and in her everyday job she is responsible for maintaining the development infrastructure serving more than 50 developers distributed over various locations. In this guest post on the Sonatype blog, Kate shares her experience migrating from Artifactory to Nexus Pro.

Why:

A few years ago, we started out using Artifactory because it was readily available, free, and supported most of what we needed from a Maven repository in terms of security and permissions for developers.

It served its purpose for a while, but soon we reached the point where Artifactory was no longer enough. Our biggest concern was that Artifactory didn’t permit developers to deploy any artifacts they needed during their work, while still protecting our official builds by restricting which artifacts the builds had access to.

In search of a better solution, we started by looking at the open source version of Nexus, but it didn’t have this capability as well. After examining Nexus Pro, it became clear to us that it was definitely the way to go when we required that capability.

In addition to Nexus Pro's procurement capabilities, we especially liked that the artifact "database" is just a file system. This makes backing up of the artifacts very easy, makes recovery from various problems easier, and allows access to the "database" in other ways beside via the repository manager as well.

The migration:

Well in advance of the migration, we configured our DNS to use the names mavenrepo/artifactory and mavenrepo/nexus to facilitate the changeover. We had originally intended to use an httpd front-end to the server to make the old Artifactory URLs point to the appropriate new URLs. As it happened, we didn’t do this, although Nexus access is proxied through an httpd server to simplify the URLs.

At the time of the migration, we had approximately 133GB of artifacts in our local repository, not including proxied artifacts from the Central Repository and other locations. The process was much simplified by the Nexus Pro migration plugin. Of course, we wanted to have the Artifactory repository available as much as possible while we were importing into Nexus Pro, to ensure that our developers could continue to work uninterrupted. The process we worked out to ensure failsafe transition looked like this:

  1. Shut down Artifactory.
  2. Create a complete copy of our Artifactory instance on another server.
  3. Restart Artifactory with all deployments disabled (to prevent adding any more artifacts!)
  4. Using Artifactory’s artadmin tool, export the contents of the Artifactory database, creating a dumpExport directory with the full contents of the export.
  5. In parallel with steps 1-4, install Nexus Pro and the Artifactory import plugin on the Nexus server machine.
  6. Fire up Nexus Pro.
  7. Copy the exported artifacts from the export server to the Nexus server and import them into Nexus Pro.
  8. Configure Nexus Pro proxy repositories (about a dozen, in our case, and very easily done).
  9. Shut down Artifactory. (For good!)

Post-migration:

Because we had encountered some difficulties configuring Apache httpd to rewrite the URLs, we decided to simply update our base POM; this did, however, require everyone using it to upgrade as well. In fact, this migration is still ongoing as less-frequently used projects encounter the need.

All developers had to change their settings.xml files as well, which was expected and went smoothly.

We haven’t set up the procurement repository yet, but are planning to do so some time in the future.

At this time, we’re very happy with the performance of Nexus Pro and haven’t had any issues with it so far. As the administrator, I really appreciate the simplicity of the user interface for uploading new artifacts that don’t reside in the any of the central Maven repositories, and the flexibility of the permissions is impressive.

Overall, my only regret about the migration is that we didn’t do it sooner!