Repository Management with Nexus
10.1. Introduction
If you release software, you will often need to test a release before deploying it to a production system or an externally accessible repository. For example, if you are developing a large, enterprise web application you may want to stage a release candidate to a staging system and perform a series of rigorous tests before a release manager makes a decision to either return a system to development or deploy a system to production.
The Staging Suite in Nexus Professional allows an organization to create a temporary staging repository and to manage the promotion of artifacts from a staging repository to a release repository. This ability to create an isolated, release candidate repository that can be discarded or promoted makes it possible to support the decisions that go into certifying a release, while the certification process is done on the same binaries that will ultimately be released.
Without the Staging Suite, when a developer deploys an artifact to a hosted repository such as the Release repository, this artifact is published and immediately made available - there is no oversight, there is no approval or certification process. There is no chance to test the artifact before writing the artifact to a hosted repository. If there is a mistake in the release, often the only option available is to republish the artifacts to the release repository or deploy a new version of the artifacts.
While this is acceptable for some users, organizations and enterprises with a QA cycle often need a temporary storage for potential release candidates: a staging repository. With the Nexus Staging Suite, an organization can automatically stage releases to a temporary repository which can then be used to test and certify a set of artifacts, before they are published to a final release repository. This temporary repository can then be promoted as a whole or dropped depending on the results of testing. When used the binary artifacts being tested and certified are the identical artifacts that will ultimately be released and not a clean fresh build kicked off after the certification finished as is often the case without a staging suite being used.
Here’s how staging works in Nexus Professional:
- A developer deploys an artifact (or a set of artifacts) to Nexus Professional
- The staging suite intercepts this deployment and determines if the deployment matches for a staging profile
- If a match is found a temporary staging repository is created and the artifacts are deployed to this repository.
- Once the developer has deployed a set of artifacts to Nexus, they will then "Close" the staging repository.
- The Staging Suite will then add this temporary staging repository to one or more Target Repository Groups.
Once the staging repository is closed and has been added to a target repository group, the artifacts in the staging repository are available to Nexus users for testing and certification via a repository group. Tests can be performed on the artifacts as if they were already published in a hosted repository. At this point different actions can be performed with the staging repository:
- Release
- A Nexus user can "release" a staging repository and select a hosted repository to publish artifacts to. Releasing the contents of a repository publishes all artifacts from the staging repository to a hosted repository and deletes the temporary staging repository.
- Drop
- A Nexus user can "drop" a staging repository. Dropping a staging repository will remove it from any groups and delete the temporary staging repository.
- Promote
- If your Nexus installation contains Build Promotion profiles, you will also see an option to "promote" a staging repository to a Build Promotion Group. When you promote a staging repository you expose the contents of that staging repository via additional groups. Build Promotion profiles are explained in detail in the next section.
Figure 10.3. The Stages of a Staging Repository starting with Deployment and Ending with a Release or a Drop of the Repository