Công Cụ Kiểm Soát Phiên Bản Phân Tán

Anonymous trong Tối Ưu Hóa Hiệu Suất và DevOps

2008-01-01 Khoảng 1300 từ 6 phút

Khi mới tiếp xúc với các công cụ SCM, tôi bắt đầu với VSS. Tuy nhiên, chỉ vài ngày sau (khi chuyển công tác sang NetEase), tôi đã chuyển sang dùng CVS. Khoảng một năm sau, cả công ty lại chuyển từ CVS sang SVN. Người chủ trì cuộc “di cư” này từng nói rằng SVN là phiên bản hoàn thiện hơn của CVS (điều này vẫn còn tranh cãi). Tuy nhiên, theo trải nghiệm cá nhân, tôi thấy SVN tiện lợi hơn nhiều khi quản lý phiên bản nhiều tệp tin, bởi CVS không đảm bảo tính nguyên tử (atomicity) khi commit nhiều tệp cùng lúc.

Vài năm trước, tôi từng tranh luận với đồng nghiệp về ưu điểm giữa mô hình khóa của VSS và mô hình hợp nhất của CVS. Với tôi, câu trả lời dường như quá rõ ràng, nên tôi chẳng buồn tranh luận dài dòng. Dù trong một số trường hợp đặc biệt, chúng ta vẫn cần mô hình khóa để phối hợp công việc, nhưng đối với lập trình viên, rõ ràng chúng ta cần khả năng làm việc song song.

Chúng ta đã từng từ bỏ mô hình hợp tác khóa trong quá khứ, và giờ đây đã đến lúc thay đổi thêm một bước nữa. Có lẽ công cụ kiểm soát phiên bản phân tán chính là xu hướng tương lai. Tôi tin rằng một ngày nào đó, các hệ thống tập trung như CVS/SVN sẽ bị thay thế hoàn toàn.

Hãy cùng nhìn lại những khó khăn tôi từng trải qua - có thể nhiều nhóm phát triển khác cũng gặp phải:

Quy tắc nghiêm ngặt về commit: Chúng tôi cấm commit mã không biên dịch được, và khuyến khích không commit mã chưa qua kiểm thử. Kết quả là có thành viên gần một tháng trời không dám commit module phức tạp, vì luôn cảm thấy chưa hoàn thiện. Nhưng thực tế, hàng loạt thay đổi quan trọng lại không được lưu trữ dưới dạng phiên bản.
Hợp tác song song giữa hai người: Khi hai người cùng phát triển một module liên kết chặt chẽ, họ thường xuyên phải trao đổi mã qua lại. Để tiện lợi, họ dùng kho mã làm trung gian, dẫn đến hàng loạt phiên bản chưa hoàn thành tồn đọng trong kho.
Làm việc từ xa: Có người mang mã về nhà bằng laptop, nhưng phần code hoàn thiện ở nhà lại không thể commit được (vì kho mã nội bộ không truy cập từ mạng ngoài được).
Sợ commit khi chưa hoàn thiện: Một lập trình viên viết xong module nhưng còn bug chưa sửa xong, nên không dám commit. Đồng nghiệp muốn hỗ trợ debug nhưng không có cách nào chia sẻ đoạn code đang dở dang. Chạy sang máy người kia dùng “XP” (remote desktop)? Trời ơi, sao ai cũng dùng editor khác nhau, và còn thích dùng scheme màu sắc “độc” nữa chứ?

Chúng tôi từng thử giải pháp “chữa cháy” như tự tạo kho mã cục bộ. Nhờ TortoiseSVN, việc này trên Windows khá đơn giản. Nhưng quản lý nhiều kho riêng rẽ khiến người dùng cảm thấy phiền phức, nên không duy trì được lâu.

Khi đồng nghiệp hỏi về khác biệt giữa hệ thống phân tán và công cụ hiện tại, tôi trả lời: “Cốt lõi là khả năng hợp nhất kho mã một cách linh hoạt.” (Tôi tiếp cận chủ đề này chưa lâu, nên xin phép được nói theo cách hiểu đơn giản).

