Quá trình Microsoft Office di chuyển từ Source Depot sang Git

• Microsoft Office đã sử dụng hệ thống quản lý mã nguồn nội bộ Source Depot trong thời gian dài, sau đó thực hiện một cuộc di chuyển quy mô lớn sang Git nhằm cải thiện trải nghiệm nhà phát triển và thúc đẩy đổi mới công nghệ
• Source Depot có những giới hạn về năng suất do mô hình tập trung, phân nhánh chậm và quy trình làm việc bất tiện; việc chuyển sang Git đòi hỏi hàng trăm kỹ sư và nhiều năm thực hiện
• Trong quá trình di chuyển, nhóm đã vượt qua các thách thức kỹ thuật và tổ chức quy mô lớn như phát triển công nghệ mới như VFS for Git, chuyển hệ thống build/test hiện có và vận hành song song hai hệ thống
• Để bảo đảm việc chuyển đổi thành công, dự án nhấn mạnh cách tiếp cận mang tính hợp tác và đặt con người làm trung tâm như mạng lưới giao tiếp xoay quanh các “champion”, tính minh bạch mạnh mẽ, đào tạo thực dụng và chiến lược rollback tức thì
• Sau di chuyển, dự án ghi nhận các kết quả tích cực như giảm thời gian onboarding, mức độ ưa chuộng Git tăng lên (89%) và năng suất được cải thiện, đồng thời để lại những bài học cốt lõi về thay đổi công nghệ quy mô lớn

---

Từ Source Depot sang Git: trải nghiệm di chuyển quy mô lớn của Microsoft Office

Thách thức mới mang tên tối đa hóa năng suất nhà phát triển

• Việc nâng cao năng suất nhà phát triển là 'Multiplier work', và giá trị của nó càng lớn trong các tổ chức quy mô lớn
• Dự án di chuyển Microsoft Office từ Source Depot sang Git là một ví dụ tiêu biểu
• Đây không chỉ là thay đổi công cụ, mà là một dự án lớn kéo dài lâu năm với hàng trăm kỹ sư và các hệ thống phức tạp

Source Depot: câu chuyện quản lý mã nguồn của một thời

• Đầu những năm 2000, Microsoft vận hành Source Depot, một hệ thống quản lý phiên bản nội bộ dựa trên công nghệ Perforce
• Source Depot có những giới hạn về hiệu quả làm việc như phân nhánh chậm, kiến trúc tập trung, thời gian checkout mã dài và cơ chế merge bất tiện (Reverse/Forward Integrate)
• Toàn bộ hạ tầng phát triển (build, phát hành, workflow) gắn chặt với hệ thống này, nên không thể thay thế đơn giản
• Việc chuyển Office sang Git đòi hỏi nhiều năm cùng nỗ lực của hàng trăm kỹ sư

Bắt đầu từ OneNote: khởi điểm của quá trình di chuyển

• Trong tổ chức kỹ thuật của Office, chi phí duy trì và vá lỗi Source Depot cùng nhu cầu về “công nghệ có tính cạnh tranh” đã dẫn tới quyết định chuyển mạnh sang Git
• Bộ sản phẩm Office có lịch phát triển khác nhau theo chu kỳ phát hành (vài tháng, nửa năm, hàng tháng, Insider), nên cần vận hành song song Source Depot và Git trong thời gian dài
• Các nhiệm vụ bắt buộc xuất hiện gồm đảm bảo tính nhất quán quản lý phiên bản của Office, xác minh build và chuyển hạ tầng kiểm thử kế thừa

Quy mô Office và chiến lược truyền thông

• Khi đó, Office là một tổ chức cực lớn với 4.000 kỹ sư cùng cộng tác
• Mỗi nhóm được chỉ định một 'Developer Satisfaction Champion', và thông qua mô hình hub-spoke đã hình thành cấu trúc phản hồi và giao tiếp thông suốt giữa các nhóm
• Tác giả là champion của OneNote và đảm nhận vai trò nòng cốt tại hiện trường của cuộc di chuyển quy mô lớn

VFS for Git: vượt qua giới hạn của codebase khổng lồ

