Context and Motivation

Currently, the .NET product is organized in multi-repository fashion, with each of its components (runtime, roslyn, SDK, …) living in dedicated git repositories. While this code organization simplifies development of the individual components, construction of the final product requires complex orchestration to flow binary dependencies between the individual product repos, as well as human effort to get a coherent product build. This way of building the .NET product is called Microsoft’s official build.

Source-build, yet another way of building the .NET product, is used by our Linux partners (Red Hat, Canonical) to build and ship .NET in their distros, satisfying strict requirements of building the product without binary dependencies. Maintaining both these methodologies is expensive.

The Unified Build project aims to reduce the costs of the .NET servicing releases as well as the release time by providing a single (virtual) repository that with all the code and assets needed to build the entire product. Focusing on the source-build philosophy (aggregate code base is the source-of-truth) as the way that the community and Microsoft produce the product will drastically improve development operations, servicing, and community interaction.

.NET Unified Build is a theme for the Germanium semester.

Details can be found in the "Unified Build (Theme)" document. The scenarios listed below are pulled from this document and will be represented as linked work items in this project.

Scenarios

• [S1] Microsoft and its partners can develop and build a .NET distribution with minimal orchestration
  • Microsoft can produce a shippable .NET 9 build in 50% less time than .NET 8. // Joc wanted to put concrete numbers there
  • Release retrospective items classified as “Build” drop by 50% in .NET 9 as compared to .NET 8.
  • A shippable build is produced from a single commit in a single source repo.
• [S2] Developers can efficiently work on the product.
  • Cross-stack repository changes can be done in a single commit.
• [S3] Microsoft, its partners, and community developers can validate the complete product
  • Distro partners can decommission their existing smoke tests if they desire, and still have confidence in shipping the product.

Areas

• Vertical Build Proofs of Concept for each vertical (Windows, Linux, MacOS, SDK Workloads) - Uncover hidden problems with building the product for each platform in a single build without requiring cross-platform build assets.
• Vertical Builds Design - Leverage the finding of the vertical build PoC works to design vertical builds for each platform properly, with the minimal set of join points.
• Enable Vertical Builds - Implementation of the vertical builds design with the new set of join points.
• Cross-builds Design - Design for cross-arch or cross-platform builds and determine how to define cross-build behavior.

Source-Build

// I'm talking about unified build rather just than about source-build as the source-build methodology efficiently becomes the unified build (without considering using binary artifacts during the build)

• Eliminate Source Edits During Build - Improve developer experience of the unified build by eliminating source edits during the build.
• Parallel Build Support - Improve unified build performance by supporting parallel builds.
• Remove Inner Clone - Improve developer experience and performance of the unified build by not creating an inner repo clone during the build.
• Incremental Build Support
• Support for Multi-band SDKs - Support for multiple SDK bands in the VMR and unified build.

Product Validation

• Scenario tests in VMR - End-to-end scenario tests executed on already installed .NET product.
• PR Validation - Definition and implementation of the set of tests that would be executed as part of the VMR PR validation.
• Product Validation Tooling

Product Construction

• VMR Backflow design - Design for the backflow from the VMR to the individual product repositories.
• VMR Backflow tooling - Implementation of the core functionality and CLI tooling for the VMR backflow in to the product repos.
• Dependency Flow Service - Implementation of the new .NET Product Construction service, that will be extending the current dependency flow and BAR design.
• Maestro Integration - Integration of the new dependency flow service with Maestro++.
• Dependency Flow Switch Preparation - Preparation for switching from the existing multi-layered product dependency flow to the new flat dependency flow between VMR and product repos.
• Dependency Flow Switch - Switch to the new flat dependency flow between VMR and product repos.

Release Infra

• Release infra investigation & design - Design for changes necessary to enable releases off of the VMR.
• Signing Design - Design for signing releases based off of the VMR.
• Identify Repo Dependencies - Identification of the dependencies between product repos and the layout used to stage the product assets for release.
• Staging / Release Pipeline - Updates to the current release infrastructure, namely the staging and release pipelines to be able to base releases both off the current dependency flow for .NET8 and the VMR for .NET9.

Purpose

This issue tracks the arcade-services repository rollout. On top of the Rollout instructions described on the wiki, it provides the person responsible for the rollout checklist of the steps that should to be performed to rollout services in this repository. All relevant information, including the rollout PR, issues encountered during the rollout and steps taken to resolve them should be linked or added to this issue to keep full audit trail of changes rolled out to production.

Process

Build status check (Monday)

• Check the status of the dotnet-arcade-services-weekly pipeline
• Ensure the arcade-services-internal-ci pipeline is green
• In case there is a problem with the CI build, notify the Rollout channel

Rollout preparation (Tuesday)

• Wait for the vendor to prepare the rollout. This includes a thread on the Rollout channel, rollout issue in AzDO and the rollout PR
• Link the rollout PR to the "Rollout data" section of this issue
• Double-check that the release notes contain all information
• Merge the already prepard rollout PR
• Ensure the build is green and stops on the "Approval" phase

Rollout day (Wednesday)

• Approve the rollout build (that has been already started the day before)
• Monitor the rollout build for failures. The Maestro exceptions query might help in diagnosing issues.
• Keep track of any issues encountered during the rollout either directly in this issue, or in a dedicated issue linked to this issue
• Update the rollout stats in the "Stats" section below
• Notify the Rollout channel
• Close this issue with closing comment describing a high-level summary of issues encountered during the rollout

Rollback

In case the services don't work as expected after the rollout, it's necessary to roll back.

• Announce the issues on the Rollout channel, rollout issue in AzDO
• Notify the partners that we'll be rolling back
• Rollback as described on the Rollback / Hotfix wiki page
• Validate the rolled-back services are running as expected
• Announce successful rollout on the Rollout channel
• Notify the partners that the rollback has been finished (as reply on the original email)

Rollout data

Rollout PRs

• The main PR: <TO BE FILLED>
• Rollback PRs: <TO BE FILLED, IF APPICABLE>

Rollout times

Use the following Kusto query to gather data about rollout times:

Pre-Approval run time: <TO BE FILLED>
Post-Approval run time: <TO BE FILLED>

Useful links

• AzDO pipelines
  • arcade-services-internal-ci
  • dotnet-arcade-services-weekly
• Rollout channel
• Maestro exceptions
• Deployment Policy

Contact Details

[email protected]

What happened?

A bug happened!

Version

1.0.2 (Default)

What browsers are you seeing the problem on?

No response

Relevant log output

...

Code of Conduct

• I agree to follow this project's Code of Conduct