Industry standards/Best Practices

post by mahmad26 on Oct 15, 2018

Hi,

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?

4.0k views

post by john.burrows on Jul 26, 2019

Hi mahmad26,

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.

1. 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>

2. 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.

3. 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.

4. 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.

5. 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.

John