• Quy mô mã nguồn lớn đến mức chỉ một lần git clone cũng cần hơn 200GB, nên nhóm đã giải quyết vấn đề bằng Virtual File System for Git (VFS for Git) được phát triển cùng GitHub
• VFS for Git vượt qua giới hạn của Git mặc định bằng cách chỉ tải về những tệp thực sự được sử dụng
• Đây là trải nghiệm vượt qua giới hạn của một trong những hệ thống quản lý phiên bản lớn nhất ngành, với sự phối hợp cùng Microsoft Windows

Cách tiếp cận theo từng giai đoạn của quá trình di chuyển

Giai đoạn 1: vũ trụ song song (Parallel Universe)

• Nhóm xây dựng một dịch vụ bridge đồng bộ Source Depot và Git theo thời gian thực, liên tục cải thiện các vấn đề về sai lệch giữa hai hệ thống và khác biệt mô hình (cấu trúc nhánh, changelist, v.v.)
• Quy trình đồng bộ hóa và build cho các nhánh main/private của Office được vận hành bằng một hệ thống tự động 24/7
• Sau ba lần thử lại, nhóm mới triển khai được hệ thống song song hoạt động ổn định

Giai đoạn 2: xác minh tính tương đương

• Toàn bộ test suite được chạy lặp đi lặp lại trên cả hai hệ thống để chứng minh kết quả build hoàn toàn giống nhau
• Những khác biệt tinh vi như cách xuống dòng, chữ hoa/chữ thường và định dạng kết quả kiểm thử đã được debug và xử lý trong nhiều tháng
• Với kết quả 'Green across the board' (kiểm thử đều vượt qua trên cả hai hệ thống), nhóm đã sẵn sàng bước vào giai đoạn chuyển đổi thực tế

Cách tiếp cận lấy con người làm trung tâm

Giao tiếp đa kênh, lặp đi lặp lại

• Để đồng bộ lịch trình của hơn 4.000 kỹ sư và hàng chục nhóm, dự án xây dựng hệ thống giao tiếp chuyên sâu với champion của từng nhóm
• Thông báo quan trọng được lặp lại ít nhất 3 lần (email, Teams, wiki, họp, v.v.) để giảm thiểu nhầm lẫn
• Khi phát sinh sự cố, nhóm tạo dựng niềm tin bằng cách công khai thông tin ngay lập tức và minh bạch

Đào tạo áp dụng Git và thích nghi

• Với những kỹ sư đã quen với Source Depot suốt 10 năm, nhóm chuẩn bị hệ thống học theo từng bước như môi trường đào tạo thực hành và hướng dẫn lệnh chuyển đổi
• Thông qua thư viện video tập trung vào thực chiến, dự án cung cấp học tập dựa trên các kịch bản thực tế
• Mục tiêu không chỉ là giảm lo lắng và tăng năng lực, mà còn hỗ trợ họ thích nghi với workflow hiện có

Chiến lược rollback và cơ chế an toàn

• Khi chuyển đổi thực tế, nhóm trao cho Director một 'nút đỏ', để có thể rollback ngay bất cứ lúc nào nếu xảy ra vấn đề nghiêm trọng
• Một phần lịch sử cũ của Source Depot cũng được lưu giữ trong thời gian dài, giúp bảo toàn an toàn lịch sử phát triển trước đó

Kết quả và thành tựu chính

• Sau khi chuyển đổi, dự án ghi nhận thời gian onboarding giảm 50%, mức độ ưa chuộng Git đạt 89%, hiệu năng build được cải thiện, hiệu quả code review và hợp tác tăng lên, từ đó mang lại tác động nâng cao năng suất
• Các kỹ sư cũng đánh giá tích cực việc có được những kỹ năng có thể chuyển đổi trong toàn ngành
• Khả năng để nhân sự mới tham gia công việc ngay lập tức cũng được nâng cao

Bài học cốt lõi từ một cuộc di chuyển quy mô lớn

• Để thành công, cần đầu tư vượt xa dự kiến không chỉ vào yếu tố kỹ thuật mà còn vào giao tiếp lấy con người làm trung tâm
• Cần nhấn mạnh việc xây dựng hệ thống vận hành song song, chứng minh tính tương đương tuyệt đối, thiết kế rollback chắc chắn ngay từ đầu và vai trò của nhân sự nòng cốt (champion)
• Việc đo song song các chỉ số định tính như mức độ hài lòng là bắt buộc; trong quá trình thay đổi, sự ổn định tổ chức và cảm giác an toàn tâm lý là rất quan trọng
• Bản chất của thay đổi quy mô lớn là quản trị thay đổi linh hoạt và có hệ thống trên toàn tổ chức

