Seeking the thrill of transformative tech? Explore the art of designing and implementing DevOps solutions on Azure. Master the shift towards CI/CD, testing, and delivery, while preparing for the Designing and Implementing Microsoft DevOps Solutions exam!
Gauge your current knowledge
Gauge your current knowledge
A feed in Azure Artifacts acts as a central storage hub for your team's packages, like NuGet, npm, or Maven packages. It allows you to host your own packages locally within Azure DevOps. You control who can publish to the feed and who can download from it by setting feed-level permissions. To manage storage and organization, you can also define retention policies that automatically delete old or unused package versions.
An upstream source connects your private feed to an external, public package registry, such as npmjs.org or NuGet.org. When a developer requests a package, the system first checks your local feed. If the package isn't there, it automatically fetches it from the upstream source and stores a copy in your feed. This process caches packages locally, which improves download speed for your team and ensures you have a controlled copy of external dependencies.
A view is a filtered window into your feed that controls package visibility and promotion. You typically create views that match your release stages, like @local, @prerelease, and @release. Packages start in a view like @local. When a package is ready, you promote it to the next view, such as from @prerelease to @release. This controls which packages are visible to different teams or pipelines; for example, a production pipeline might only be allowed to consume packages from the @release view, ensuring stability.
To set this up, you first create a feed and configure its permissions, deciding which users or groups can contribute or consume packages. Next, you add upstream sources to your feed, linking it to the public registries your projects need. Finally, you create the necessary views (@local, @prerelease, @release) and set up your build pipelines to publish packages to the appropriate initial view. Your release pipelines are then configured to only consume packages from the stable, promoted views, creating a clear package promotion path from development to production.
StudyCerts
StudyCerts