Từ kích thước nhất định của codebase, bạn vẫn sẽ có Git hoặc có giải pháp chuyên biệt hơn không?
(Ngoài ra để kiểm tra chỉ là một phần của cơ sở mã)
Từ kích thước nhất định của codebase, bạn vẫn sẽ có Git hoặc có giải pháp chuyên biệt hơn không?
(Ngoài ra để kiểm tra chỉ là một phần của cơ sở mã)
Câu trả lời:
Git hoạt động cho mục đích đơn lẻ, nhưng nó có một vài vấn đề:
Google, có lẽ là người dùng monorepo nổi tiếng nhất, đã phát triển Piper để đáp ứng nhu cầu của họ. Nhưng bạn không phải là Google và vì vậy các giải pháp của họ có thể không phải là của bạn.
Một trong những lợi thế chính của monorepo là bạn có thể thực hiện các thay đổi nguyên tử toàn cầu (nghĩa là bạn không cần phải phiên bản nhiều thứ vì bạn có thể thay đổi người gọi và callee trong cùng một cam kết). Để tăng sức mạnh này, bạn thực sự muốn có một hệ thống xây dựng thống nhất theo dõi các phụ thuộc trên toàn bộ repo. Bazel là một trích xuất mã nguồn mở của hệ thống xây dựng của Google, Blaze và nó cố gắng làm điều đó (mặc dù nó còn non trẻ và chưa trưởng thành và thiếu rất nhiều tính năng cần thiết cho việc sử dụng không phải của Google). Quần là một hệ thống tương tự ra khỏi Twitter.
Nếu bạn đang xây dựng hàng tấn mã khi bạn thực hiện một thay đổi nguyên tử như vậy, thì có lẽ bạn cũng muốn có một trang trại xây dựng cho phép bạn làm điều đó không phải trên máy cục bộ của bạn. Tương tự, bạn sẽ cần một hệ thống CI mạnh mẽ để xử lý các bài kiểm tra chạy trên mọi thứ khi bạn cập nhật.
Câu trả lời là: một chút của cả hai. Để đáp ứng các ràng buộc của "sử dụng git" và "quản lý một cơ sở mã lớn", Microsoft đã phát triển một hệ thống tệp mới (trước đây họ đang sử dụng một biến thể của Perforce gọi là SourceDepot). Đó là nguồn mở nhưng tôi không có kinh nghiệm cá nhân về việc sử dụng nó.
Tại sao bạn muốn có một monorepo? Lý do rõ ràng nhất là bạn có thể sửa đổi API và tất cả những người gọi API đó trong một cam kết nguyên tử. Ngoài ra, có những lợi thế để có thể thực hiện git logtìm kiếm trên toàn bộ cơ sở mã ...
Ý kiến khác nhau về cơ sở mã lớn là gì. Nếu bạn đang nói về một công ty có 100 kỹ sư, tôi sẽ lập luận rằng Git vẫn có thể xử lý nó. Nó đã được phát triển cho nhu cầu của nhân Linux, đây không phải là một dự án nhỏ.
Không phụ thuộc vào cách bạn lưu trữ kho lưu trữ, bạn có thể gặp vấn đề. Chẳng hạn, nếu bạn đang làm việc trên một cơ sở mã Java lớn và đang sử dụng các công cụ như Eclipse hoặc IntelliJ, chúng sẽ sử dụng nhiều bộ nhớ hơn và thường trở nên chậm hơn.
Mặt khác, có tùy chọn hoạt động trên tất cả các mã cùng một lúc (ví dụ: khi áp dụng tái cấu trúc hoặc chuyển đổi mã nguồn) là một trong những lợi thế chính của kho lưu trữ nguyên khối.
Khi bạn hỏi về việc bạn có cần các công cụ chuyên dụng hay không, sau đó tăng kích thước mã nhất định, câu trả lời là có. Theo Google, nơi được cho là có cơ sở mã C ++ lớn nhất thế giới, tất cả các công cụ có sẵn (nguồn mở hoặc thương mại) đều không đáp ứng yêu cầu của họ. Cuối cùng họ đã phát triển một hệ thống đường phố gọi là Piper:
Nếu tôi hiểu chính xác thì "nhu cầu" cho một đơn vị đơn giản chỉ là nhu cầu cơ bản của sơ đồ phiên bản đơn / kết hợp được áp dụng cho một dự án phần mềm có chứa nhiều thành phần / dự án phụ liên quan lỏng lẻo mà / có thể được quản lý / phiên bản độc lập trong kho riêng biệt.
Tương tự, nếu bạn muốn, với nhu cầu sử dụng kho lưu trữ nguồn thông thường để cung cấp sơ đồ phiên bản đơn / kết hợp cho vô số tệp nguồn, mỗi tệp có lịch sử sửa đổi độc lập của riêng chúng.
Sử dụng một giải pháp monorepo thực tế chắc chắn là một, nhưng IMHO không phải là cách duy nhất để giải quyết nhu cầu này.
Một cách tiếp cận khả thi khác là sử dụng kho lưu trữ dự án ô chứa một hoặc nhiều tệp kê khai với phiên bản chính xác của từng kho lưu trữ thành phần dự án riêng lẻ.
Ngay cả khi các kho thành phần có các phiên bản của chúng được sửa đổi bởi các cam kết độc lập, không nguyên tử, bản thân dự án có thể được quản lý đơn giản bằng cách kết hợp tất cả các thay đổi phiên bản kho thành phần liên quan thành một cam kết duy nhất với (các) tệp kê khai trong kho lưu trữ ô.
Cách tiếp cận như vậy có một số lợi thế so với việc chuyển sang một giải pháp monorepo thực tế: