Skip to content

Best Practices for Structuring and Naming Artifactory Repositories

The following guidelines, will enable you to ease the distributed software development process and to scale your Artifactory across global topologies. Creating the right repository structures, for any product development, plays a vital role in promoting a coherent product scaling strategy. It not only reduces overhead of random multiple repository creations, but helps teams discern the purpose of using a repository manager. The challenge is that there are no hardcoded guidelines to follow for naming conventions or creating a repository structure.

Recommend a 4 part naming structure that includes:

  • ProjectKey - AzDo project name as the primary identifier of the project (For pilot program, the project key is "crm")
  • PackageType - The technology, tool or package type being used, such as nuget, helm, maven, docker, npm etc;
  • Environment - The package maturity level is kind of different environments of your product life cycle such as "sandbox", "dev", “qa”, “stg”, “prod”, "archive". Helps in artifact promotion
  • Locator - The locator, the physical topology of your artifacts such as "local" or "remote"

This structure produces the following recommended repository naming structure that should be used throughout CRM organization: [projectkey]-[packagetype]-[environment]-[locator]

It makes things much easier when the repository name is clear, along with filled description field. Through UI, after filter options are applied, the alphabetization will place similar repositories next to one another in the Artifactory tree browser based on the significance of the components of the name.

Additional guidelines apply to the four different Artifactory repository types, that include: local, remote, virtual and distribution.

  • Local repository naming conventions are composed of two use cases.
    • CRM Org artifacts
    • Third party artifacts(when you want to store third party artifacts due to no http acccess/ method validated snapshot etc).
  • Remote repositories are either part of an Artifactory topology and their naming conventions should align with those defined for your local repositories or they are central repositories making them external and giving them slightly different naming conventions.
  • Virtual repositories are topology agnostic, so they lack locators.
  • Distribution repositories support multiple technology types and generally end with “-dist”.

When setting up your naming conventions for your repositories, the four main categories to consider are:

  • Security
  • Manage permissions at repository level
  • Performance
  • Cleanup policies should be implemented in order to ensure the highest repository efficiency
  • Operability
  • sometimes it is better to create separate repositories, with different read/write/delete permissions, in order to prevent teams from interfering with each other’s work. But fewer repositories are preferred for operability.
  • Limitations
  • The name can be up to 64 characters, and 58 for remote repositories
  • Artifactory is case sensitive, it’s a good idea to use lower case letters
  • Avoid using characters that require URL encoding in your environments, for example the ‘_’ character
  • There are a some special characters (‘/’, ‘\’, ‘:’, ‘|’, ‘?’, ‘*’, ‘”‘, ‘’’, ‘<‘, ‘>’, ‘+’, space) that are outright forbidden
  • There are also some reserved and not recommended names, such as ‘repo’ and ‘trash’
  • Appending the word ‘-cache’ is also considered reserved because it is largely used for automatically created cache for remote repositories.

Repository Layouts

CRM organization often deal with multiple projects, technologies, life cycles, and products, that may yield in multiple repositories. Proper layouts helps in

  • Automatic snapshot/integration versions cleanup
  • Deleting old versions
  • Conversions between remote and local layouts
  • Conversions between 2 local layouts when moving or copying
  • Resolution conversions from a virtual repository to its underlying repositories (where the virtual repository has its own layout defined)