Wondering what’s new in Nexus? Just ask the experts.

We’re hosting another Nexus Office Hours this Friday, on Google+ Hangout On Air. Our Nexus experts Brian Fox, Manfred Moser and Rich Seddon will demo the latest in Nexus and dedicate most of the hour to Q&A time with you!

How to join: No registration required, just RSVP on Google+, and the event will appear in your calendar. You can join through your calendar invite or by returning to the event page at the start of the hangout. Be sure to bring your Nexus questions with you. If you can’t make it — be sure to leave your questions on the event page in the comments section and we’ll be sure to answer them during the session. That way you can tune into the recording later, and get your answers!

*Interested in joining our panel that day in the video conference? Sign up for one of the spots on our panel, by leaving us a comment on the event page and we’ll invite you in before we go live. Space is limited, so be sure to sign up early!

Please feel free to pass along this invite to your friends and colleagues.

RSVP

Please feel free to share this with your colleagues who are interested in learning how to get the most out of Nexus.

Have a great weekend everyone!

Watch the replay.

If you missed the live broadcast, the recording is now available here.

Interested in checking out our next session? Moving forward, Nexus Office Hours will be held the last Friday of every month. Join us and be sure to bring any general repository management or specific Nexus questions you may have, since we’ll be dedicating most of the hour to your live Q&A.

Join us for our April Nexus Office Hours on Friday, April 26 from 1PM-2PM EDT (GMT-0400). RSVP here.

We want to give you a sneak preview. On Thursday, April 18, 2013 from 11:00AM-11:30AM EDT (GMT-0400), Brian Fox will demo Sonatype CLM, and show you how it will help you develop faster, and still meet your company’s requirements for security and licensing. Plus, we’ll provide some tips on how you can take advantage of Nexus-only features like procurement and staging.

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

We’re pleased to announce that Sonatype will be hosting Nexus Office Hours each month starting in March! Our Nexus experts Brian Fox, Manfred Moser and Rich Seddon will demo the latest Nexus tips & tricks and will take real-time questions from you!

When: Friday, March 22, 2013 – 1:00-2:00PM EDT (GMT-0400)

Where: In a Google+ Hangout On Air! Once we begin, our hangout will broadcast live to the Nexus Office Hours event page on Google+, as well as our Sonatype YouTube channel.

How: Be sure to RSVP ‘Yes’ on the Nexus Office Hours event page, and this event will be automatically saved to your Gmail calendar and you will receive a reminder just before we start the hangout. Not on Google+? No worries, you can still view the broadcast on the event page or the Sonatype YouTube channel when the hangout begins.

