Skip to content

Artifact Management Design and Policies in Azure DevOps

This document captures the current recommendations and supported patterns for artifact management in Azure DevOps. The goal of artifact management is to manage shared assets (mostly libraries) that are produced internally and shared across repositories and consumed from Internet sources i.e. Software of Unknown Provenance (SOUP).

Note: Azure Artifacts is not intended for Containers (Docker images) or Container deployment artifacts (Helm charts etc.).

Key Terms

  • Feed - A named and secured database managed by Azure DevOps Artifacts that can store binary packages in various consumption formats and is identified by a URL. Azure DevOps Artifacts support today the formats (NuGet for .NET, Maven for Java, NPM for Angular and other NPM based sources, Python packages, and universal for holding anything else).

  • View - Azure DevOps Artifacts have a way to allow a package to be promoted or demoted from named views within a feed to allow for package curation and "quality" level promotion. The default view is @local that all packages go into and doesn't need to be specified when using the "default unqualified view".

  • Upstream Sources - Upstream sources enables you to use a single feed to store both the packages you produce and the packages you consume from "remote feeds": both public feeds (for example, npmjs.com, NuGet.org, Maven Central, and PyPI) and authenticated feeds (that is, other Azure DevOps Services feeds in your organization or in organizations in your Azure Active Directory tenant). Once you've enabled an upstream source, any user connected to your feed can install a package from the remote feed, and your feed will save a copy.

Design Goals

Below are the key goals of Azure artifact feeds design:

  • Simplify developer experience for consuming and publishing artifacts
  • Maintain both "Debug" and "Release" version of artifact with same name version number
  • Optimize storage for the artifacts to manage cost
  • Ensure that only approved SOUP can be used in a Product release build
  • Provide a mechanism for SOUP to be reviewed and approved during development cycle
  • Provide developers a way to use new SOUP during development without pre-approval
  • Provide a way to maintain a cache of SOUP for future references, to protect against outages and removal from source
  • Allow sharing of artifacts between the Platforms

Project Scoped Feeds

Based on above goals, it is recommended to create two Azure DevOps Project scoped feeds for each Platform:

  • {Platform}Develop e.g. CareLinkDevelop
    • Feed should be configured to consume upstream sources from required remote feeds e.g. npmjs.com, NuGet.org, Maven Central, PyPI, Org scoped feed etc.
    • Feed should be used by developers for local development
    • Feed should be used to publish "Debug" configuration build artifacts from the Pipelines
    • All developers of the Platform should have access to this feed to publish and consume artifacts
    • "local" view is the default view
  • {Platform}Formal e.g. CareLinkFormal
    • Feed should be configured to consume upstream sources from required remote feeds e.g. npmjs.com, NuGet.org, Maven Central, PyPI, Org scoped feed etc.
    • Feed should be used to publish and consume "Release" configuration build artifacts from the Pipelines
    • Only build pipeline accounts should have access to publish to this feed. Developers should not have access to publish to this feed
    • "local" view is the default view
    • "release" view of the feed will contain artifacts ready to be shared within the Platform

Organization Scoped Feed

In addition to above two Project scoped feeds, an Organization scoped feed should be created to allow for sharing of artifacts between Platforms e.g. when Paceart needs to consume artifacts generated by CareLink. Below are some of the key characteristics of Organization scoped feed:

  • Should not contain any 3rd Party SOUP packages
  • Should be configured as Upstream for the {PlatformFormal} and {PlatformDevelop} feeds which need to use packages shared from other Platforms
  • Only build pipeline accounts should have access to publish to this feed. Developers should not have access to publish to this feed
  • Artifacts in the Organization scoped feed should be retained forever i.e. disable retention Policy for Organization scoped feed

Retention Policy

A retention policy should be configured for Project scoped feeds to improve client performance and manage cost by releasing storage space. Note that retention policies will not delete any version that has been promoted to a view. Therefore, any packages that have been promoted to release view will never be deleted.

  • Publishing Artifacts

    • Pipeline build from all branches should publish "Debug" build of artifact to the {PlatformDevelop} feed. This will publish to local view
    • Pipeline build from all branches should publish "Release" build of artifact to the {PlatformFormal} feed. This will publish to local view
    • If an artifact needs to be shared with other Platforms, pipeline build from "main" and/or "release" branches should publish "Release" build of artifact to the Org scoped feed. This will publish to local view of Org scoped Feed

  • Consuming Artifacts

    • Pipeline build from "develop" and "feature" branches should consume artifacts from local view of {PlatformFormal} and Organization scoped feeds
    • Pipeline build from "main" and "release" branch should consume artifacts published to release view of {PlatformFormal}
    • Any 3rd party upstream packages referenced at any point will be downloaded and cached in the {PlatformFormal} feed as part of the pipeline build and in {PlatformDevelop} feed when developers build locally

  • Promoting Artifacts

    • Pipeline build from "main" branch and/or "release" branches should promote the artifact published to the {PlatformFormal} feed from local view to the release view
    • Pipeline build from "main" branch and/or "release" branches should also promote the artifacts in {PlatformFormal} feed local view that are sourced from Organization scoped feed to the release view. Note, either this promotion will be required or the Pipeline should directly consume from Organization scoped feed in addition to {PlatformFormal} feed
    • 3rd party upstream package downloaded into the local view {PlatformFormal} feed should be promoted to the release view after review and approval from the authorized group.
      • This process should be facilitated a report which lists all the 3rd Party packages in the {PlatformFormal} feed that have not been promoted to the release view
      • Pre-Release packages from 3rd Party should never be promoted to release view
      • As a rule, developers should not use Pre-Release packages from 3rd Party

  • Naming

    • Artifact names must match assembly/component binary names or component formal names
    • Names should follow the Medtronic.FunctionalArea.Component naming standard of namespaces and projects

  • Versioning

    • Artifacts should follow [Semantic Versioning 2.0.0 Standard.] ( https://semver.org/)

    • A specific version number is in the form Major.Minor.Patch-Suffix, where the components have the following meanings:

      • Major: changes when major breaking changes
      • Minor: changes when new features, but backwards compatible
      • Patch: changes with bug fixes only, is backward compatible
      • Suffix (optional): a hyphen followed by a string denoting a pre-release version and/or "+" followed by build metadata Below "suffix" recommendation should be used to indicate maturity of the artifact release:
        • Use "-alpha" for artifacts created pre-TRR builds
        • Use "-rcx" for TRR build where "x" indicates TRR number
        • Drop suffix for the final release build

Metronic Azure DevOps Artifacts Usage

medtronic-artifact-usage

ToDo Items

  • Update guidance for Retention Policy to include recommended retention rules
  • Update the process for promotion based on how Release process is defined
  • [What are Azure Artifacts?] (https://docs.microsoft.com/en-us/azure/devops/artifacts/overview?view=azure-devops)
  • [Key concepts for Azure Artifacts] (https://docs.microsoft.com/en-us/azure/devops/artifacts/artifacts-key-concepts?view=azure-devops)
  • [Best practices for using Azure Artifacts] (https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/best-practices?view=azure-devops)
  • [Nuget Package Versioning] (https://docs.microsoft.com/en-us/nuget/concepts/package-versioning)
  • [Upstream Sources] (https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops)
  • [Retention Policy] (https://docs.microsoft.com/en-us/azure/devops/artifacts/how-to/delete-and-recover-packages?view=azure-devops&tabs=maven#automatically-delete-old-package-versions-with-retention-policies)