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, having no oversight, no process and no 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 that 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. You will not have 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:
- A Nexus user can "release" a staging repository and select a hosted repository to which to publish artifacts. Releasing the contents of a repository publishes all artifacts from the staging repository to a hosted repository and deletes the temporary staging repository.
- A Nexus user can "drop" a staging repository. Dropping a staging repository will remove it from any groups and delete the temporary staging repository.
- 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 11.3. The Stages of a Staging Repository Starting with Deployment and Ending with a Release or a Drop of the Repository