We will be taking real-time questions submitted on the Nexus Office Hours event page, Twitter (please use hashtag #nexusofficehours) and on our YouTube page in the comments section of the broadcast.

**If you’d like to join our panel that day in the hangout, please leave us a comment on this page and the first 6 people will be invited in as the session starts. This event will be recorded and saved to Google+ as well as our YouTube channel.

RSVP Now

Since its release four years ago, Sonatype Nexus has grown to support many repository formats. And most users of build tools including Gradle, Leiningen, SBT and Ant/Ivy have started to realize the numerous benefits of using a repository manager.

Using an MRM has become accepted best practice for Maven users.

The benefits of proxying external repositories and deploying third party artifacts are only the beginning. Things really take off when you start deploying your internal components to Nexus, making them immediately available to everyone.

Nexus: More Than Basic Repository Management

Nexus is evolving to help you manage the security and licensing aspects of your components.  In order to show you how, we have made this a focus of the latest release of the book Repository Management with Nexus.

The book now shows you how to access Insight information for a particular artifact. There are concrete examples on how to inspect and fix security issues, thanks to the information available in your Nexus search results and the linked information on the public security databases.

Note: When you read this, don’t forget to configure your Routing correctly to ensure that aspect of your Component Lifecycle Management (CLM) efforts is covered and no information about internal artifacts leaks to the public.

Part of your effort to get control over your component usage is to secure your sources. Part of that effort is to start using the Central Repository via secured access.

If you are using Nexus Professional this is as easy as upgrading to 2.2 and changing the Remote Storage Location URL. It is also available now for Nexus OSS by getting a $10 token here and making the same changes. Other repository managers will be supported soon.

Nexus 2.2 Now Included in Nexus Book

We have also made improvements and general updates to cover the latest Nexus 2.2 release. Among the topics changed are settings.xml setup explanations, documentation for capabilities, updates to the plugin creation chapter and many more.

Still, with all these improvements we realize that nothing is perfect and you might have questions or ideas for enhancing the book. If that’s the case, we encourage you to file issues with your wishes or attend one of our Nexus training classes. Also, don’t forget that the book is open source and we do take fixes as pull requests.

Component Lifecycle Management is Key

These improvements to Nexus are part of a larger Component Lifecycle Management solution that is provided by Sonatype. CLM helps you ensure the integrity of component-based software by analyzing usage and providing governance and policy enforcement during development.

As demonstrated by these Nexus improvements, CLM is integrated directly into your development infrastructure – including IDE, CI and repository manager tool of choice.

We’re making SSL connectivity to Central available to anyone that downloads open source components regardless of the repository manager. Given the tremendous growth of Central, and the fact that modern applications are largely built from OSS components, this capability is likely to be leveraged by many organizations. SSL has become the standard mechanism for protecting web traffic – across the spectrum of Ecommerce, banking, health care, and so on. Providing SSL support for Central means that your components are no longer susceptible to man-in-the-middle attacks that could compromise the component. SSL also eliminates the potential for a hacker to gain visibility into your organization by tracking the components that you download for your development initiatives.

As of Nexus Pro 2.2 (available now), SSL is now the default connectivity option for Nexus Pro users. Because we take security of the ecosystem seriously, we aren’t stopping there, we’re making SSL connectivity to Central available to you even if you aren’t using Nexus Pro.

In order to ensure the highest level of performance for those who count on SSL, we are securing the service with a token. You can get a token for your organization simply by providing a $10 donation that will be donated to open source causes. For the first 60 days all donations will go to the Apache Software Foundation. After that, the donations will go to other open source foundations such as Eclipse. Sonatype will provide a donation on behalf of Nexus Pro customers since we’ve included SSL access to all Pro customers automatically.

If you happen to be using Nexus OSS (any version), support for the SSL token is included already. I’ve already reached out to the Artifactory and Archiva teams and they are working on the changes necessary to enable SSL to Central – we’ll let you know when that support is enabled. If you’re not using a repository manager at all, what are you waiting for?

If you are an existing Nexus Pro customer, you can download the latest release from the support page.

If you would like to make a donation to the open source community and get SSL access, you may do so here.

Some of you might be interested in using our Yum support to facilitate application deployment to staging and production networks. A lot of companies that deploy Java and other technologies end up packaging applications as RPMs and deploying them through Yum on Redhat or Centos because it provides a really easy way to manage, deploy, and rollback software packages in production. It is much easier to tell Operations to deploy RPMs than it is to draw up a series of instructions for installing Jetty or Tomcat from a tarball. To support these use cases, we’re going to invest some of our time developing more documentation and training to support developers that need to adapt applications to deployments that depend on this Yum integration.

While Nexus is primarily used to support application development, this Yum support can be used on its own as a way to cache and simplify Yum repository configuration and package data. We’ll also be building out more examples of how Nexus can be integrated with infrastructure management tools such as chef and puppet.

Features of the Nexus Yum Support

As we integrate this feature into Nexus proper, here is the current list of features. We expect this support to evolve over time, but here’s what the plugin provides now.

• Expose an existing Maven repository as an RPM repository – Use a Maven repository, hosted in Nexus, containing RPMs as if it is a Yum repository. This leverages the virtual repository mechanism in Nexus which allows you to use Maven tooling to deploy RPMs into a Maven repository but still allow Yum clients to interact with the repository using the protocol it understands.
• Automated Refresh of Repository Data – Yum repositories are automatically updated if you upload/deploy/delete a new RPM into Nexus. In a traditional RPM repository you have to run createrepo to refresh repository metadata. With Nexus this is all taken care of automatically.
• Full group support so that you can logically group a set of Yum repositories behind a single URL. If your infrastructure relies on a number of remote RPM repositories you can consolidate OS configuration to point to a single Yum repository that can aggregate multiple repositories into one.
• Versioned views on repositories: http://your.nexus/nexus/service/local/yum/repos/releases/1.2.3/ gives you a Yum repository with all packages in version 1.2.3 in repository releases. This particular feature is a game-changer for companies that release software using RPM as a delivery mechanism.
• Alias Definitions for Specific Versions eg. production=1.2 and testing=2.0 and access them via the alias: http://your.nexus/nexus/service/local/yum/repos/releases/testing/ and http://your.nexus/nexus/service/local/yum/repos/releases/production/ to get constant repository URLs for your servers. A new release is then applied to the server by setting the alias to a new version.
• createrepo Nexus Tasks Types – Create Yum createrepo tasks manually via web interface. Multiple createrepo tasks on the same repository are merged.
• Full Integration with Nexus Staging – Use Yum group repositories as target of staging repositories (Nexus Pro). Stage RPM artifacts to development environments configured to pull artifact from Nexus repository groups./li>

You can find the source for the Nexus Yum Plugin in our Github Repository. We would love your feedback as we still have time to make changes and improvements before the Nexus Yum Plugin is integrated into Nexus OSS proper.

When I roll up to a new client in desperate need of build help, there’s always a chance I’ll have a “Scotty moment” – a moment when I pick up the mouse and attempt to ask an Apple II to synthesize transparent Aluminum. (“Computer, bring up the repository and scan for vulnerabilities.”) If you don’t get the reference, I’ll walk you over to IMDB and point you towards the movie Star Trek IV. In Star Trek IV, James T. Kirk and company travel back in time to 1986 in a “bird of prey” to rescue a humpback whale which is being summoned by a mysterious alien probe in the year 2286. Leonard Nimoy directed Star Trek IV and it had a comedic “fish out of water” feeling to it that made it appeal to a wider audience.

The crew of the Starship Enterprise is thrown into a 1986 San Francisco and if you haven’t seen the movie, you can imagine that the plot was a series of “future meets past” vignettes. So, let’s go back to this scene where Scotty shows up at a materials factory. Scotty and Bones need to fabricate several tons of transparent aluminium – the container for the to-be-rescued whale. They have some discussion about the pros and cons of giving this engineer a recipe from the future and the following scene ensues:

This is my nomination for the best scene in movie history, and it is also a chance to see just how far Apple has come in 26 years. (It should also been noted that it only took real scientists 23 years to catch-up with science fiction – from Wikipedia “[A group of scientists] succeeded in turning metal transparent during research in 2012 to create quantum computers.” reference).

What does this have to do with Repository Managers?

Right, right, I almost forgot that you are here to learn about Nexus or something like that. Back to reality…

While I’m certainly not giving corporations recipes for game-changing transparent aluminium, I’m very often walking into enterprises that have no idea what they’ve been missing because they’ve been “out of the game” for about a decade.

You see, “enterprise architects” at very serious organizations often work on applications that have a decade long life cycle. When your critical banking application has been alive for 10 years, it’s very likely that you haven’t changed much in that interval. For example, I just heard of one company that wanted help migrating to Maven 3…. we can do that, but wait, they are using a heavily customized Maven 1 build (with Jelly, yikes). Moving from Maven 2 to Maven 3, no problem. Moving from Maven 1 to Maven 3, now that’s like going back in time to rescue a humpback whale.

You see enterprise architects and developers – they might only come up for air once a decade, and the rate of technology adoption is all over the map. Companies like Google and Facebook are far ahead of the curve updating a development stack every year. Yet, in other companies, say a large insurance company, it isn’t a priority to update technology more often than is absolutely necessary. In those companies, you might still be running some Cobol or a system on a very early version of the JDK. Teaching a training class at a company like that is surprising – they might not even know what Central is yet.

When you roll up to these places and start explaining the benefits of repository managers. You start by talking about dependency management… Client: “what’s a dependency?” You realize you have to go further back into the past. You: “Ok, do you guys have a CI server?” Client: “What’s CI?”… then you go even further… You: “Ok, do you use Ant or Maven?” Client: “Neither of those were available in 1999, we use gmake.” That’s when you realize you’ve crossed into the deep past, your job is no longer to guide people through an easy transition, that’s when you need to just dive right into delivering future tech.

Need to transport a humpback whale to 2286? I’ll give you the recipe for Nexus.

At this point, at these clients, it would take several days to run through the progression of the industry. These people have missed Agile, web applications, build tools, dependency management, repositories, the rise of dynamic languages atop the JVM, etc. You don’t have time to to run long seminars on how the application lifecycle has changed, what open source did to the industry, and how the nature of corporate development has shifted to smaller groups collaborating with one another using methods of communication inspired by open source projects.

Instead you just have to give them the recipe for the future. And, to me, that’s Nexus. Nexus, and repository managers more generally, this is the technology that enables software development at scale. In the late 90s, large software projects were monolithic. You checked out the entire codebase, ran a multi-hour build and hoped it worked. Teams were large and the reality of software in the 90s is that you couldn’t scale beyond a certain size (both team size and code complexity) without incurring massive management inefficiency.

With the rise of Maven Central and the ability to effortlessly distribute components, software applications have been much more modular and component-driven. When you assemble a modern web application in 2012, you already have a pre-made “warp core” in the form of the Spring Framework, and you can just add on fully tested “transporter room” in the form of MyBatis. As systems become more interoperable and more complex, component-driven development is the only way we’re going to achieve computing systems of complex.

Did you know that Sonatype’s Building the Starship Enterprise?

Just look at science fiction, and think about the software complexity of something like the Starship Enterprise. Do you think we’re going to get there by building bigger monolithic projects? Do you think we’re going to get there by building thousands of software projects each with uniquely difficult builds? Nope. Large scale technology projects are only possible if you break a system into isolated components and use some mechanism to manage and distribute those components.

This is what a repository manager does. It enables technology at scale, and once we’ve all understood this we can start building the next generation of applications and stop reinventing the wheel every time someone decides to reinvent a new way to distribute software.

Anyone have any Spock ears?

Ok, so this post has been 80% hand-waving and 20% telling you that Nexus is the answer. Maybe I’ve made my point using a bit too much grandiosity, but I’ll leave you with this…

When someone asks why Nexus is important, I answer: “Look at Star Trek. Do you think they manage all those systems with an Ant build and a bunch of WAR files deployed to Tomcat? No. Have you ever heard Sulu going on and on about some crappy Bash script that failed to update the software for the Friday patch? No. They don’t have problems because the Federation standardized on Sonatype Nexus in 2215. The Holodeck software, the transporter room management console, the phaser charging subsystem…. all of those are components and they use Nexus to both distribute software and scan it for Federation CVE vulnerabilities. You should see what we did in the holodeck for Nexus training, it’s intense.”

Start working on the future today, and go download Nexus. Also, does anyone have any Spock ears? I’m going to be Spock for Halloween.

In other words, everyone is scaling horizontally and everyone needs a repeatable, automated process to set up instances, deploy software, and perform tasks that were previously manual. Everyone seems to agree that the boundary between development and operations requires automation – it is time to stop wasting good operations and development talent on manual deployments. This trend is called Devops, and in this article I’m going to talk about where Nexus should fit into your automation effort.

DEVOPS: A Common Misconception

The first thing you’ll notice in any devops initiative is confusion. Operations “people” often lack context and see Puppet or Chef as a green light to move into the development infrastructure space. This isn’t just about taking a build and deploying it to production, ops believes that they are going to finally clean up that messy build system. For operations, the boundaries of devops often reach far into the application lifecycle: Builds, CI servers, Issue Trackers – it’s often very unclear where you draw the line between deployment automation and development infrastructure. For example, some of the questions that come up as part of a devops initiative are telling. “Can we get the Maven build to generate RPMs instead of WARs?”

If the first question in a move to Puppet or Chef is operations asking, “How do we build the application from source?” You are doing it wrong. You need to use Nexus as a integration point between Development and Operations. Otherwise, it’s get’s awful, quickly. Operations and Development start to step on each other’s toes and your devops initiative runs the risk of screwing up your development process. “We didn’t make that deadline because we had to adapt the build to this new Puppet script.”

Provide some structure to devops with a repository manager. Isolate operations from source code, and make sure that technologies like Puppet don’t start affecting your builds.

Appropriate Boundaries in Devops

Does this look familiar? Does this capture your current approach to deployment automation (or what most people call “devops”)? Do you run a build every time you have to do a deployment to production?

This is what I’ve seen in the field from over-zealous Puppet implementations. Instead of relying on build output from Jenkins, the initial cookbooks checkout source from Git, run a fairly complex build, and only then deal with deployment automation. From the perspective of development, this is wasted effort: tools like Jenkins, Hudson, and Bamboo already handle the generation of binary build output. Why go to the trouble of building something from source when the binaries are already available on Nexus? To automate builds once again in a Puppet script is duplication.

This approach also means that your operations team and the automation scripts they run have to take on the responsibility of setting up a development environment. If you start from source, your Puppet scripts have to manage dependencies, they have to know about source tags and branches, they have to incorporate much more complexity than they would need to if they just started with binary build output. If you change the build, you don’t just have to worry about all of your developers. You’ll have to trust that these Puppet scripts are building the same output that is being generated from Jenkins.

The following figure represents a more reasonable approach that separates the two concerns:

Jenkins is for Source, Puppet is for Deploys: Nexus stores the Bits in Between

Don’t start devops from source. Puppet and Chef should gather binary build output from Nexus, the same way they install RPMs or DEBs from OS-level repositories. If you need to run a deployment to a production system in Puppet, you should just be able to tell your operations team to update the version number to the latest release. Puppet and/or chef should then refer to Nexus to gather this build output.

Jenkins (or Hudson or Bamboo) should continue to be the tool you use to run both continuous integration builds and release builds. When I configure Jenkins these days I usually have a 15 minute build that checks Git constantly alongside a release build that is triggered only when I’m ready to run the Maven release plugin. In this approach, I don’t have to have a seperate “build system”. Everything is consolidated into Jenkins, and if I want the Puppet people to deploy something I just trigger a release build wait a few minutes and send them a collection of version numbers.

This is much easier than the alternative of telling the Puppet team to “run a build”, waiting for them to come back with a question about some broken build script, help diagnose that build script, realize that someone on the ops team “had a better idea” for some complier option, finally get some build output only to realize that they didn’t use the right version of Maven on the Puppet VM image that ran the build, etc. Use Puppet for what it does best, and that isn’t to trigger a build.

The Argument Goes Both Ways

Yes, I’ve seen mega-builds managed by Puppet. They are difficult to manage, and they end up starting too early in the process. When you extend tools way beyond what they focus on your systems tend to become very brittle.

On the other side of this spectrum, I’ve seen companies try to make Jenkins do everything that Puppet does and that’s also a big problem. Jenkins wasn’t designed to provide OS-level configuration management. Yes, you can use it for that. In this way, Jenkins is a bit dangerous because it can do everything, but that doesn’t mean you should use it to automate production deployments. That’s what Puppet and Chef do. Use the right tool for the job.

The lessons I’ve learned from being in several devops initiatives is that Devops is not about Developers and Administrators getting together to hold hands and value each other as co-equals in a collaborative, consensus-based process of harmony. It isn’t. The ironic fact of this trend is that devops is about drawing strongly defined boundaries between these two concerns (Development and Operations) using tools like Jenkins, Nexus, and Puppet to create more structure than existed before.

If you are looking for some structure to your devops initiatives, check out Nexus. I’ve already seen it work very well as the collaboration point between dev and ops.