Azure Artifacts helps you standardize on packages and modules

Continuous integration and continuous delivery (CI/CD) is one of the engines driving modern cloud-native development. Each time we build from the main branch of an application, we deploy it to our live systems—everything from the UI to the application infrastructure. Our builds contain many different elements, from JavaScript libraries to Bicep infrastructure descriptions to application containers, and even images, video, and audio content.

What’s needed is some way to marshal all those components and deliver them to one place, ready for deployment. Artifact management is an important and growing part of our development tools, with JFrog expanding its offerings and open source container registries going beyond Docker to all the elements of cloud-native applications. Other options include working with the .NET NuGet package registry for your own private library of regularly used packages, or using private npm instances for JavaScript.

One concept that keeps coming back is the idea of the “monorepo,” or one repository for all the code that goes into all the projects running across an organization. Everyone has access to the same internally developed libraries and all the code. The intent is to encourage organic best practices and reduce duplication, all to avoid common pitfalls and ensure that costs are controlled. This approach helps manage inner-source projects where teams aim to standardize common libraries and components, developed in-house across teams using open source approaches.

A common repository for your organization

What if our artifact repositories worked the same way, hosting common versions of libraries and components, as well as base images for our containers and VMs? That’s what Azure Artifacts is for. It works in conjunction with the Azure Container Registry, giving you a shared repository for your code and packages and a private mirror of your most used packages from major public registries and repositories. By hosting common packages and making it your default host, you now have an additional set of architectural guidelines for Python, JavaScript, Java, and .NET, ensuring that projects default to approved libraries without explicit permissions.

At the heart of Azure Artifacts is the idea of the feed. Feeds are how you organize and store packages and control access. You can mix different package types in a single feed, scoping the feeds to either an entire organization or a specific project. There’s even the option of a public feed, ideal for open source projects so that the wider world has access to your package library. One important caveat: A public Azure Artifacts feed needs to be part of a public Azure DevOps project. Private feeds are automatically created from private projects.

Configuring Azure Artifacts feeds

There are two types of private artifact feeds. You can tell the difference from the URL the service generates for each feed: project feeds include a project name as well as the organization name. If you’re using an organization-level feed, all the feeds are available from the Azure Artifacts drop-down menu. Project feeds can only be found from the Azure DevOps project in question, so users will need to know how to navigate to it. To secure your artifact repositories, either disable public projects or use the feed permission API on programmatically generated feeds.

The default is to allow any Azure DevOps user to create and administer feeds; in practice, you’re more likely to lock creation down to a group of administrators and approved users. It’s an approach that, for example, limits usage to architects as a way of enforcing coding standards. Once you’ve created a feed, you’re automatically an administrator and can control permissions and other feed settings. Users can be assigned appropriate roles, for instance, a reader who can only see and install packages or a contributor who can add their own artifacts to a feed. If you want to support working with upstream packages, these can be managed by users with collaborator permissions and by feed owners and administrators.

At the same time, you can control the views that users have: the default @local view which shows everything or the @prerelease view which includes test versions of packages to allow testers to try out builds before they’re released to the rest of the organization.

If you’re already using NuGet internally, you can use a PowerShell module to migrate your repository to an Azure Artifacts feed. You’ll need your NuGet feed URL and the target Azure Artifacts feed URL, along with any passwords. The process is relatively quick. Once it’s done, you can retarget any .NET package builds to your new feed.

Working with upstream packages

Azure Artifacts can add upstream packages to your feed. This helps ensure that your projects all run on an approved version of a third-party package. You can enable upstream sources in new feeds or add specific public repositories to existing feeds. As you install new packages using tools such as npm or Visual Studio, if you have the correct permissions, they’re automatically added to the current feed. Once a package is saved to a feed, any user can install it. The same process should help manage dependencies and ensure that all necessary packages are in a feed before your team uses them.

Azure Artifacts is part of the Azure DevOps product suite, alongside Azure Pipelines. If you prefer to buy it stand-alone, individuals and teams get the first 2GB of storage free, with additional storage priced at $2 per GB up to 10GB, then $1 per GB up to 100GB, with further reductions for up to 1TB and beyond. You may prefer the free Basic Azure DevOps plan for teams of up to five users. (If you go over that limit, it’s $6 per user per month.) Or it’s part of the fully featured Test plan.

If you hit the initial 2GB limit, you need to add Azure DevOps billing to your account. There’s a warning when you approach the limit; once reached, you won’t be able to upload any more files and may need to delete those that exceed the limit. You can track usage at both an organization and project level. One point to note is that the lowest level of granularity that the service offers is 1GB, so you may not get the detailed tracking you need, especially as it can take as long as 48 hours for file deletion to show up in your usage statistics.

Managing packages and dependencies in a large project can be a big issue, so Azure Artifacts can save time by keeping everyone on the same page. A mix of project and global feeds can ensure that everyone in an organization uses the same packages, a useful option if you’re using inner-source techniques to standardize common controls. With a very low cost of entry, it’s worth setting up a couple of feeds as an experiment before committing to a full Azure DevOps package.