Examining Release views in Azure DevOps

Examining Release views in Azure DevOps

'OR ### Examine Release Views in Azure Artifacts

Azure Artifacts provides a Package Management service to create, host, and share packages (e.g., NuGet, npm, Maven, Python). The ability to manage packages effectively is crucial for modern software development. Release views in Azure Artifacts are a key concept that helps developers organize and manage their packages based on their state, such as whether they are stable, prerelease, or ready for production.

In Azure Artifacts, feeds are used to organize and store packages, and views allow you to filter and manage the visibility of those packages based on their status (local, prerelease, or release).

Azure Artifact Feed Views

Azure Artifacts provides three primary feed views:

1. Local View

2. Prerelease View

3. Release View

Each of these views serves a distinct purpose in managing the lifecycle of packages and controlling which versions are available to different consumers.

1. Local View

Purpose:

The Local View is used to display locally published packages that may not yet be ready for broader use or public consumption. These packages are typically still in development or testing stages and are not meant to be shared with other consumers in the organization unless explicitly intended.

Usage:

1. This view can be used for testing or development versions of packages before they are finalized.

2. Developers or teams working on a package can publish to the Local view for internal or early-stage consumption, without the package being exposed to broader audiences.

3. For example, a developer might push a package with a version 1.0.0-alpha to the Local View to allow internal testing without having it appear as a stable package.

Typical Scenarios:

1. Development builds that are not yet stable or fully tested.

2. Early alpha or beta versions that are only meant for specific internal teams.

3. Packages that are part of a private or experimental feature.

Example:

You may have a feed that includes packages like my-package-1.0.0-alpha, my-package-1.0.0-beta under the Local view, which are still under active development.

2. Prerelease View

Purpose:

The Prerelease View shows packages that are pre-release versions of a package, typically used for testing before they are made generally available. These could be versions marked with pre-release tags, such as alpha, beta, rc (release candidate), or even other custom tags used in the versioning scheme.

Usage:

1. Packages in this view are often unstable or not fully tested and are intended for QA, internal testing, or select early adopters.

2. Developers might push packages with version tags like 1.0.0-beta or 2.1.0-rc to the Prerelease View.

3. Allows teams to test new features and early versions without affecting production environments.

Typical Scenarios:

1. Beta or Release Candidate versions that are ready for testing but not intended for general consumption.

2. Feature flags or experimental versions of a package that are being tested with a specific set of users.

3. Testing a new package version in a staging environment.

Example:

The package my-package-1.0.0-beta would be visible in the Prerelease View for consumers who wish to test new features or functionality before a stable release is published.

3. Release View

Purpose:

The Release View shows stable, production-ready packages that are considered safe for use in production environments. These packages are considered final, have undergone sufficient testing, and are ready for deployment in end-user environments.

Usage:

1. This view is typically where the official, production-grade packages are published once they’ve passed testing and are ready for consumption by a broader audience.

2. These packages typically follow a versioning pattern that indicates they are stable, such as 1.0.0, 1.1.0, or 2.0.0.

3. It is ideal for production systems or applications that require reliable and verified dependencies.

Typical Scenarios:

1. Stable releases of software that can be deployed in production environments.

2. Official releases of libraries, tools, or services that other teams and external developers can consume with confidence.

3. Long-term support (LTS) versions that are designed for stable and continuous production use.

Example:

A stable package my-package-1.0.0 or my-package-2.0.0 would be available in the Release View for production use.

Using Views in Azure Artifacts

In Azure Artifacts, the views provide a mechanism to filter and display packages based on their release status. Here's how you can use them:

1. Creating and Managing Views in Azure Artifacts

• Default Views: By default, feeds have three predefined views: Local, Prerelease, and Release. These views help organize packages according to their stage in the release lifecycle.

• Managing Views: You can manage views within the Azure DevOps portal under Artifacts > Feeds > Manage Views.

2. How to Filter Packages by View

When browsing a feed or searching for a package in Azure Artifacts, you can filter the available packages by selecting the view you want to display:

• Local View: Shows locally published, often in-progress versions of packages.

• Prerelease View: Filters for packages that are in the pre-release state (e.g., 1.0.0-alpha, 2.1.0-beta).

• Release View: Filters to show only stable, production-ready versions of the package (e.g., 1.0.0, 2.0.0).

3. Publishing Packages to Different Views

When you publish a package to Azure Artifacts, the version can be specified to target a particular view:

For example, you can push a NuGet package to the Prerelease View using a command like:

xxxxxxxxxx
2
1
dotnet pack --version 1.0.0-beta
2
dotnet nuget push my-package-1.0.0-beta.nupkg --source https://dev.azure.com/{organization}/_packaging/{feed}/nuget/v3/index.json

This package would appear in the Prerelease View for users who want to test the beta version before it’s finalized.

4. Viewing and Consuming Packages by View

When you consume packages from a feed, you can specify the view from which you want to pull the package:

• Release View: For production use.

• Prerelease View: For testing or QA purposes.

• Local View: For internal or in-progress work.

By selecting the correct view, you can ensure that your project or pipeline always consumes the correct version of a package for your environment (e.g., stable releases for production, beta versions for testing).

Benefits of Using Views in Azure Artifacts

1. Control Over Package Visibility:

Views allow teams to control which packages are visible based on their stage in the lifecycle, ensuring that only stable, production-ready packages are consumed by production systems, while development or testing packages can be isolated.

2. Prevention of Accidental Consumption:

Using views helps avoid accidental use of unstable or experimental versions in production. For example, consumers can filter out pre-release versions and only install stable versions from the Release View.

3. Organized Package Management:

Views provide a simple, organized way to manage and differentiate between in-progress packages, testing versions, and stable releases, reducing confusion and promoting clear separation of environments.

4. Targeted Testing:

With the Prerelease View, teams can ensure that packages are properly tested before their final release, by allowing only designated teams or users to access alpha, beta, or release candidate versions.

5. Improved Collaboration:

Teams can work on packages in isolation (via the Local View) or share pre-release versions (via the Prerelease View) without affecting the general availability of stable packages.

Summary

In Azure Artifacts, the use of Release Views (Local, Prerelease, and Release) enhances the management and consumption of packages by filtering and organizing them according to their stability and intended usage. By clearly distinguishing between development, testing, and production versions of packages, you can manage your dependencies effectively and avoid introducing unstable code into your production environment.

Key Takeaways:

1. Local View: For in-progress or internal packages.

2. Prerelease View: For testing versions like alpha, beta, or RC.

3. Release View: For stable, production-ready packages.

By properly using these views, you can ensure a well-organized package management lifecycle, promoting smoother transitions from development to testing to production in your software delivery pipeline.