My Assumption: Most of us don’t read documentation…

Based on my experience, I’m going to guess that most of us likely just dive into implementation when it comes to new tools and libraries. Even though one of my focuses is documentation, I’m only assuming that 20% of you read anything in the book prior to install. Sonatype understands this and with every Nexus release our engineers and product managers are trying to implement new features to be as straightforward as possible.

This isn’t to say that we’re no longer writing documentation. Documentation is essential when you are setting up critical, enterprise-grade development infrastructure. In my time consulting and training I’ve seen some really “interesting” builds that have developed from what I’m calling the “Just Dive In” approach: what happens when an organization adopts a tool before it understands what the tool provides or even what it is. What happens when you never take time to learn about a tool.

The “Just Dive In” Approach

This is a common malady for programmers, and we’re almost all guilty of this approach at some point in our career. Someone tells you to check out Hudson or Maven, you read some of introductory articles on DZone, and you immediately dive in. Even though you might only have a rudimentary grasp of the tool, you’ve converted your build over to Maven and Nexus. It’s full of duct tape because you didn’t fully grasp the Maven lifecycle, or you don’t use snapshots because you didn’t have time to learn about the differences between release and snapshot artifacts.

Note: I’ve been there. This is how busy developers adopt new technologies. You adopt a new technology like Spring or a new web framework by doing. Having time to read a full length book on a new technology is rare. My own theory is that it always takes two attempts to adopt a new technology with the first attempt being a dress rehearsal full of mistakes and missteps. So back to our example…

Maybe you make a mental note to purchase the book or take a training course on the technology… later, when the project calms down, but time moves quickly these days. Deadlines and meetings multiply and suddenly you find yourself unable to take some time out to really learn Maven or Nexus. All of a sudden your half-baked prototype become a production dependency.

Hoping you can swim…

As a consultant this is usually when someone calls me up and needs some emergency help. They migrated to Maven (or they set up Nexus) but they didn’t take a day to start from the fundamentals. A product deadline is approaching and someone needs to do the equivalent of open heart surgery on a non-standard build in the matter of days. Often the changes that need to be made to fix a build full of bad assumptions and introduce more compromises and workarounds. This is expensive, last-minute work that could have been avoided with training.

While most of us don’t read documentation, I think it is up to managers to make sure that someone in the organization has a grasp of the fundamentals from the very beginning. That’s my cue to tell you about our Nexus training class, it’s a comprehensive introduction to Nexus best practices and it walks you through the decisions you’ll need to make *before* you introduce a repository manager into your architecture. (Let’s see that’s a couple hundreds dollars vs. the price of an emergency consulting engagement – if you have a complex environment, I’d recommend the training first.)

Conclusion: Check out that pool before you dive in…

This rapid adoption trend has become more apparent in the last decade. As an industry we’re trying to create developer-facing APIs, tools, and frameworks that are simpler to adopt and use. While you should be able to get up and running with an evaluation of Nexus or Maven in a few minutes, we can’t let this simplicity keep us from a fundamental truth. When you don’t set aside enough time to learn a new build tool or piece of development infrastructure you end up with these half-migrated disasters that end up having to be rewritten often at the last minute.

If you want to avoid this situation, set aside some time to understand products before you dive into a production implementation. Understand the fundamentals of repository management and dependencies before you implement an enterprise-class build and Nexus deployment. Resist this urge to just get started and read the introductions to some of these books we’ve invested in before you start implementing a deployment. It’ll save you time and money, I promise.

Join us Tuesday, February 21 at 11:00AM (GMT-0500) for a 30 minute demonstration of Nexus 2.0, with Jason van Zyl, Sonatype Founder & CTO. You’ll see all the new features and learn how Nexus 2.0 will help you:

• Avoid downtime by using a highly available architecture
• Improve repository management with enhanced component information
• Standardize on a single repository for .NET, Java, and OSGi

Reserve Your Seat

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

In this post, I focus on storage requirements for Nexus. I discuss general recommendations and point you at resources we’ve developed to help you come up with accurate estimates for how much disk space you’ll need.

Disk Space

Disk space is going to be the critical parameter for a Nexus installation. At its core, Nexus is simply a collection of files and a set of services to index and serve these files. If you integrate Nexus into your development process and come to depend on it as a collaboration mechanism, you can easily consume hundreds of gigabytes (or even terabytes) of space.

Coming up with a simple guideline for storage requirements is difficult as it depends on a number of factors: How many projects do you have? How large are the artifacts being deployed to Nexus? How frequently are these artifacts deployed? and How long do you keep your releases? How much open source are you consuming from Central? How often do you update external dependencies? and How many 3rd party artifacts do you need to upload?

If you deploy artifacts to Nexus, your internal, hosted repositories are what will end up consuming the most space over time. At a large organization with hundreds of projects and frequent releases, it is very easy to create systems that consume a surprising amount of space. If you are interested in diving into the details and coming up with an estimate for your organization, watch “Getting Scientific about Sizing Nexus”.

An Initial Starting Point

While some of our engineers like to aim high with an initial recommendation of 250-500 GB, I like to aim a little lower. Sure, if you are rolling Nexus out to a 5,000 developer installation with thousands of projects, you may very well want to start with 1 TB. On the other hand, if you are gradually rolling Nexus out to a department or two, you should start with a more reasonable number: 50 or 100 GB.

