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.

tkapin / test1

[DRAFT] .NET Unified Build (Theme) #9