Tìm hiểu về các phương pháp quản lý mã nguồn trong phát triển lập trình

Khá lâu rồi mới có động lực tìm hiểu và viết về một chủ đề nào đó. Hôm nay mình trở lại để cũng nghiên cứu về các phương pháp quản lý mã nguồn trong phát triển lập trình. Mono repo và Multi repo là hai phương pháp quản lý mã nguồn phổ biến nhất hiện nay.

Khái niệm

Mono-repo là kiểu cấu trúc project trong đó tất cả module (hoặc project con) đều nằm trong cùng 1 git repository. Ví dụ: Dự án A có sử dụng nhiều module như base, network, UI, sercurity… và tất cả chúng được lưu trữ trong 1 git repository duy nhất.
Multi-repo là kiểu cấu trúc project trong đó mỗi module (hoặc project con) chứa ở những git repository riêng lẻ. Ví dụ: Dự án A có sử dụng nhiều module như base, network, UI, sercurity… và chúng được lưu trữ trong nhiều git repository khác nhau.

So sánh đánh giá giữa mono-repo và multi-repo

Dưới đây là một số điểm khác nhau giữa mono-repo và multi-repo:

	Mono-Repo	Multi-Repo
Quản lý phụ thuộc	Các phụ thuộc giữa các dự án và thành phần trong hệ thống thường được quản lý một cách trực tiếp. Điều này có thể giúp đảm bảo sự tương thích giữa các phần của hệ thống.	Quản lý phụ thuộc có thể phức tạp hơn. Việc theo dõi và đồng bộ hóa các phiên bản phụ thuộc có thể đòi hỏi sự quan tâm đặc biệt.
Quy mô và mở rộng	Mono repo thích hợp cho các dự án nhỏ hoặc trung bình, nơi tất cả các thành phần có thể được quản lý và triển khai cùng nhau. Nó cũng có thể dễ dàng mở rộng khi số lượng thành viên và dự án tăng lên.	Multi repo thường được sử dụng trong các dự án lớn và phức tạp, nơi các dự án độc lập cần được quản lý một cách riêng biệt. Nó cung cấp sự tách biệt giữa các thành phần, nhưng cũng đòi hỏi sự quản lý phụ thuộc và triển khai.
Tốc độ và hiệu suất	Vì tất cả mã nguồn được lưu trữ trong một git repository nên việc tìm kiếm, truy xuất và đồng bộ hóa có thể nhanh chóng và dễ dàng hơn.	Trong multi repo, việc tìm kiếm và truy xuất mã nguồn có thể phức tạp hơn vì phải tìm kiếm và điều hướng giữa nhiều git repository.
Tính tách biệt, độc lập	Commit history sẽ chứa tất cả các commit của project (bao gồm các module, project còn) sẽ khiến cho commit history bị rối, khó tìm kiếm và kiểm tra khi cần thiết	Các commit sẽ được độc lập theo từng module và project riêng vì chúng ở các repository khác nhau
Phân quyền	User chỉ tham gia vào 1 cấu phần/project sẽ có quyền truy cập vào toàn bộ source, tài nguyên trong project (bao gồm cả các module và project con)	User sẽ chỉ được cấp quyền truy cập vào module/project có liên quan và không thể truy xuất được vào các module khác không liên quan
Sự linh hoạt	Vì tất cả các project và module đều nằm trong cùng 1 git repository nên chúng sẽ phải áp dụng chung một Git Workflow.	Mỗi module (hoặc project còn) sẽ có 1 git repository khác nhau nên chúng có thể áp dụng các Git Workflow khác nhau tạo ra sự linh hoạt trong quá trình phát triển. Ví dụ: Main project sẽ có nhiều người tham gia sẽ có rất nhiều các commit, branch nên cần sử dụng Forking Workflow để tạo ra sự linh hoạt và độc lập cho từng thành viên… Module Networking sẽ có ít người tham gia và thay đổi ít sau khi release thì hoàn toàn có thể áp dụng Feature Branch Workflow
Đáp ứng việc phình lên của dự án	Theo sự phát triển của dự án thì git repository sẽ càng ngày sẽ phình to lên khi các module (hoặc project con) được update hoặc thêm mới	Khi dự án phình lên thì nó sẽ chỉ bị phình lên theo với từng module (hoặc project con) tương ứng
Dung lượng	Đối với những dự án lớn với nhiều resource (hình ảnh, video, audio …) thì việc tải source code với dung lượng lớn có thể rất tốn thời gian	Mình sẽ chỉ cần tải xuống những project (hoặc module con) cần thiết
Thời gian build	Khi build thì toàn bộ module (hoặc project con) sẽ được build lại dù nó không bị thay đổi gì giữa 2 bản build	Chúng ta có thể build của các module (hoặc project con) thành các file JAR, WAR, DLL, gói npm, gói Maven, Docker image và nhiều loại tài liệu khác và đẩy chúng lên Artifactory để quản lý và lấy về sử dụng. Và mỗi khi build project main thì những module đã được build và đẩy lên Artifactory trước đó sẽ không build lại, nên giảm rất nhiều thời gian build ứng dụng

Như mình biết hiện nay hầu hết các công ty lớn đều đã áp dụng multi repo trong việc phát triển như: Facebook, Ingenico, Zalo, Vin…

Trên đây là những tìm hiểu của mình về Mono-repo và multi-repo, còn việc đánh giá nên sử dụng cụ thể cấu trúc/phương pháp nào thì nó còn phụ thuộc vào phạm vi ứng dụng, số lượng thành viên, mong muốn của leader cũng như các thành viên trong dự án.

Nếu mình có gì sai sót hoặc còn thiếu mong mọi người có thể góp ý nhé