Hệ thống tập trung luôn yêu cầu có máy chủ trung tâm, mọi người phải đồng bộ nghiêm ngặt với kho mã. Khi dự án có ≥2 người tham gia, thường phát sinh các quy tắc như “không commit code dở dang”, dẫn đến những vấn đề tôi đã nêu.

Ngay cả khi làm việc một mình cũng gặp rắc rối. Có lần về nhà, thấy bố tôi (một lập trình viên kỳ cựu) đang phát triển dự án nhỏ trên 2 máy tính. Tôi đề xuất dùng SVN, và chọn giải pháp tạo kho trên USB. Nhưng mỗi lần cắm USB vào 2 máy lại nhận thành các ổ đĩa khác nhau (D:/ và E:/), khiến hệ thống liên tục báo lỗi.

Thực tế, phần lớn chúng ta chỉ cần quản lý phiên bản, chứ không nhất thiết phải hợp tác đa người trên cùng tệp. Trong công ty tôi, việc sửa code của người khác phải thông báo cho tác giả. Ai cũng cố gắng làm việc trong thư mục riêng. Tôi không đòi hỏi công cụ phân tán phải giải quyết bài toán phân bố địa lý, mà chỉ cần khả năng tạo nhánh riêng (hoặc nhóm nhỏ) và commit cục bộ dễ dàng. Chỉ cần tính năng hợp nhất kho là đủ.

Tôi vốn ít tiếp xúc với công cụ phân tán, cho đến khi Git ra đời. Với sự bảo chứng của Linus Torvalds, Git hẳn phải là công cụ chất lượng. Nếu bạn chưa biết Git là gì, hãy tham khảo [Git Tiếng Việt Tutorial].

Tiếc rằng Git hỗ trợ Windows còn hạn chế. Chúng tôi vẫn còn 50% dự án chạy trên Windows, và đa số lập trình viên dùng hệ điều hành này. Lý do được cho là Git phụ thuộc sâu vào các tính năng hệ thống tệp của Linux, trong khi Windows xử lý kém hiệu quả. Dù lý do có là gì, tôi cũng không tự tin lắm khi đề xuất chuyển sang Git trong công ty.

Một lựa chọn khác là Monotone, nhưng cũng gặp vấn đề tương tự về hỗ trợ Windows. Thú vị là Git chịu ảnh hưởng lớn từ Monotone (theo suy đoán của tôi). Cả hai đều viết bằng C++, dù Monotone ra đời sớm hơn (bắt đầu từ 2003).

Theo bài đánh giá của Mozilla: “Git không phù hợp với dự án đa nền tảng do thiên lệch UNIX, tương tự như Monotone.”

Vậy nên Mercurial (ký hiệu “hg” - tên hóa chất của thủy ngân :D) trở thành lựa chọn đáng cân nhắc. Công cụ này hiện là “ứng cử viên sáng giá” của Mozilla.

Một đối thủ khác là Bazaar, với website so sánh chi tiết với các công cụ khác. Dù có ý kiến cho rằng hiệu năng không cao, nhưng với quy mô dự án vừa và nhỏ như chúng tôi, điều này không thành vấn đề. Đặc biệt, tính năng “đổi tên thông minh” của Bazaar rất ấn tượng.

Ai từng dùng SVN hẳn ám ảnh với việc đổi tên thư mục - nếu không thực hiện trực tiếp trên kho mã, bạn sẽ phải xóa/add toàn bộ tệp tin. Ngay cả khi làm đúng cách, các client cũng phải thực hiện hàng loạt thao tác del/add, khiến tôi “đau tim” mỗi lần thấy ổ cứng kêu rào rào.

Darcs cũng là công cụ đáng chú ý, đặc biệt vì được viết bằng Haskell - ngôn ngữ mà tôi vốn có thiện cảm. Với tôi, phần mềm viết bằng Haskell đồng nghĩa với sự ổn định. Dù bản thân không dùng Haskell hay Python nhiều, nhưng nếu chọn một ngôn ngữ để tìm hiểu, tôi sẽ ưu tiên Haskell.

SVK có thể là