Hành trình chuyển đổi sang Git của Windows và thành tích ấn tượng: 1.760 bản build Windows chỉ trong một ngày

Trong tháng Hai vừa qua, Microsoft đã ra một thông báo bất ngờ khi cho biết nhóm phát triển Windows sẽ chuyển sang sử dụng hệ thống kiểm soát phiên bản mã nguồn mở Git thay vì công cụ của Microsoft. Gần 3 tháng sau tuyên bố này, khoảng 90% đội ngũ kỹ thuật của Windows đã thực hiện việc chuyển đổi.

Tại sao Microsoft lại ra quyết định này?

Quá trình chuyển đổi này được thúc đẩy bởi một vài yếu tố. Vào năm 2013, công ty đã bắt tay vào thực hiện dự án OneCore của mình, nhằm hợp nhất bộ phận phát triển Windows khác nhau và tạo ra cho hệ điều hành này một nền tảng gọn gàng hơn với các lớp và có tính module. Cùng lúc đó, Microsoft cũng sử dụng SourceDepot, một phiên bản tùy chỉnh của hệ thống kiểm soát phiên bản thương mại Perforce, cho tất cả các dự án lớn của mình.

Hình ảnh minh họa cho mục tiêu "Windows as a service"

SourceDepot không thể xử lý một dự án với kích cỡ lớn như Windows, do đó, thay vì để toàn bộ hệ điều hành trong một kho lưu trữ (repositor) duy nhất, bộ code của Windows được chia thành 65 bộ lưu trữ khác nhau, với một loại lớp ảo hóa được đặt trên đầu để mang lại cái nhìn thống nhất về cả bộ code đó. Một vài bộ lưu trữ đó chứa các thành phần hoàn toàn biệt lập, một số khác lại chỉ như lát cắt ngang của hệ điều hành, một số khác lại chi như cái túi chứa các mã code khác nhau. Vì vậy, cấu trúc kho chứa này không phù hợp với tính module hóa của OneCore.

Trong khi đó, Microsoft muốn một cấu trúc phù hợp hơn với OneCore. Họ cũng muốn một hệ điều hành phù hợp hơn với mục tiêu phát triển “Windows như một dịch vụ” và phát hành ra các bản nâng cấp nhỏ sau mỗi 6 tháng thay vì 3 năm một bản nâng cấp lớn như trước.

Bản thân nhóm phát triển Windows đã mở rộng đáng kể so với những ngày còn là Windows 7 và 8, với việc phản hồi khách hàng tốt hơn thông qua chương trình Insider Program. Nhóm phát triển cố gắng đáp ứng nhiều hơn với các báo cáo lỗi và đề xuất từ người dùng Windows, và các thay đổi này cũng cần được đưa lên hệ thống kiểm soát phiên bản.

Không những vậy, quy mô của bộ code Windows, với tổng số khoảng 3,5 triệu file, cũng đã đẩy SourceDepot đến giới hạn. Tổng số branch (một phân nhánh của phần mềm trong quá trình phát triển) được tạo ra mỗi ngày bị giới hạn ở con số 500. Do vậy, các nhóm phát triển phải suy tính trước xem liệu họ có thực sự muốn tạo ra branch đó không, và khi họ thấy thực sự cần làm một cái như vậy, họ sẽ phải tìm một branch cũ, không sử dụng nữa, yêu cầu nhóm tạo ra nó loại bỏ branch đó đi để hệ thống có đủ dung lượng cho một branch mới.

Giải quyết các vấn đề về hiệu suất chính là động lực lớn thứ hai cho việc chuyển ra khỏi SourceDepot tới một điều gì đó mới hơn.

Lớn hơn cả, công ty muốn phát triển một hệ thống kỹ thuật duy nhất (1ES), không chỉ kiểm soát phiên bản, mà còn theo dõi lỗi, xây dựng phần mềm, và có thể mở rộng cho toàn bộ công ty. Hiện tại, các nhóm khác nhau sử dụng nhiều hệ thống khác nhau, một số đã tự dịch chuyển sang Git, nhưng các sản phẩm khác, cũ hơn và lớn hơn, vẫn nằm trên SourceDepot. Các bộ phận khác của việc quản lý vòng đời ứng dụng (ALM) được xử lý bởi Visual Studio Team Service, phiên bản lưu trữ đám mây củ hệ thống ALM.

Chuyển đổi sang Git

Do có sự quen thuộc rộng rãi với các nhà phát triển và hỗ trợ mạnh mẽ cho việc tạo ra nhiều branch với mức chi phí thấp, công ty quyết định sử dụng Git làm hệ thống mới. Nhưng Git lại không được thiết kế để xử lý các bộ lưu trữ 300GB với số file lên tới 3,5 triệu. Microsoft phải bắt tay vào một dự án tùy chỉnh Git để có thể xử lý quy mô của công ty.

Quá trình này được chia thành 3 bộ phận chính. Đầu tiên là dự án Git Virtual File System (GVFS) để cho phép kho lưu trữ có thể tạo ra bản sao (được copy từ một máy chủ từ xa tới một bản sao trên máy chủ local, để nhà phát triển có thể làm việc ngay trên đó), mà không phải sao chép toàn bộ 300GB dữ liệu về. Thay vào đó, bản sao bộ khung của kho lưu trữ được tạo ra trên máy local, và các file mở ra sẽ được đẩy về theo yêu cầu từ máy chủ Git.

Bộ phận thứ hai là các cải tiến về thuật toán cho bản thân Git. Microsoft nhận ra rằng Git thường lấy về các file không cần thiết, và điều này có thể làm các hoạt động trên kho chứa bị chậm hơn khi số lượng file gia tăng. Với khoảng 3,5 triệu file, ngay một hoạt động đơn giản như tình trạng git – hiển thị những file nào đã được chỉnh sửa và thay đổi nào cần được thực hiện, cũng mất khoảng 30 phút.

Công ty cải thiện thuật toán để nâng cấp khả năng mở rộng và khả năng “nhận thức” của GVFS, chỉ liên lạc với các file đã nằm trên máy chủ local – những file mà GVFS chưa yêu cầu từ máy chủ rõ ràng không thể bị thay đổi, vì vậy chúng không cần kiểm tra những thay đổi đó. Điều này giúp giảm thời gian ghi tình trạng git xuống chỉ còn 9 giây.

Tuy nhiên, khi ngày càng nhiều nhà lập trình Windows chuyển sang Git, họ liên lạc với ngày càng nhiều file hơn, và làm quá trình này lại bị kéo dài thêm lên thành 11 giây. Thường các file này không thực sự được chỉnh sửa, mà nó chỉ được nạp khi xây dựng hoặc sửa lỗi nào đó.

Do vậy, công ty lại tiếp tục tối ưu hiệu suất hệ thống: thay đổi Git để sao cho, trong khi mở rộng nhất có thể, nhưng không làm thay đổi tổng số file trong kho chứa hay số file được lấy ra và lưu trữ trên máy local. Nhờ đó, việc ghi trạng thái git giảm xuống chỉ còn 2,3 giây và mục tiêu là giảm xuống dưới 1 giây.

Điều thứ ba công ty làm được là xây dựng một máy chủ proxy Git, để các nhóm từ xa với các kết nối có băng thông thấp, độ trễ cao, có thể dễ dàng làm việc trên bộ code Windows. Sao chép kho chứa Windows từ trụ sở ở Redmond đã mất đến 127 giây, bản thân kho chứa được lưu trên Azure nằm ở bờ Đông, vì vậy có thể đảm bảo băng thông cao và độ trễ thấp. Với hoạt động kể trên, quá trình này giảm xuống còn 70 giây – nhanh hơn nhiều so với trước.

Những con số ấn tượng

Kho chứa Windows giờ có khoảng 4.400 brach đang hoạt động, với 8.500 code được đẩy lên và khoảng 6.600 code được review mỗi ngày. Một con số đáng kinh ngạc – 1.760 bản build Windows được tạo ra trong một ngày – nhiều hơn cả chương trình Windows Insider xử lý vào lúc nhanh nhất.

Trong khi SourceDepot có xu hướng buộc các branch phải duy trì trong thời gian dài, giờ đây Git cho phép công ty có thể sử dụng mô hình thông thường của các branch ngắn. Giờ đây, khi một branch được tạo ra và bắt đầu phát triển, khi hoàn thành nó sẽ được hợp nhất vào cây phát triển chính, và branch đó đóng lại. Ngoài ra Git cũng cho phép các nhà phát triển tự quyết định nhiều chi tiết đến mức đáng ngạc nhiên, như cách hiển thị các commit theo toàn bộ lịch sử hay thu gọn lại.

Hơn nữa do Git là mã nguồn mở, nên Microsoft có thể chỉnh sửa client của Git để làm nó hiểu được GVFS và sử dụng các thuật toán để mở rộng theo số lượng file chỉnh sửa. Hiện tại, GVFS phải sử dụng với máy chủ Git là một phần của VSTS, và chỉ có những yêu cầu mở rộng mới sử dụng file theo cách GVFS đòi hỏi.

Tuy nhiên, tham vọng của công ty là loại bỏ các phân nhánh này và tích hợp công việc vào dòng chính nhất có thể - với mục đích cuối cùng là tất cả các sửa đổi được các nhà phát triển Git chính chấp nhận và được kết hợp vào codebase tiêu chuẩn của Git.

Để làm điều này dễ dàng hơn, công ty đang dịch chuyển theo hướng phát triển mở - với các bản cập nhật thường xuyên và cởi mở với các đóng góp từ bên ngoài. Các bên thứ ba cũng cho thấy sự quan tâm của họ với quá trình này: Atlassian SourceTree đã bổ sung thêm hỗ trợ GVFS, và TowerGit sẽ sớm bổ sung khả năng hỗ trợ này. Visual Studio đã tích hợp Git sẽ thêm hỗ trợ GVFS vào trong bộ Visual Studio 2017 Update 3.

Microsoft cũng cho biết, họ đang thảo luận với cả Google và Facebook - hai công ty đều gặp các vấn đề tương tự khi mở rộng phát triển trên Git. Các công ty này đều có hệ thống nội bộ riêng để xử lý các tải công việc của họ, và có thể chúng ta sẽ thấy họ hợp tác với nhau trong tương lai.

Những bộ phận cuối cùng của nhóm Windows còn sử dụng SourceDepot sẽ chuyển sang Git trong vài tháng tới. Sau đó, toàn bộ hệ thống mới sẽ được triển khai ra sang các bộ phận khác ngoài Windows, với các nhóm phát triển khác đang thực hiện việc chuyển đổi.

Theo Arstechnica