Incorporate a testing mode for the Release pipeline.

[andriipatsula]

Goals and Motivation

Currently, we lack a proper testing mechanism for the Release pipeline. The Release-DotNet-5.x-Test pipeline skips almost all stages and tests only the bare minimum.

Another risk is that we use the same environment (including storage accounts, secrets, and subscriptions) for both Prod and Test modes, which has the potential to break the released bits one day.

The goal is to introduce a test environment that is completely isolated from the production one. This environment would have a separate resource under the -test subscription, and we aim to eliminate any if () {} else {} statements in the yaml(s), scripts, and tools.

Our objective is to have the same code run in both modes but publish results to completely different locations. Your text is clear, but for smoother flow and clarity, you might consider a slight adjustment:

A similar approach was implemented for the source-build-release and source-build-release-test pipelines.

They defined a common base in source-build-base.yml. In both source-build-release-test.yml and source-build-release-official.yml, they simply define the required parameters.

Business objectives

One of the primary business objectives outlined in .NET Release Infrastructure Adoption is to establish proper testing for the Release infrastructure. This will enable us to run test pipelines that behave identically (run the same code) to the production environment but without impacting the production itself.

• [ ] We have introduced a test environment with test resources: storage accounts, keys, subscriptions, etc.
• [ ] We developed a test version of the Release pipeline that executes identical code and publishes the same artifacts.

Milestones

Testing

[dkurepa]

As a part of transfer the transfer to arcade-services, I'm creating a milestone based on this issue