Staging is one of the most outstanding features in Nexus Pro. It allows you to add a checkpoint before releasing software, so developers can deploy release candidates into the staging repository, testers can test the release candidates, and release managers can then choose to promote or drop a release. As we can imagine, the Nexus role for developers and testers should be different when configuring staging as one role is responsible for the deployment of staged artifacts and the other is responsible for testing and promoting tested artifacts. In this post, I will describe how to configure appropriate roles for developers and testers.
Suppose we have a staging profile named sonatype-training, and we want to create a role with which a developer can deploy release candidates to the staging repository, close staging repository, and drop it. In other words, this role will allow a developer to do anything but promote a staged repository.
First, there are two preconfigured roles we are interested in, the first one is UI:Staging Repositories, which gives access to the Staging Repositories screen in the UI. The developers need all the privileges contained in this role, except Staging: Promote Repository (create,read), because we don't want them to be able to see the promote menu.
The other role we are interested in is Staging: Deploy (sonatype-training), which gives permission to do a staged deployment, close a staging repository, and drop a staging repository. Note that this role is created per Staging Profile, so if you have a Staging Profile named my-staging, the name of the role will be Staging: Deploy (my-staging). This role should be assigned to the developers so they can perform a deployment to a staging repository.
Now we know all the necessary roles/privileges for developer to do staging work, create a role named Staging: Developers (sonatype-training). It should look like this:
Assign this role to developers so they can deploy release candidates to the staging repository, and they will be able to close the staging repository, then testers can start testing these artifacts. If the developer feels the artifacts are not ready to be tested, simply drop them. The promotion feature is invisible to them.
Now it's time to create a role for the testers. They should be able to browse and download the staging repository contents, promote staging repositories, and drop staging repositories if they feel the release candidate is not acceptable. Create a role named Staging: Testers (sonatype-training) like this:
Note that for promoting, the testers need full control of the target repository. Here I am using role Repo: All Repositories (Full Control), you can always create fine grained repository roles as you need to. Assign this role to the testers so they can promote or drop staging repositories. Testers will not be able to close a staging repository or perform a staged deployment using this role, and this separation of privileges provides for a a valuable separation between the two roles. Developers perform staged releases to a staging repository, and testers act as necessary gatekeepers who can control which artifacts are promoted from a staging repository to a hosted release repository.
In this post, I created two roles, one for developers' staging deployment, staging close, and staging drop, the other for tester' staging promotion and staging drop, but you are not limited to this configuration. Nexus is designed to have flexible privileges for each feature, so you can trim these staging privileges to create roles that fit your own organization's software process.
