My organization has been using Nexus for a few years. We are now finding ourselves in a position where we would like to setup guidelines for new teams being onboarded and set of norms to apply to the existing teams. Would anyone be able to provide insight on what their organization does as far as managing snapshots/releases? Are there restrictions/limitations that have been put in place to help with administration of the application? Are there guidelines being recommended as to file sizes to be uploaded or how often are artifacts in the snapshot to be cleaned?
We do not have everything structured yet to where we want it, but we have set some standards to help control items and ensure common configurations throughout our organization. Please be aware that we are a Global company and have quite a few Products/Projects going at the same time with their own repositories and their own way of doing things. We strive to get everyone at least configuring their environments in a similar way to ensure ease of support, etc.
We standardize our naming conventions for Groups, Release, Snapshot and 3rdParty repositories.
We do this by providing an example settings.xml for users to utilize with a repo.id parameter set to their group name, and all repositories are set using the parameter.
Example settings.xml file contents (sorry it is not formatted correctly, but I could not get this to show properly.)
settings
…
servers
…
server
id ${repo.id}-releases /id !-- Must match with the id for releases repository mentioned in distributionManagement section of your root pom.xml file –
username XXXXX /username
password XXXXXXXXXXXXXXX /password
configuration
timeout 120000 /timeout
/configuration
…
/server
server
id ${repo.id}-snapshots /id !-- Must match with the id for snapshot repository mentioned in distributionManagement section of your root pom.xml file –
username XXXXX /username
password XXXXXXXXXXXXXXX /password
configuration
timeout 120000 /timeout
/configuration
…
/server
server
id ${repo.id}-3rdparty /id !-- Must match with the id for 3rdparty repository mentioned in distributionManagement section of your root pom.xml file –
username XXXXX /username
password XXXXXXXXXXXXXXX /password
configuration
timeout 120000 /timeout
/configuration
…
/server
server
id ${repo.id} /id !-- The repo.id (group) created on Nexus server. –
username XXXXX /username
password XXXXXXXXXXXXXXX /password
configuration
timeout 120000 /timeout
/configuration
…
/server
/servers
mirrors
mirror
id ${repo.id} /id
url https://SERVER_FQDN/content/groups/${repo.id} /url
mirrorOf * /mirrorOf
/mirror
/mirrors
…
/settings
We setup a Snapshots Group and add all Snapshot repositories to it. Then we created a Scheduled Task to run Daily and Remove Snapshots from the Repositories set with a Minimum Snapshot Count of Two and Snapshot Retention (days) of One.
We are in the process of creating and having 1 3rdParty repository that all Projects share, so we can control the 3rd party dependencies better. We have Technical Reviews of Intellectual Property to check licenses, etc. before allowing 3rd party dependencies in out products, but would like to ensure that we have a common location for those approved dependencies instead of duplicating repositories for each product. In other words, we are trying to get to 3rdParty instead of multiple ${repo.id}-3rdparty.
We are also trying to get into the position of actually using our IQ Server and Firewall policies to help control and monitor artifacts better.
We do standardize on individuals having a readonly access to Nexus for local development and build work. But build servers and automation environments have deployment access to upload Snapshots, Releases, etc. Of course, there are individuals (usually SCM Resources) on each team that have deployment and delete abilities to be able to properly support their teams if necessary. Those personnel follow other standard practices that meet SCM Best Practices and Standards as well.
Not sure how much of this helps your question or journey towards Best Practices, etc. But, this is a few things we are doing or moving towards to help us better control, automate, and administer our Nexus environments.
I hope this either helps or gets other conversations started for you.