Tái phát minh cách .NET xây dựng và phát hành (Một lần nữa)

Sau khi tôi viết bài viết trước về cách .NET xây dựng và phát hành, tôi đã khá lạc quan rằng mình sẽ không phải viết thêm một bài nào nữa. Hoặc ít nhất là không phải viết về cách chúng tôi xây dựng và phát hành. Vấn đề đó đã được giải quyết xong xuôi. .NET đã làm được! Chúng tôi đã tìm được sự cân bằng giữa phát triển kho lưu trữ phân tán và khả năng nhanh chóng tạo ra một sản phẩm để phát hành. Xin chúc mừng mọi người, giờ đây các nhóm cơ sở hạ tầng có thể tập trung vào những việc khác. Bảo mật, tiêu chuẩn hóa xuyên công ty, hỗ trợ xây dựng các tính năng sản phẩm mới. Tất cả những điều tốt đẹp.

…Một năm rưỡi sau…

Chúng tôi đang hỏi chi phí để xây dựng 3-4 phiên bản chính với hàng tá dải .NET SDK giữa chúng mỗi tháng sẽ là bao nhiêu. Và giữ cho hệ thống kỹ thuật của chúng luôn được cập nhật. Và này, có một bản sửa lỗi muộn mà chúng tôi muốn đưa vào bản phát hành tuần tới, vậy tôi có thể kiểm tra nó hôm nay và để nhóm xác thực vào tối nay không? Chắc không khó đến thế, phải không? Và tôi có một tính năng mới xuyên suốt toàn bộ stack mà tôi muốn thử nghiệm… làm thế nào để xây dựng nó?

Câu trả lời hầu hết đều gây thất vọng:

“Sẽ tốn rất nhiều, và ngày càng tệ hơn.”

“Tôi không nghĩ chúng ta có đủ thời gian cho bản sửa lỗi đó, tôi chỉ có thể đoán thời gian build sẽ mất bao lâu, nhưng ít nhất là 36 giờ trước khi chúng ta có thể bàn giao để xác thực. Có thể hơn?”

“Tôi chắc rằng chúng ta có thể duy trì cơ sở hạ tầng nhiều như vậy, nhưng chúng ta sẽ từ từ chìm dưới chi phí duy trì nó.”

“Mức độ quan trọng của việc bạn có toàn bộ stack để làm việc là như thế nào? Sẽ mất một thời gian để thiết lập điều đó.”

Đây không phải là những câu trả lời mà chúng tôi muốn đưa ra. Và vì vậy, chúng tôi đã quay trở lại bàn vẽ, tìm kiếm giải pháp.

Bài viết trên blog này nói về dự án Unified Build: nỗ lực của .NET nhằm giải quyết nhiều vấn đề này bằng cách chuyển việc xây dựng sản phẩm vào một kho lưu trữ ‘monolithic ảo’, hợp nhất quá trình build thành một loạt các ‘vertical build’, đồng thời vẫn cho phép những người đóng góp làm việc bên ngoài monolith. Tôi sẽ kể ngắn gọn câu chuyện về hành trình xây dựng sản phẩm của chúng tôi trong suốt vòng đời của .NET. Tôi sẽ chỉ ra những bài học chúng tôi đã học được về việc áp dụng mô hình xây dựng sản phẩm phân tán cho một sản phẩm đơn lẻ, đặc biệt là những nhược điểm về chi phí và độ phức tạp. Cuối cùng, tôi sẽ đi sâu vào chi tiết của Unified Build và công nghệ nền tảng của nó, Source Build của các bản phân phối Linux. Chúng ta sẽ xem xét phương pháp xây dựng sản phẩm mới và kết quả mà chúng tôi đang thấy.

Mục lục

Làm thế nào chúng ta đến được đây? Đây không phải là cơ sở hạ tầng build tuyệt vời của tôi

