dotnet
.NET Release Infrastructure Adoption
Goals and Motivation
Until now, the ownership of the .NET release infrastructure has been informally aligned with the teams that created the infrastructure. Specifically, this has been split between the Engineering Services, who have created the staging pipeline and the .NET Release team and DDFun, who have created most of the tooling in the dotnet-release repository as well as the release pipeline.
With the constitution of the Product Construction team, it makes sense to transfer the ownership of the release infrastructure to this team, which is the primary goal of this epic. This epic describes the individual objectives of the ownership transfer and the necessary changes that needs to be made in order to ensure the seamless releases of the .NET product.
Business Objectives
There are several business objectives that needs to be met in order to successfully transfer the ownership of the .NET release infrastructure to the Product Construction team. From the project management perspective, these business objectives also represent themes to align concrete workitems with.
- [ ] The release infrastructure is audited, understood and well documented
- [ ] The release infrastructure is reliable and allows to release the .NET product seamlesly
- [ ] The release team can operate the infrastructure efficiently and with confidence
- [ ] The release infrastructure is testable so that changes can be implemented with high confidence
- [ ] Telemetry and alerting is set up so that we can monitor the release infrastructure
- [ ] The release team has means to confirm correctness of released assets
Related Epics & Sub-Epics
There are several related deliverables, that are not directly in the scope of this epic, but are related to our improvements of the release infrastructure.
- dotnet/arcade#12261
Concrete Work Items
The following items break down the overall effort into a set of deliverables, that can be perceived as individual milestones of this work. Each of the issues, representing an area of improvement be considered to be a mini-epic with it's own concrete issues listed transitively.
Information Gathering
Tasks associated with the "The release infrastructure is audited, understood and well documented" objective.
- dotnet/arcade#12821
- https://github.com/dotnet/arcade/issues/13298
Reliability Improvements
Tasks associated with the "The release infrastructure is reliable and allows to release the .NET product seamlesly" objective.
- dotnet/arcade-services#2394
- dotnet/arcade-services#2403
- dotnet/arcade-services#2407
- dotnet/arcade-services#2634
- dotnet/arcade-services#2400
- dotnet/arcade-services#2402
Usability Improvements
Tasks associated with the "The release team can operate the infrastructure efficiently and with confidence" objective.
- dotnet/arcade-services#2390 (Sub-Epic)
- dotnet/arcade-services#2395
- dotnet/arcade-services#2396
- dotnet/arcade-services#2416
- dotnet/arcade-services#2399
- dotnet/arcade-services#2401
- dotnet/arcade-services#2404
- https://github.com/dotnet/arcade-services/issues/2627
Testability
Tasks associated with the "The release infrastructure is testable so that changes can be implemented with high confidence" objective.
- https://github.com/dotnet/arcade-services/issues/2397
- dotnet/arcade-services#2388 (Sub-Epic)
- https://github.com/dotnet/arcade-services/issues/2389 (Sub-Epic)
Telemetry and Alerting
Tasks associated with the "Telemetry and alerting is set up so that we can monitor the release infrastructure" objective.
- [x] #2644
Release Validation
Tasks associated with the "The release team has means to confirm correctness of released assets" objective.
N/A
Additional things that could be done:
- Harden later stages (publishing to staging locations) to be more resilient.
- Harden Linux signing stages to be more strict about expected files (in patch vs. RTM releases)
