Nordlicht Reisen GmbH, a fictional travel agency, is building its own library with pricing rules for its booking portal. Two teams need it, and a third also uses packages from nuget.org. So far, someone copies the DLL into the repositories. You are to decide where the packages live, who may see them, and how a package is only "released" after it has been tested.
The exam names two skills: recommend package management tools and design feeds and views for local and upstream packages.
Prior knowledge: K3, lesson 3.7.4 already teaches SemVer, the version from a Git tag with MinVer, your own package with dotnet pack, feeds in GitHub Packages and Azure Artifacts with views, upstream and retention, central package versions and package source mapping. This lesson does not repeat that. It starts with the comparison of the two worlds and with the decisions for a team. How to choose a version and the order of versions follows in lesson 3.2; for large files as a package instead of in the repository, see lesson 2.3.
Two worlds, one purpose
A package is a versioned, immutable unit that a team or a project pulls in. A feed is the place where packages live. Microsoft describes Azure Artifacts as a way to manage all dependencies in one feed; feeds store, manage and share packages within a team, across organizations or, for existing public projects, publicly on the web.
| Azure Artifacts | GitHub Packages | |
|---|---|---|
| Package types | NuGet, npm, Python, Maven (and Gradle), Cargo, Universal Packages | npm, RubyGems, Maven and Gradle, NuGet, Docker and OCI images (Container registry) |
| Where it lives | in an Azure DevOps organization, in a project or in the organization | on a repository or an organization at GitHub |
| Sign-in | in pipelines the build account, otherwise sign-in through the Credential Provider or a PAT | according to GitHub only personal access token (classic); in Actions the GITHUB_TOKEN for packages of the workflow's repository |
| Permissions | feed roles | inherited from the repository or set for people and organizations; some registries only know repository permissions |
| Special features | views, upstream sources, retention policies | packages of public repositories are public |
| Cost | 2 GiB of free storage per organization, meant for evaluation | free for public packages; for private packages storage and data transfer depending on the plan, above that budgets |
Two remarks from Microsoft's page: Universal Packages exist only in Azure DevOps Services, not in Azure DevOps Server. Cargo exists in Azure DevOps Services and in Azure DevOps Server 2022, not in Server 2020. More amounts are on the price pages of both providers; this lesson names none.
A note on signing in at GitHub: The page I read says GitHub Packages supports only the classic personal access token. To install from other private repositories you need at least the scope read:packages, unless the repository has read access to the package. How you solve sign-ins in pipelines without long-lived secrets is the topic of module D5.