.NET được sinh ra từ cơ sở hạ tầng mã nguồn đóng của .NET Framework và Silverlight vào năm 2015-2016. Nó được mã nguồn mở dần dần khi chúng tôi chuẩn bị các thành phần của nó cho việc sử dụng bên ngoài, và theo xu hướng thời đó, chúng tôi đã chia nó thành nhiều kho lưu trữ. CoreCLR đại diện cho runtime cơ bản, CoreFX cho các thư viện, Core-Setup cho việc đóng gói và cài đặt. Cùng với đó là ASP.NET Core và EntityFramework Core, và một SDK với CLI. Một vài bản phát hành đã chứng kiến những cuộc đại tu lớn của sản phẩm dưới dạng các shared framework, với WindowsDesktop tham gia vào. Nhiều kho lưu trữ hơn và nhiều phức tạp hơn.

Điều quan trọng cần hiểu là .NET là một sản phẩm được phát triển trong các kho lưu trữ riêng biệt nhưng phụ thuộc lẫn nhau và cần được kết hợp với nhau trong một khoảng thời gian tương đối ngắn để phát hành. Trên lý thuyết, ‘đồ thị’ của sản phẩm trông giống như bất kỳ hệ sinh thái mã nguồn mở nào. Một kho lưu trữ tạo ra một thành phần phần mềm, xuất bản nó lên các registry công cộng, và các người tiêu dùng hạ nguồn phụ thuộc vào thành phần mới và xuất bản các bản cập nhật của riêng họ. Đó là một mô hình nhà sản xuất – người tiêu dùng, nơi các thay đổi lan truyền qua ‘đồ thị phụ thuộc’ toàn cầu thông qua một loạt các hoạt động pull->build->publish. Mô hình này có tính phân tán cao và hiệu quả, nhưng không nhất thiết phải hiệu quả về mặt thời gian. Nó cho phép các nhà cung cấp phần mềm và chủ sở hữu kho lưu trữ có quyền tự chủ đáng kể về quy trình và lịch trình của họ. Tuy nhiên, cố gắng áp dụng phương pháp này cho một sản phẩm như .NET, sử dụng các kho lưu trữ riêng biệt nhưng phụ thuộc lẫn nhau, có những nhược điểm lớn.

Hãy gọi đây là “phương pháp xây dựng sản phẩm phân tán”. Để hiểu tại sao nó có thể là một phương pháp khó sử dụng, chúng ta hãy xem xét quy trình tạo ra một bản phát hành bảo mật.

Ví dụ: Bảo trì bảo mật

Hãy xem xét việc phát hành một bản vá bảo mật. Một lỗ hổng bảo mật được phát hiện ở đâu đó trong thư viện .NET Runtime. Bởi vì .NET có nguồn gốc từ .NET Framework, giả sử lỗ hổng bảo mật này cũng tồn tại trong .NET Framework 4.7.2. Điều tối quan trọng là bản cập nhật bảo mật của .NET phải được phát hành đồng thời với bản cập nhật .NET Framework, nếu không cái này sẽ làm lộ cái kia. .NET có nhiều đường dẫn phát hành do Microsoft quản lý. Microsoft Update, CDN của chúng tôi, các registry gói Linux và container, nuget.org, Visual Studio, Azure Marketplace, v.v. Điều đó đặt ra một số hạn chế về dòng thời gian. Chúng tôi cần có khả năng dự đoán được.