Kết luận và khả năng áp dụng về sau

• Cuộc di chuyển sang Git của Office là một dự án mang tính lịch sử, được hình thành qua nhiều năm chuẩn bị và nhiều tháng thực thi
• Sau cùng, đây được ghi nhận là một ví dụ thành công về thúc đẩy thay đổi tổ chức trong khi vẫn bảo đảm tính liên kết công việc của hàng nghìn người
• Trong các thay đổi quy mô lớn khác như chuyển đổi đám mây, tách rời kiến trúc nguyên khối hay nâng cấp framework, các nguyên tắc xác minh song song, giao tiếp lặp lại và thiết kế rollback nhanh đều có thể áp dụng tương tự
• Dù chưa đi sâu thêm vào các chi tiết kỹ thuật (hạ tầng build, vấn đề offline/hợp đồng, v.v.), bài học quan trọng nhất vẫn là cách tiếp cận chiến lược và tổ chức đối với thay đổi công nghệ quy mô lớn

[ndrgrd]

Nếu xử lý nhiều tệp nhị phân thì có thể Git không thật sự phù hợp, nhưng với các kho lưu trữ tập trung vào mã nguồn thì có vẻ Git là đủ.

[rtyu1120]

Có lẽ đây cũng là một thay đổi lớn ngay trong nội bộ MS, nhưng nhờ đó những tính năng như partial clone, sparse checkout hay các công cụ như Scalar cũng được công khai ra bên ngoài để có thể sử dụng, điều này có vẻ cũng là một tác động tích cực haha

[GN⁺]

Ý kiến Hacker News

• Tôi luôn thấy thú vị khi đọc những bài viết kể lại câu chuyện cũ theo cách mới. Bình luận này chỉ ra rằng bài gốc có nhắc đến việc “mất vài giờ để tải toàn bộ kho Office”, nhưng gần như bỏ qua thực tế rằng với git, việc đó hầu như không khả thi nếu không có hệ thống tệp mới như VFS. Với Perforce, người dùng có thể chỉ checkout phần mình cần, nên có lẽ đa số người dùng Source Depot cũng không kéo toàn bộ ứng dụng Office mỗi lần mà chỉ lấy phần cần thiết. VFS thu hẹp khoảng cách này bằng cách chỉ tải xuống các object cần dùng trong git. Perforce/Source Depot là một lựa chọn VCS tập trung rất mạnh vào thời điểm đó, nhưng giờ cảm giác thời thế đã thay đổi
  • Có công ty đã tự phát triển công nghệ cho Perforce để chỉ lấy file khi thực sự cần, tương tự như VFS. Điều này đặc biệt quan trọng trong phát triển game, nơi vừa lưu file văn bản vừa lưu các tài sản nguồn nhị phân dung lượng lớn. Tôi nghĩ nó có cùng gốc công nghệ với cơ chế mà chương trình ổ đĩa từ xa tích hợp trong Windows sử dụng. Cá nhân tôi vẫn muốn một VCS kiểu máy chủ, nơi toàn bộ mã nguồn công ty được lưu trữ nhưng không cần sao chép toàn bộ lịch sử về máy cục bộ. Tuy vậy, git vẫn đủ tốt cho các cộng tác ngắn hạn giữa nhiều thiết bị, nên tôi vẫn chưa thấy cần phải dựng cả máy chủ trung tâm lẫn pipeline CI/CD. Tôi rất thích các workflow như stash, stage theo từng hunk, interactive rebase trong git
  • Công ty chúng tôi vẫn đang dùng Perforce, thật đáng tiếc vì giờ chẳng còn ai thích Perforce nữa. Tôi đã tận mắt thấy ánh mắt của người mới vào vụt tắt khi nói với họ rằng “chúng tôi không dùng git”
  • VFS không thể thay thế hoàn toàn Perforce. Trên thực tế, phần lớn các công ty game AAA vẫn dùng Perforce. Cần phải khóa file tài sản để tránh hai người cùng sửa rồi rơi vào tình huống không thể merge, và điều đó rất cần thiết để giảm lãng phí khi phải bỏ đi thành quả làm việc của một artist
  • Thành thật mà nói tôi không hiểu vì sao git đến giờ vẫn chưa hỗ trợ checkout có chọn lọc các phần cụ thể trong cây kho mã. Tôi nghĩ chỉ cần gắn thêm một dịch vụ trung gian hiểu được object file các thứ là có thể mở rộng khá dễ
