There are two main use cases for the Procurement Suite. In the first use case, the Procured Release Repository, the Procurement features of Nexus Professional are used to create a procured release repository to make sure that the organization has full control over the artifacts 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.
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. A procured repository is one which only serves the artifacts 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) artifacts 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 artifacts, create a hosted repository, turn on procurement, populate the repository, and then deactivate procurement. This has the effect of "locking down" the artifacts that are involved in a production release.
There are some development environments which require even more control over which artifacts 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 artifact, or group of artifacts so that they would be made available to the developers. This is the "ask-first" model for organizations that want to control which artifacts 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 artifacts can be referenced by a large development team.