I recommend starting with 50 or 100 GB, and I also recommend being prepared to expand that number as needed. Starting with this smaller number avoids the problem of procuring a huge chunk of disk space only to watch it sit idle for the months (or years) it will take you to consume all this space. Aim low, plan to expand.

Conclusion

Your initial estimate for disk space consumption is going to be just that, an estimate. Having set up scores of Nexus instances for organizations of all sizes, my experience has been that you’ll want to do some ballpark estimates and then multiply that estimate by a factor of two or three. When you connect systems like Hudson to Nexus and deploy snapshots from every integration build, you’ll appreciate the extra space.

As you start to use Nexus, you’ll have to tweak your scheduled jobs to make sure that you are periodically removing old snapshots and regularly keeping an eye on storage. If you expand the number of projects or developers using a Nexus instance, you’ll want to revisit some of these initial estimates and make sure that your system has enough storage to keep track of all the artifacts it is caching and storing.

Sometimes Releases are Disposable

For example, consider a company that creates a large web-based system. They may deploy new versions of components to production multiple times a day. If this seems unrealistic, know that system administrators for popular services like Facebook, Last.fm, and Flickr have talked openly about how frequently code is pushed to production systems. A few times a day isn’t odd in some of these environments, and with a large system, you’d consume terabytes of space to keep all of those old releases around.

Last time I worked at a large consumer-focused web site, pushing something to production once a day wasn’t uncommon, and even the idea of rolling back to anything other than yesterday’s build was laughably impractical. If you identified a bug in a CMS or a production database, you’d just craft the fix it and move on. This is especially true of larger, web-facing systems in which the only reality is the code that is running in production today. A site like Flickr gains nothing from being able to roll back to a release from last September.

The Other Side of the Coin: Releases are Forever

Compare this to the production release schedule of a critical, supported product and it’s like night and day. If you are coding some serious banking system you might be lucky to have a release once a month. In all likelihood you might be looking at a quarterly release.  When you are working on critical applications, ship software, or have infrequent release cycles then the ability to roll back to previously released binaries is very important. When you work somewhere fast-paced with a very short release cycle, there’s not much value in retaining older releases.

For this reason, we’re clarifying this point: if it makes sense for you to delete release artifacts from a hosted repository, go for it. Just remember to re-index the server once you’ve manipulated the storage folder.

We put together the following video to share more of our thoughts on this topic.

• Integrated security and licensing reports to discover problematic components
• Improved availability with our new Nexus Availability Architecture
• Ability to manage both Java and .NET components from a single repository

The webinar recording is now available here.

Special pre-release pricing is available for Nexus Pro 2.0. Check out the webinar or contact a representative for more information.

Want a preview of everything coming up in Nexus 2.0? Join us on Wednesday, November 30 at 11AM EST (GMT-0500)  for a 30 minute sneak preview. You’ll see how Nexus 2.0 will let you:

• Manage BOTH Java and .NET components from a single Nexus repository
• Increase artifact control and reduce risk with integrated security and licensing information
• Improve availability and performance with our new Nexus Availability Architecture

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

Reserve Your Seat

Nexus Best Practices will give you the knowledge and practical instruction to get the most from your Nexus repository. Take this class to get up to speed quickly, gain better control over your component usage, and see faster build times.

This virtual class is ideal for individuals and teams who are looking to get up to speed with Nexus quickly. It is also appropriate for existing Nexus users who are interested in gaining a greater understanding of the fundamentals, as well as advanced techniques and tips and tricks.

After this course, you will:

• Understand all of the benefits of using a repository manager
• Be proficient with installation and maintenance of your Nexus instance
• Use the Nexus user interface effectively as both a user and an administrator
• Support Nexus as a key component of your enterprise development infrastructure
• Gain control over the artifacts that can be proxied from external Maven repositories
• Understand how to use Nexus to support staged releases

Our first class is scheduled for Thursday, October 20 from 11:00AM-5PM EDT (GMT-0400).

Enroll today

Learn more

Stop Running Tasks

You can stop running processes immediately and no longer have to wait for them to complete.  This is quite useful for recovering from high load situations.  Stopping a running process is easy — just select the process and click on the cancel button (see Figure 1). You can also delete tasks without waiting for them to finish. Delete will automatically stop the process and then delete it.

Improved Maven 2 Support

You’ll get improved support for environments with both Maven 2 and Maven 3 clients. Nexus now suppresses Maven 3 metadata automatically when communicating with Maven 2 clients. This improvement allows you to use such mixed environments successfully.

Enhanced User Information

Sonatype Pro for Nexus customers can better audit who uses each Nexus server with usage information that includes userid and user agent.

Download Nexus Today

So what are you waiting for, download the latest version of Nexus OSS  or the professional version from our support site.  Learn more about Sonatype Pro for Nexus.

Figure 1. Stop running processes easily with the new cancel button

“We will be moving data centers and want to setup another Maven2 repo that is managed with Nexus OSS. We want both repositories to be online and read\writeable until we migrate all our environments to the new site. I have a few questions:

1. What is the best method for copying the repo to the new location?
2. What is the best method for keeping the two repos in sync? We want to minimize network bandwidth usage.”

The video below answers these questions, and offers multiple solutions: