Tools like JFrog Artifactory are examples of universal artifact management repositories.
They're basically centralised stores you control for all your binary artifacts (packages, libraries, container images, build outputs, etc) that your software projects produce, or just depend on.
They have a number of use cases. For example, your build process may produce different binaries you need to deploy to users, a live environment, or that are depended on by other processes you have. An artifact management repository can host, and in theory serve those files as needed. And that allows you to be fully in control of their distribution - this may be useful for security-critical projects, where you want to host both your own binaries, and also mirror external dependencies, rather than pulling them in from the internet.
So, they're useful tools, though they may be overly complex for many projects, or missing some key features relating to binaries which are specific to app based projects (whether mobile, desktop, game, or embedded), as we will explore.
First, a quick overview of the biggest artifact management repository tools.
The most widely used example of an artifact repository manager. Supports a wide range range of the most widely used package repostory formats, including npm, PyPi, rpm, etc. Also has a number of DevSecOps integrations.
Another prominent tool, with near as much format support as Artifactory, and similar in design.
A more modern alternative, with a limited free plan (in contrast to Artifactory or Sonatype). Does have slightly more limited repository format support.
A self-hosted option with a freemium model.
When it comes to serving artifacts via package repositories like npm, there are a number of further options to consider, which may be more limited in functionality or format support but also more accessible for many teams:
- AWS CodeArtifact
- Azure Artifacts
- Google Cloud Artifact Registry
- GitHub Packages
- GitLab Packages
- Buildkite Package Registries
- Pulp
- Harbor
All of these options, whether universal artifact management repositories like Artifactory, or more narrowly focused package hosting tools like GitHub Packages, are heavily focused on serving your artifact via package repositories.
For many application types or use cases that makes sense, but what about:
- A mobile app being published to the App Store, Google Play, F-Droid, or internal/beta distribution
- A game being published to Steam, or a games console
- A desktop app being published direct to users or via OTA updates (in instances where a Linux package manager isn't being used)
- Embedded firmware with custom deployment, OTA updates, etc
In all cases you do have binary artifacts from your build processes which it would be great store, manage, and version - but they're not packages you would traditionally serve by a package repository.
Artifactory specifically does have a catch-all "Generic" repository type which you could in theory type any binaries into, but its clearly not designed particularly with app, game, and embedded projects in mind.
Further, if we imagine what a binary artifact management specifically designed for those projects could look like, we can imagine a completely different set of features and workflow which tools like Artifactory just don't offer:
- Internal/beta distribution of apps for mobile, XR, wearables, etc
- Collaboration around builds during an app development workflow
- Deployment to distribution platforms like the App Store, Google Play, Steam, or application specific feeds or repositories like Sparkle, Squirrel, F-Droid etc (as well as apt, rpm, and so on).
An alternative to consider specifically designed with app, game, and embedded projects in mind is Buildstash. Buildstash looks to be a store for all of your binary artifacts - similarly connecting to CI/CD tools and your build workflows - but while actually focusing on how software teams working on these types of projects collarate, distribute, and publish their applications.
For example, Buildstash includes integrated beta distribution capabilities for platforms like iOS and Android, replacing functionality teams would have used to have to get from a dedicated tool (like the now defunct Visual Studio App Center).
Further, its focus on how teams collaborate around builds mean it has a big focus on build context - where did the build come from, what open bug reports and issues relate to it, has it been signed off by QA, etc.
And lastly, it has a focus on deployment and distribution for app, game, and embedded projects - whether targeting stores like Google Play or Steam, or publishing directly to users via distribution groups or even a page on your own website.