Repository Management with Nexus
9.3. Two Approaches to Procurement
There are two main use cases for the Procurement Suite. In the first use case, the Procured Release Repository, the procurement features are used to create a procured release repository to make sure that the organization has full control over the components that are making it into a production release. The other use case, the Procured Development Repository, is for organizations that need more up-front control over which artifacts are allowed during the development of a project. The following sections describe these two uses cases in more detail.
[[procure-sect-cert]] ==== Procured Release Repository
The Procurement Suite can be used in two different ways. In the "Procured Release" mode, developers work with a proxied 3rd party repository exactly as they would without the Procurement Suite. When a developer needs to add a dependency on a new artifact, Nexus will retrieve the artifact from the third-party repository (like Central or Apache Snapshots) and this artifact will be served to Maven via a proxied Nexus repository. When a QA or Release engineer needs to build a release or staging artifact, the Release or QA build would be configured to execute against a procured repository or repository group with only approved and procured repositories. A procured repository is one which only serves the components which have been explicitly approved using the Procurement Suite.
In this model, developers can add as many third-party dependencies as they want, and it is the responsibility of the QA and release engineers to approve (or procure) components from the development Repository to the QA/Release repository. Developers can move forward, adding dependencies freely from a third-party, proxied repository, but once it is time to populate a release repository, a Nexus administrator can audit the required components, create a hosted repository, turn on procurement, populate the repository, and then deactivate procurement. This has the effect of "locking down" the components that are involved in a production release.
There are some development environments, which require even more control over which components can be used and referenced by developers. In these situations, it might make sense to only allow developers to work with a procured repository. In this mode, a developer must ask a Nexus administrator for permission to add a dependency on a particular third-party artifact. A procurement manager would then have to approve the component, or group of components so that they would be made available to the developers. This is the "ask-first" model for organizations that want to control which components make it into the development cycle.
This is a model common in industries that have strict oversight requirements. More often than not, banks, hospitals, and government agencies have fairly strict regulations on the software that can be used by large development teams. With the Procured Development Repository approach, an architecture group can have full control over what components can be referenced by a large development team.
In a typical usage a software build relies on approved components that have successfully passed procurement and as well as additional components that have been authored internally in the organization and are available on Nexus as well.
In order to use a combination of such components together with the procured component, you should set up a a repository group that contains all repositories with pre-approved components as well as the procurement repository. E.g. the release and snapshot repositories could be added to the group, based on the assumption that any internally authored components deployed there are automatically approved. In addition you could add the 3rd party repository, if all uploads to it are done with prior approval of the specific components.
Once this repository group is set up, you can reference it from any tool just like the public group e.g. in a separate settings.xml used by builds that can only have access to the approved components.
Ensure to run clean builds without any components in the local repository of the build to ensure that only approved components are used in the build.