Overview
Integrating a single source of truth for all your commercial and open source binaries, artifacts and dependencies can be a big task, but the rewards in terms of a faster build and release cadence, higher developer efficiencies and component re-use across projects are worth it. These best practices, learned from customers, will provide you with the workflows for successfully integrating and scaling JFrog Artifactory into your development lifecycle.
Onboarding JFrog Platform - Artifactory Best Practices
1. Repository design characteristics
One of the fundamental design characteristics for your universal binary repository structure is the placement of local, remote and virtual repositories.
Repository Types
Local repositories are physical and locally managed, while remote repositories are caching proxies of a remote server. To improve developer efficiency, remote repositories will attempt to resolve the artifact from the remote server and then store that artifact in the local cache for future requests. Virtual repositories simplify search and build processes by aggregating local and remote repositories under a single URL. Once set up, some customers prefer to only have virtual repositories visible to developers and projects.
Package Type Mirrors Repository Type
Within JFrog Platform there are over 25 different package types available to integrate into your development environment. Each repository is constructed for one defined package type. For example, for Maven package integration, create a Maven repository structure. When adding another package type, for example Docker, then create a separate Docker set of repositories to mirror your development lifecycle, and repeat to support all the development environments across your organization. The one exception is the package type Generic, which can accept any file format.
2. Naming conventions and structure
JFrog recommends a 4 part naming convention to scale and manage your global repositories. As shown, this includes:
<team>-<technology>-<maturity>-<locator>
A product or team name as the primary identifier of the project.
The technology, tool or package type being used.
The package maturity level, such as the development, staging and release stages.
The locator, the physical topology of your artifacts.
Creating Artifactory repositories per team, or folders inside repositories, enables each team to handle their specific vulnerabilities.
Note
See the complete whitepaper, Best Practices for Structuring and Naming Artifactory Repositories, for further descriptions of the use cases and configurations to optimize your development environment.
3. Create a repository structure that mirrors your development life cycle.
Repository Structure
Create a repository structure that mirrors your development life cycle in order to support an intuitive promotion of the artifact across different stages in the CI. A classic 4 stage development life cycle such as; development, test, staging and production would have 4 repositories:
yourcompany-docker-dev-local
yourcompany-docker-test-local
yourcompany-docker-stage-local
yourcompany-docker-prod-local
Publish Build Artifacts with Tags/Metadata to Each Stage of the Development Lifecycle
Instead of deploying artifacts into a quarantined area, JFrog Artifactory simply tags artifacts with metadata.
With promotion properties in place, you can set permissions that apply to artifacts tagged with properties that represent different stages. We can automate this using dev tool integrations as we deploy from one stage to another.
Then the artifacts will be published to a repository that grants access to users with roles relevant to that stage, like testers for example.
Using REST API, you can automate many of the tasks involved in build promotions.
Note
Learn more about getting started with Artifactory as a Docker Registry, for cloud or self-hosted.
Visit the JFrog Resource Center for additional screencasts of workflows and community help to integrate JFrog into your development ecosystem.