• Trong kỳ thực tập tại Microsoft năm 2016, tôi từng làm một công cụ review mã tự động hỗ trợ Source Depot và đã mất gần cả tuần cho tính năng này dù lúc đó còn chẳng biết Source Depot là gì (https://austinhenley.com/blog/featurestheywanted.html). Khi ấy vẫn còn rất nhiều lập trình viên dùng Source Depot. Tôi tự hỏi giờ họ đã chuyển hết sang git chưa
  • Tôi nhớ CodeFlow mỗi ngày. Đó thực sự là một công cụ tuyệt vời
  • Vẫn còn nhiều nơi đang dùng Source Depot rất активно. Các lệnh Source Depot và cấu hình môi trường của nó lúc nào cũng khiến tôi thấy căng thẳng
  • Hiện nay phần lớn công việc hằng ngày của tôi đã được xử lý bằng git
• Với tư cách người từng trực tiếp dùng vss (Visual SourceSafe) trong thập niên 90, tôi ngạc nhiên là bài này còn không nhắc đến nó. Visual SourceSafe là giao thức quản lý phiên bản mã nguồn do chính Microsoft tạo ra, khác với Source Depot là thứ được cấp phép từ Perforce
  • VSS (Visual SourceSafe) là sản phẩm Microsoft có được sau khi mua lại One Tree Software ở Raleigh, rồi đổi tên từ “SourceSafe” thành “Visual SourceSafe” và đóng gói kèm với Visual C, Visual Basic, v.v. Trước đó họ từng bán một sản phẩm quản lý phiên bản tên là “Microsoft Delta”, giá cao mà chất lượng thấp, lại còn không hỗ trợ NT. Một trong những người đến từ thương vụ One Tree là Brian Harry, người sau này dẫn dắt Team Foundation Version Control (TFS). TFS dùng SQL Server làm kho lưu trữ nên khả năng quản trị và độ tin cậy tốt hơn VSS rất nhiều. Có vẻ Brian Harry giờ đã nghỉ hưu và blog cũng không còn cập nhật nữa. Một điều tôi còn nhớ khi dùng VSS là nó xử lý network file locking bằng SMB nên rất dễ gặp lỗi mạng thường xuyên, và kho lưu trữ hay bị hỏng. Vì vậy chúng tôi phải đặt một batch job khôi phục chạy mỗi đêm để tự sửa trong lúc không ai dùng, vì sáng hôm sau còn phải làm việc
  • Theo trải nghiệm dùng VSS trong thập niên 90, nó gần như là cơn ác mộng khi làm việc theo nhóm, và theo tôi biết thì ngay cả Microsoft nội bộ cũng hầu như không dùng
  • Tôi từng dùng VSS khi phát triển một mình trong thập niên 90 và khi đó nó như mở ra cả thế giới mới. Ở bậc cao học tôi đã tiếp xúc với các VCS khác như RCS, CVS, v.v. Tôi nhớ khi vào Microsoft năm 2004, có người giải thích với tôi rằng VSS không an toàn và rất dễ hỏng. Tôi không biết điều đó có hoàn toàn đúng không, nhưng dù sao trong công ty VSS cũng chưa từng là một lựa chọn
• Tôi từng là thành viên trong nhóm di chuyển Microsoft từ XNS sang TCP/IP. Công việc đó thật ra không phức tạp như tưởng tượng, nhưng tôi rút ra được bài học tương tự. Còn chuyển từ MSMAIL sang Exchange thì thực sự rất vất vả
  • Tôi từng thấy một khung biển số xe có dòng “Exchange: The Most Feared and Loathed Team in Microsoft”, và tự hỏi liệu có phải vì những trải nghiệm hồi đó không. Chuyện đã hơn 20 năm nên tôi không nhớ chính xác câu chữ
• Câu “Authenticity mattered more than production value” thực sự chạm đến tôi. Là một cựu nhân viên Microsoft từng làm ở một dòng sản phẩm nhỏ chỉ mới bắt đầu chuyển từ Source Depot sang Git ngay trước khi tôi nghỉ việc vào năm 2015, tôi hoàn toàn đồng cảm với lượng công sức khổng lồ cần cho việc này. Đây thật sự là một thành tựu ấn tượng
  • Tôi cũng thấy khó tin là mình đã trải qua hết những quá trình đó. Xin cảm ơn
• Nhìn lại bối cảnh Microsoft phải đối mặt vào đầu những năm 2000, Windows ngày càng cực kỳ phức tạp và cần quản lý phiên bản cho hàng triệu dòng mã, trong khi git còn chưa tồn tại và SVN mới chỉ bắt đầu phát triển. Tôi tự hỏi liệu Microsoft khi đó có từng nghiêm túc cân nhắc các sản phẩm thương mại như BitKeeper, được phát triển năm 1998 và công bố năm 2000, hay không. Có lẽ lúc ấy các hệ thống tập trung như Perforce là xu hướng chính, còn mô hình phân tán kiểu BitKeeper thì vẫn quá lạ hoặc chưa có nhiều minh chứng thực tế
  • Hồi đó đã có VSS (Visual SourceSafe), và sau này thì có TFVC
• Tôi muốn gửi lời cảm ơn tới các tech lead đã giải thích cho một kỹ sư mới vào nghề như tôi về những điều bí ẩn của Source Depot. Khi thực sự hiểu được cấu trúc của Source Depot, đó đúng là một khoảnh khắc bừng sáng. Tôi chỉ phụ thuộc vào WinCE và IE nên clone chỉ mất 20 phút chứ không phải nhiều ngày, thật may mắn. Tôi đã quên tên những người từng giúp mình, nhưng thái độ sẵn sàng hỗ trợ người mới để họ bắt đầu công việc dễ dàng hơn thì tôi vẫn tiếp tục duy trì với đội của mình đến tận bây giờ
• Đa số mọi người nhớ việc áp dụng git như một chiến thắng kỹ thuật, nhưng trên thực tế đổi mới thật sự là ở chỗ từng lập trình viên nay có thể tự kiểm soát workflow của mình. Không còn phải chờ cửa sổ đồng bộ, cũng không cần xin lead cấp quyền truy cập branch. Giờ mọi người đều có thể làm việc nhanh và tự do hơn mà vẫn không va chạm với nhau. Tôi có cảm giác thay đổi này tác động đến tinh thần làm việc còn lớn hơn rất nhiều so với bất kỳ dashboard năng suất nào. Git không chỉ là một công cụ mà còn thay đổi cả niềm tin vào vòng lặp phát triển
• Tôi tò mò Microsoft nội bộ rời bỏ Visual SourceSafe từ khi nào. Theo tôi họ đáng lẽ nên ngừng nó sớm hơn để ít nhất bên ngoài khỏi tiếp tục dùng
  • Tôi nghĩ đa số nhóm thực ra không dùng VSS. Khi làm ở Microsoft, nhóm chúng tôi dùng Source Depot. Tôi cũng từng dùng TFS và không thích lắm, nhưng sau khi dùng Source Depot thì lại thấy nhớ TFS
  • Tôi nghi ngờ việc Microsoft nội bộ có dùng VSS cho mục đích chính hay không. Nếu họ thực sự dùng nội bộ thì có lẽ họ đã không phát hành nó trong tình trạng lỏng lẻo như vậy. TFS là một trải nghiệm khó hiểu, cả bên trong lẫn bên ngoài đều không mấy ổn
  • Có lẽ là vào khoảng năm 2000. Dự án duy nhất tôi biết từng dùng nó là .NET, nhưng ngay cả dự án đó cũng đã chuyển sang Source Depot
  • Tôi thậm chí còn không biết là có Microsoft SourceSafe
• Tôi không thật sự hiểu câu chuyện OneNote shallow clone có dung lượng 200GB
  • Thực ra không phải OneNote, mà là shallow clone của toàn bộ Office
  • Có lẽ trong đó có video hoặc các tệp nhị phân dung lượng lớn