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 Repository Manager allows an organization to create a temporary staging repository and to manage the promotion of components 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 a component to a hosted repository such as the release repository, this component is published and immediately made available, having no oversight, no process and no certification process. There is no chance to test the component before writing the component to a hosted repository. If there is a mistake in the release, often the only option available is to republish the components to the release repository or deploy a new version of the components.
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 staging suite, an organization can automatically stage releases to a temporary repository that can then be used to test and certify a set of components, 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 components being tested and certified are the identical components 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 Repository Manager:
- A developer deploys a component (or a set of components) to Nexus Repository Manager.
- 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 components are deployed to this repository.
- Once the developer has deployed a set of components, 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 components in the staging repository are available to users for testing and certification via a repository group. Tests can be performed on the components as if they were already published in a hosted repository. At this point different actions can be performed with the staging repository:
- A user can "release" a staging repository and select a hosted repository to which to publish components. Releasing the contents of a repository publishes all components from the staging repository to a hosted repository and deletes the temporary staging repository.
- A user can "drop" a staging repository. Dropping a staging repository will remove it from any groups and delete the temporary staging repository.
- If your repository manager 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