Cấu trúc phát triển của .NET trông rất giống một hệ sinh thái mã nguồn mở điển hình. .NET Runtime, .NET SDK, ASP.NET Core và WindowsDesktop shared framework được phát triển bởi các nhóm khác nhau, mặc dù có sự cộng tác chéo rất lớn. Đôi khi, chúng được phát triển như những sản phẩm độc lập. .NET Runtime tạo thành nền tảng của sản phẩm. ASP.NET Core và WindowsDesktop được xây dựng trên nền tảng đó. Một lượng lớn các công cụ phát triển (C#, F#, MSBuild) được xây dựng dựa trên bề mặt của .NET Runtime và một số thư viện phụ trợ. SDK tập hợp và xây dựng một CLI, cùng với các task, target và công cụ. Phần lớn nội dung của shared framework và công cụ được phân phối lại trong hộp.

Để xây dựng và phát hành bản vá bảo mật này, chúng tôi cần sự phối hợp giữa nhiều nhóm đóng góp cho sản phẩm .NET nói chung. Chúng tôi cần các cấp thấp nhất của đồ thị .NET xây dựng tài sản của họ, sau đó cung cấp chúng cho người tiêu dùng hạ nguồn. Họ cần nhận bản cập nhật, xây dựng và cung cấp tiếp cho hạ nguồn. Điều này sẽ diễn ra liên tục cho đến khi sản phẩm “mạch lạc”; không có thay đổi mới nào được đưa vào đồ thị và mọi người đồng ý về một phiên bản duy nhất của mỗi thành phần trong sản phẩm. Tính mạch lạc đảm bảo rằng một thành phần có thay đổi được đưa vào mọi nơi phân phối lại thành phần đó hoặc thông tin về nó. Sau đó, chúng tôi muốn thực hiện xác thực của mình, lấy tất cả tài sản có thể phát hành từ việc đóng tất cả các thành phần chưa được phát hành đó, và sau đó phát hành tất cả cùng một lúc ra thế giới.

Đây là rất nhiều bộ phận chuyển động cần phải hoạt động tốt cùng nhau trong một khoảng thời gian ngắn.

Ưu điểm và Nhược điểm của Hệ sinh thái Phân tán

Điều quan trọng cần lưu ý là phong cách phát triển hệ sinh thái phân tán này có rất nhiều ưu điểm:

Phân lớp – Ranh giới kho lưu trữ khuyến khích phân lớp và các sản phẩm ít ràng buộc chặt chẽ hơn. Trong vòng đời phát triển phiên bản chính, các thành phần riêng lẻ của stack thường vẫn tương thích với nhau, ngay cả khi các thay đổi diễn ra nhanh chóng và không đồng đều qua đồ thị.
Cộng đồng – Ranh giới kho lưu trữ khuyến khích các cộng đồng tốt, tập trung. Ví dụ, cộng đồng WPF và Winforms thường riêng biệt. Các kho nhỏ cũng thường dễ tiếp cận hơn.
Tính gia tăng – Phát triển phân tán thường cho phép các thay đổi gia tăng. Ví dụ, chúng tôi có thể thực hiện các thay đổi phá vỡ đối với bề mặt System.CommandLine, sau đó đưa chúng vào người tiêu dùng theo thời gian.
Vòng lặp nội bộ chặt chẽ – Các kho lưu trữ nhỏ hơn, tập trung hơn có xu hướng có trải nghiệm vòng lặp nội bộ tốt hơn. Ngay cả những thứ đơn giản như git clone hay git pull cũng nhanh hơn trong một kho lưu trữ nhỏ.
Phát triển không đồng bộ – Tính gia tăng giúp phát triển không đồng bộ hơn. Nếu thành phần của tôi chảy đến ba người tiêu dùng hạ nguồn làm việc ở ba múi giờ khác nhau, các nhóm đó có thể tiến triển trên các thành phần của riêng họ vào thời gian riêng của họ.
Phân mảnh/Build gia tăng chi phí thấp – Phát triển phân tán cho phép ‘tối ưu hóa’ việc bỏ qua các build của các thành phần không thay đổi thường xuyên.

Tuy nhiên, nếu bạn nheo mắt nhìn kỹ, nhiều ưu điểm của mô hình phân tán lại là điểm yếu đáng kể của nó khi chúng ta cần xây dựng và phát hành phần mềm yêu cầu các thay đổi trong một phần đáng kể của đồ thị phải được hoàn thành trong một khoảng thời gian ngắn. Các thay đổi ở quy mô lớn trên các đồ thị lớn thường chậm và khó dự đoán. Trong các hệ sinh thái OSS điển hình (ví dụ: hệ sinh thái gói NuGet hoặc NodeJS), những khía cạnh này thường không phải là vấn đề. Các hệ sinh thái này không tối ưu hóa cho tốc độ hoặc khả năng dự đoán. Thay vào đó, chúng coi trọng quyền tự chủ của mỗi nút. Tuy nhiên, khi chúng ta cố gắng áp dụng mô hình phân tán để phát hành phần mềm một cách nhanh chóng, chúng ta thường gặp khó khăn vì nó làm gia tăng hai khái niệm chính: Độ phức tạp trong xây dựng sản phẩm và Chi phí overhead trong xây dựng sản phẩm.

Độ phức tạp trong xây dựng sản phẩm

Trong bối cảnh xây dựng sản phẩm, ‘độ phức tạp’ đề cập đến số lượng các bước cần thiết để một thay đổi đi từ máy của nhà phát triển đến khi được giao cho khách hàng theo tất cả các cách cần thiết. .NET bắt đầu với một đồ thị phụ thuộc sản phẩm tương đối đơn giản và các công cụ phù hợp để quản lý đồ thị đó. Khi nó phát triển, các kho lưu trữ mới được thêm vào đồ thị và cần có luồng phụ thuộc bổ sung để xây dựng sản phẩm. Đồ thị trở nên phức tạp hơn. Chúng tôi đã phát minh ra các công cụ mới (Maestro, hệ thống luồng phụ thuộc của chúng tôi) để quản lý nó.

Các đồ thị phức tạp hơn có những nhược điểm đáng kể:

Càng nhiều cạnh và nút, thời gian đạt được sự mạch lạc càng lâu.
Các nhóm dễ mắc sai lầm hơn. Có nhiều điểm phối hợp hơn và nhiều điểm trong quy trình làm việc nơi con người có thể ảnh hưởng đến kết quả.
Sự phức tạp cũng có thể khuyến khích sự khác biệt trong môi trường build và yêu cầu. Thật khó để giữ mọi người thống nhất về cùng một quy trình khi các nhóm di chuyển và nâng cấp ở các tốc độ khác nhau.

Chi phí overhead trong xây dựng sản phẩm

Chúng tôi định nghĩa overhead là “lượng thời gian không dành để tích cực sản xuất các artifacts mà chúng tôi có thể giao cho khách hàng“. Overhead là không thể tránh khỏi. Tuy nhiên, khi chúng ta thêm độ phức tạp vào quy trình xây dựng sản phẩm, đặc biệt là độ phức tạp trong đồ thị, overhead có xu hướng bắt đầu chiếm ưu thế trong quy trình. Nó như thể được nhân lên vậy.

Để hiểu overhead trông như thế nào trong một build .NET đơn lẻ, hãy xem xét một build runtime 8.0. Dữ liệu này được tạo bằng một công cụ tùy chỉnh có thể đánh giá một build Azure DevOps dựa trên một tập hợp các mẫu phân loại từng bước.

Kết quả cho thấy overhead (bao gồm cả xếp hàng đợi) chiếm tới 38,5% tổng thời gian build, và overhead (không bao gồm xếp hàng đợi) là 25,0%. Thời gian xếp hàng đợi chiếm 13,6%.

Điều nguy hiểm là chi phí này có xu hướng ẩn đi và tăng lên theo thời gian. Một build kho lưu trữ cục bộ cho nhà phát triển thường nhanh. Nhà phát triển không thấy bất kỳ overhead nào của hệ thống CI tổng thể trong build đó. Nhưng khi phóng to ra, overhead bắt đầu xuất hiện và chiếm tỷ lệ lớn hơn.

Nguồn gốc của Unified Build trong Source Build

.NET Source Build là một cách để các bản phân phối Linux có thể xây dựng .NET trong một môi trường biệt lập từ một bố cục nguồn thống nhất duy nhất. Microsoft bắt đầu làm việc với nó vào khoảng .NET Core 1.1. Nguồn gốc tinh thần của Unified Build phát triển từ các cuộc trò chuyện hành lang giữa nhóm làm việc trên .NET Source Build và nhóm chịu trách nhiệm về bản phân phối của Microsoft. Tôi sẽ không nói rằng đó không phải là sự ghen tị khi các nhóm cơ sở hạ tầng thường nhìn vào thời gian xây dựng sản phẩm .NET trong cơ sở hạ tầng Source Build. 50 phút! Ngắn hơn thời gian xây dựng chỉ riêng kho lưu trữ runtime từ đầu trong bản build CI chính thức của nó.

Tất nhiên, đây không phải là sự so sánh hoàn toàn công bằng. Source Build:

Chỉ xây dựng một nền tảng.
Không xây dựng bất kỳ tài sản nào chỉ dành cho Windows.
Không xây dựng các workload .NET.
Không thực hiện bất kỳ đóng gói trình cài đặt nào.
Không xây dựng các bài kiểm tra theo mặc định

Tất cả đều là những hạn chế rất hợp lý. Nhưng đủ để tạo ra sự khác biệt hàng chục giờ trong thời gian build? Không có khả năng. Nhiều khả năng là phương pháp Source Build có độ phức tạp thấp và overhead thấp.

Tại sao nó khó? Một chuyến đi vào vùng đất của Source Build

Để cho phép các đối tác phân phối của chúng tôi phân phối .NET, chúng tôi cần sản xuất một hệ thống cơ sở hạ tầng tạo ra .NET SDK trong các ràng buộc sau:

Triển khai đơn lẻ! – Chỉ một triển khai cho mỗi thành phần
Nền tảng đơn lẻ – Chỉ xây dựng cho một nền tảng
Build đơn lẻ – Chỉ xây dựng trên một máy. Không thể yêu cầu cơ sở hạ tầng điều phối phức tạp.

Yêu cầu Build của Bản phân phối Linux

Các bản phân phối Linux thường có các quy tắc chặt chẽ hơn và ít linh hoạt hơn khi xây dựng phần mềm. Build thường được hoàn thành ngoại tuyến (ngắt kết nối internet). Nó chỉ có thể sử dụng làm đầu vào các artifact đã được tạo trước đó trong hệ thống build đó. Các tệp nhị phân được kiểm tra không được phép. Bất kỳ mã nguồn nào trong kho lưu trữ phải đáp ứng các yêu cầu cấp phép nghiêm ngặt.

Build đơn lẻ – Một khung điều phối để kết nối toàn bộ stack

Như bạn đã biết, build .NET, giống như nhiều sản phẩm, thực sự bao gồm các build Azure DevOps của các thành phần khác nhau, được kết nối với nhau bằng các bản cập nhật phụ thuộc. Điều này có nghĩa là thông tin và cơ chế cần thiết để xây dựng sản phẩm được phân phối giữa các kho lưu trữ. Điều này không thể sử dụng được cho các đối tác phân phối Linux của chúng tôi. Họ cần có khả năng xây dựng sản phẩm mà không cần truy cập vào các tài nguyên Microsoft này.

Tầm nhìn – Mơ về Unified Build

Unified Build tìm cách áp dụng các nguyên tắc chung của Source Build cho đối tác phân phối Linux vào sản phẩm mà Microsoft phát hành. Đạt được điều này sẽ mang lại lợi ích lớn cho các đối tác phân phối Linux, những người đóng góp thượng nguồn và Microsoft, giảm chi phí bảo trì và cải thiện khả năng xây dựng và phát hành nhanh chóng.

.NET đã đưa ra các mục tiêu cấp cao sau:

Một commit git duy nhất biểu thị tất cả mã nguồn sản phẩm cho một build .NET cụ thể. Tất cả các commit đều mạch lạc.
Một commit repo duy nhất có thể tạo ra một build có thể phát hành.
Build của .NET sẽ có thể tạo bản phân phối cho một nền tảng cụ thể trong một môi trường build duy nhất.
Người duy trì bản phân phối .NET sẽ có thể cập nhật và xây dựng .NET một cách hiệu quả trong toàn bộ vòng đời của một phiên bản .NET.
Người duy trì bản phân phối .NET có thể tạo ra các bản phân phối hạ nguồn mà không cần sử dụng các dịch vụ do Microsoft cung cấp.
Người duy trì bản phân phối .NET sẽ có thể đáp ứng các yêu cầu về xuất xứ và môi trường build cho các bản phân phối của họ.
Người duy trì bản phân phối .NET sẽ có thể điều phối việc vá lỗi các bản phân phối hạ nguồn.
Người duy trì bản phân phối .NET có thể chạy các bài kiểm tra xác thực đối với sản phẩm đã xây dựng.
Người đóng góp .NET sẽ có thể dễ dàng tạo ra các bản build sản phẩm đầy đủ để thử nghiệm, thí điểm, v.v.
Người đóng góp .NET sẽ có thể làm việc hiệu quả trên phần sản phẩm mà họ quan tâm.

Tuy nhiên, để đạt được điều đó sẽ đòi hỏi giải quyết một núi vấn đề mới.

Thực thi Tầm nhìn – Phát hành Unified Build

Dự án Unified Build có thể được chia thành 4 giai đoạn:

Động não và thiết kế ban đầu (.NET 7) – Công việc thiết kế ban đầu bắt đầu vào đầu năm 2022 và mất ~4 tháng để hoàn thành.
Công việc nền tảng (.NET 8) – Tập trung vào cải thiện tính bền vững của cơ sở hạ tầng Source Build.
Khám phá Vertical Build/Luồng mã (Đầu .NET 9) – Triển khai vertical build cho mỗi trong 3 họ hệ điều hành chính: Mac, Windows và Linux.
Đưa vào sản xuất (Cuối .NET 9 – .NET 10) – Triển khai cuối cùng bắt đầu một cách nghiêm túc và cuối cùng đã phát hành với .NET 10 RTM!

Sau gần 4 năm mơ ước và làm việc, Unified Build đã được phát hành cùng với .NET 10 RTM!

VMR – Kho lưu trữ Monolithic Ảo

dotnet/dotnet VMR, hay “Virtual Monolithic Repository” tạo thành nền tảng của dự án Unified Build. Đây là bố cục nguồn mà từ đó tất cả .NET được xây dựng, bao gồm cả bởi các đối tác phân phối Linux của chúng tôi. Nó cho phép các nhà phát triển làm việc cả trong kho lưu trữ thành phần riêng lẻ của họ, nơi các quy trình làm việc phát triển có thể rất tinh vi, cũng như trong VMR khi cần các thay đổi xuyên suốt. .NET có được hầu hết lợi ích của thế giới repo phân tán mà không có vấn đề về tính mạch lạc.

Vertical Build

Vertical Build là sự chuyển hướng của .NET sang sản xuất tài sản trong một loạt các vertical. Một vertical được định nghĩa là một lệnh build duy nhất trên một máy duy nhất xây dựng một phần của sản phẩm .NET mà không cần đầu vào từ các vertical khác. Thông thường, chúng tôi chia các vertical theo runtime mà chúng tôi đang cố gắng tạo ra. Tổng cộng có 35-40 vertical khác nhau.

Luồng mã

Có lẽ khía cạnh thú vị nhất của dự án Unified Build là cách quản lý luồng mã. Đây là nơi .NET đảo ngược các mẫu phát triển tiêu chuẩn. Duy trì sản phẩm như một đồ thị các thành phần phụ thuộc lẫn nhau trong khi làm phẳng luồng mã vào một bố cục mạch lạc được chia sẻ đòi hỏi “luồng mã hai chiều”. Các thay đổi cần chảy từ các thành phần vào bố cục được chia sẻ và các thay đổi trong bố cục được chia sẻ cần có khả năng chảy ngược lại các kho lưu trữ thành phần.

Xác thực Kiểm tra Kịch bản

Trụ cột lớn cuối cùng của Unified Build là kiểm tra kịch bản bổ sung. Mục tiêu là thêm các bài kiểm tra bao phủ các phần rộng lớn của chức năng sản phẩm không được gắn trực tiếp với hệ thống build hoặc cơ sở hạ tầng kho lưu trữ. Thay vào đó, chúng thực thi dựa trên sản phẩm cuối cùng đã được xây dựng.

Kết quả

Vậy, .NET đã đạt được gì sau gần 4 năm mơ ước, lên kế hoạch và làm việc chăm chỉ?

Tính linh hoạt, khả năng dự đoán và tốc độ

Lợi tức đầu tư lớn nhất mà chúng tôi thấy là tính linh hoạt. Xây dựng sản phẩm phân tán chậm. Sản xuất các build mạch lạc chậm. Luồng phẳng (flat flow) loại bỏ vấn đề mạch lạc đó, tách biệt cái gì và làm thế nào. Điều này cực kỳ giá trị trong quá trình hướng tới một bản build RTM hoặc một bản phát hành bảo trì.

Về tốc độ, .NET đã đặt mục tiêu sản xuất một bản build chưa ký trong vòng chưa đầy 4 giờ, đã ký trong vòng chưa đầy 7 giờ. Đây là mức giảm đáng kể so với thời gian dài hơn nhiều trong .NET 8.0 và .NET 9.0. Một build 8.0 hoặc 9.0 có thể dễ dàng chạy đến 24 giờ ngay cả khi mọi thứ diễn ra hoàn hảo.

Tính mạnh mẽ và đầy đủ của cơ sở hạ tầng

Đằng sau các số liệu hào nhoáng, có nhiều năm cải tiến chất lượng cuộc sống cho cơ sở hạ tầng. Các cải tiến đối với cơ sở hạ tầng Source Build trong .NET 8 đã giảm chi phí duy trì Source Build của bản phân phối Linux. Công cụ ký tên của chúng tôi đã phải được đại tu để hỗ trợ ký trên mọi nền tảng cho nhiều loại archive.

Hướng đi tương lai

Trong .NET 11, chúng tôi sẽ thực hiện các cải tiến nhắm mục tiêu đến cơ sở hạ tầng để cải thiện quy trình làm việc và UX của nhà phát triển, chủ yếu xoay quanh luồng mã. Một lĩnh vực tôi đặc biệt hào hứng là các tác nhân AI giám sát luồng mã, kết nối các dấu chấm giữa các hệ thống khác nhau liên quan đến việc tạo ra sản phẩm và xác định các vấn đề.

Ngoài ra, sau .NET 11, một nỗ lực khác để loại bỏ các điểm nối (join points) có thể nằm trong tầm ngắm. Lợi ích khá rõ ràng: đơn giản hơn, nhanh hơn và thân thiện hơn với người đóng góp.

Kết luận

Bạn đã học được rằng các mô hình xây dựng sản phẩm với luồng phụ thuộc phân tán không phải lúc nào cũng phù hợp để phát hành phần mềm một cách đáng tin cậy và có thể dự đoán được. Các hệ thống này có xu hướng có độ phức tạp và overhead cao, làm tăng thêm thời gian. Bạn đã đọc về nguồn gốc của dự án .NET Unified Build trong .NET Linux distro Source Build và điều gì đã khiến việc áp dụng các khái niệm đó vào .NET trở nên khó khăn. Cuối cùng, bạn đã học được cách .NET áp dụng các khái niệm đó và những cải thiện đáng kể mà chúng tôi đã thấy trong công việc hàng ngày của mình.

Bài viết chi tiết về các thuật toán luồng mã phẳng sẽ sớm được đăng tải. Hãy theo dõi!

Tái phát minh cách .NET xây dựng và phát hành (Một lần nữa)