Nhiều dự án có tính chất khác nhau nhưng có liên quan với nhau thì bạn thích tích hợp chúng như thế nào (hoặc không tích hợp)?
Ví dụ, với cùng một dịch vụ có front-end, back-end(api), serverless, batch, pipeline, ... v.v.
-
Mono-repo
Nếu là cùng một dịch vụ thì chỉ có một repository! Mỗi dự án được tổ chức theo cấu trúc package/thư mục
-> Vậy quản lý commit thế nào..? CI/CD hay hook như pre-commit chắc sẽ phức tạp hơn.. -
Git Submodules
Nếu tính chất khác nhau thì ít nhất lịch sử git cũng nên được quản lý riêng! Nhưng vẫn cố gắng gộp tối đa vào một chỗ..
-> Có thêm đường cong học tập như sync submodule.. merge cũng phức tạp hơn.. liệu các lập trình viên khác có theo kịp không? -
repo tách riêng
Đơn giản thôi! Dự án khác nhau thì repository cũng tách riêng!
-> Muốn xem dịch vụ A thì phải vào repo nào? À cái này, cái kia,.. còn gì nữa nhỉ...
Có lẽ không có đáp án đúng tuyệt đối, nhưng mình tò mò mọi người thích cách nào/vì sao!
16 bình luận
Tôi thì theo kiểu mỗi repo tự lo một kiểu... Khi nảy ra câu hỏi như “Nếu tôi muốn xem lịch sử của API liên quan đến tính năng này thì պետք է xem ở đâu nhỉ?”, tôi thấy việc ghép một repo với một tính năng sẽ tiện hơn.
Tôi dùng monorepo trong hầu hết các trường hợp, nhưng có 2 trường hợp tôi dùng submodule.
Khi thuê publisher bên ngoài.
Khi không muốn công khai cho publisher bên ngoài những thứ ngoài phần thông tin cần cho việc publishing, tôi dùng submodule.
Khi cần tùy biến một giải pháp bên ngoài.
Đặc biệt với các giải pháp cung cấp tính năng plugin thì tôi dùng submodule.
Tôi đăng ký giải pháp bên ngoài đó dưới dạng submodule, rồi đưa các plugin của mình vào đường dẫn plugin bằng symlink hoặc cách tương tự. Các plugin của tôi được quản lý phiên bản riêng, còn giải pháp bên ngoài vẫn có thể giữ nguyên hệ thống version control của họ, đây là một ưu điểm.
Có vẻ trải nghiệm dùng submodule của mọi người đều không tốt nhỉ.. Giá mà có công cụ nào đó có thể cải thiện được thì hay biết mấy
Nếu tự tin chỉ làm merge commit thì mono-repo,
nếu sẽ rebase thường xuyên thì multi-repo,
submodule à? Cứ dùng liên kết thư mục mà OS cung cấp đi…
Trước đây tôi chỉ dùng các repo độc lập riêng lẻ, nhưng gần đây đã chuyển hẳn sang cách dùng submodule.
Trước kia do mức độ hiểu biết về git còn thấp nên tôi không thể tận dụng submodule đúng cách, nhưng hiện tại tôi nghĩ dùng submodule sẽ tốt hơn.
Tuy nhiên, khi dùng submodule thì phải commit cho submodule đó rồi lại phải commit thêm ở repo cha, nên có vẻ sẽ phát sinh vấn đề là thời điểm của hai bên bị lệch nhau, làm giảm tính nhất quán của repo.
https://monorepo.tools/
Nếu bạn chưa xem trang này thì rất đáng để xem thử.
Theo kinh nghiệm cá nhân của tôi, tôi không khuyến nghị submodule.
Nếu muốn chia sẻ code của kho lưu trữ khác bằng submodule thì có lẽ thà phát hành dưới dạng package sẽ tốt hơn.
Ở công ty tôi, số thành viên trong mỗi dự án ít, đồng thời ngôn ngữ và tech stack của frontend và backend cũng tách biệt, nên hầu như không có chuyện đóng góp chéo giữa các vị trí. Cũng như mọi hệ thống IT khác, cuối cùng có vẻ vẫn đi theo cấu trúc tổ chức.
Ồ.. vậy là một cách tiếp cận để điều chỉnh mức độ hiển thị mã phía bên kia tùy theo việc con người tự khớp interface hay công cụ sẽ làm việc đó, nhỉ
Vì tôi chưa có kinh nghiệm với mono-repo nên có một điều tôi thắc mắc. Khi dùng mono-repo, các mô-đun dùng chung cho nhiều dự án hay dịch vụ khác nhau (ví dụ: design system) sẽ được đưa vào từng mono-repo tương ứng phải không? Hay phần này buộc phải tách ra thành một repo riêng rồi tham chiếu tới?
Có vẻ như việc truy cập vào module dùng chung đã được hỗ trợ bằng
yarn workspacevà được truy cập dưới dạng symlink!Cá nhân tôi, ở công ty cũng như trong các dự án riêng, đều quản lý bằng một git duy nhất mà không tách riêng frontend, backend, batch, v.v.
Đôi khi thay vì cố giữ tương thích ngược thì sửa cả hai bên cùng lúc lại tiện hơn. Cả hai trường hợp đều là team nhỏ nên có cảm giác tách ra cũng chẳng được lợi gì mấy... Việc phải bỏ công cấu hình GitHub Actions để chỉ chạy phần có thay đổi vẫn là cái giá có thể chấp nhận được. Trên hết, hơn là phân chia backend và frontend, tôi thấy việc hai bên có thể đóng góp cho nhau sẽ tốt hơn. (Ví dụ đang làm frontend mà thấy backend cần gì thì tự thêm luôn, hoặc tự sửa lỗi, v.v.)
Ừm, có vẻ là nếu quy mô nhỏ hoặc vai trò không bị phân chia quá chặt thì mọi người sẽ ưu tiên monorepo hơn nhỉ! Việc lịch sử Git bị trộn lẫn với nhau thì mọi người cũng không quá bận tâm sao? (Dù sao thì cũng đều là code mà ai cũng xem?)
Điều thú vị là ngay cả trong dự án phụ của tôi cũng vậy. Đến nay tôi đã làm việc cùng khoảng 12 người, và mỗi người đều xử lý liền mạch từ frontend đến backend. Có lẽ điều này cũng khá giống với vertical slice.
Tôi không xem đó là bị trộn lẫn. Vì cũng có nhiều trường hợp trong một PR phải sửa cả frontend lẫn backend. Bên tôi theo định hướng cả 4 người đều là full-stack, nên không phân biệt backend/frontend, mọi người vừa review chéo cho nhau vừa cần nắm được các thay đổi.
Nếu module không quá lớn thì dùng monorepo
Nếu module lớn thì dùng submodule
Hoặc nếu khi phát hành mã nguồn mở, bạn muốn chỉ cho phép đóng góp vào submodule còn repo chính thì được quản lý riêng
thì có vẻ là nên tách bằng submodule.
Nhưng khi dùng submodule, lúc làm mã nguồn mở thì với người dùng khác, việc viết tài liệu liên quan đến test hay build để đóng góp có vẻ sẽ hơi phức tạp hơn một chút.
Vì vậy, cá nhân tôi thấy rằng nếu không phải là trường hợp cách thức đóng góp của hai bên khác nhau thì hoặc là dùng monorepo,
hoặc tách sang các GitHub khác nhau rồi quản lý theo cách phát hành từng phần dưới dạng package hoặc Docker image.
Tôi chưa nghĩ tới khía cạnh mã nguồn mở, cảm ơn bạn vì ý kiến này!