Chiến lược sử dụng kiểm soát phiên bản trên một hệ thống mô-đun

Giả sử (để đơn giản) rằng chúng tôi có một ứng dụng có máy khách và máy chủ; Có một ý tưởng tốt hơn để sử dụng một kho lưu trữ cho cả hai hoặc một cặp kho riêng biệt?

Trộn chúng có thể sẽ giúp dễ dàng theo dõi các thay đổi tương quan và duy trì các nhánh tương quan (nghĩa là tiến hóa giao thức), nhưng mặt khác sẽ làm cho sự phát triển cá nhân trở nên lộn xộn hơn ...

Nếu bạn đang sử dụng git hoặc mercurial , thì bạn có thể muốn xem xét các mô hình con hoặc phần phụ .

Máy khách, máy chủ và các tệp giao diện của chúng sẽ nằm trong kho riêng của chúng, nhưng sẽ được gắn với nhau ở cấp siêu kho lưu trữ . Điều này sẽ cho phép bạn thực hiện một kiểm tra ở cấp cao nhất và githoặc hgsẽ kiểm tra cam kết phù hợp của từng mô hình con / tiểu dự án.

Bằng cách chỉ cam kết với siêu kho lưu trữ khi cả máy khách và máy chủ phù hợp với nhau, siêu kho sẽ chỉ cung cấp cho bạn tùy chọn để kiểm tra một hệ thống đang hoạt động - vì vậy bạn sẽ không bao giờ thử chạy máy khách mới chống lại máy khách cũ máy chủ hoặc ngược lại.

Submodules / subreposearies cung cấp cho bạn tất cả các lợi thế của việc sử dụng các kho lưu trữ riêng biệt, cùng với các lợi thế của một kho lưu trữ nguyên khối duy nhất, với chi phí hơi phức tạp thêm một chút.

_{Câu trả lời này không nhằm mục đích ủng hộ githay hghơn các SCM khác, chỉ là tôi chỉ biết những SCM này đủ để biết rằng tùy chọn này tồn tại. Tôi không hiểu làm thế nào svnbên ngoài làm việc ví dụ.}

Tách rời!

Trên thực tế, tôi có thể có ba kho lưu trữ, một cho Thư viện khách và thư viện chỉ dành cho khách, một cho Thư viện (và thư viện tương ứng) và một cho thư viện dùng chung (kết hợp các giao diện API hiển thị chức năng giữa hai thư viện , cộng với bất kỳ mã chia sẻ nào khác). Tôi nghĩ đó thực sự là chìa khóa, mã được chia sẻ nên đi vào một kho lưu trữ riêng. Bằng cách đó, bạn có thể đảm bảo rằng khả năng tương tác giữa máy khách và máy chủ của bạn luôn ở cùng một phiên bản VÀ được tách biệt khỏi thiết kế của mỗi người tiêu dùng.

Rõ ràng, điều này không phải lúc nào cũng có thể, tùy thuộc vào khung giao tiếp cụ thể mà bạn đang sử dụng, nhưng có khả năng là mã được chia sẻ định dạng định dạng của các đối tượng truyền dữ liệu hoặc các bước bắt tay trong giao thức tùy chỉnh của bạn (hoặc một số ví dụ khác) .

Giả sử bạn có một thiết lập QA và Tích hợp liên tục khá tốt (một giả định khá lớn, theo kinh nghiệm của tôi, nhưng dù sao tôi cũng sẽ thực hiện. Nếu bạn không có bộ phận QA, ít nhất bạn nên có một số CI) Không cần sử dụng mẫu repo đơn để bảo vệ chống lại các mã trùng khớp có thể xảy ra, máy chủ CI của bạn sẽ gắn cờ khả năng tương tác thư viện hoặc nhóm QA của bạn sẽ bắt lỗi trong thời gian chạy (hoặc thậm chí tốt hơn, Kiểm tra đơn vị của bạn sẽ).

Lợi ích của kho lưu trữ phân chia nằm ở khả năng phiên bản riêng biệt các phần riêng biệt của một hệ thống. Bạn muốn lấy một bản sao của Máy chủ tuần trước và chạy nó với Máy khách của tuần này, để thử và khóa gốc của vấn đề về hiệu suất? Đừng lo lắng.

Trong Mercurial , lược đồ này có thể được sử dụng, sử dụng ->để biểu thị mối quan hệ subrepo:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

Sản phẩm có máy khách, máy chủ. Mỗi trong số chúng có các thành phần của chúng là phần phụ, có thể ít nhất một phần con được chia sẻ giữa hai phần.

Gắn thẻ có lẽ nên được thực hiện ở hai cấp độ đầu tiên, không dưới mức đó.

Các cam kết được thực hiện ở cấp độ thành phần, siêu năng lực theo dõi hiệu quả các nhánh và phiên bản của sản phẩm được đặt tên. Các nhánh / dấu trang được đặt tên thường tốt hơn các nhánh nhân bản về khả năng sử dụng (nghĩa là khả năng huấn luyện) và khả năng tương thích với subrepose.

hg có xu hướng hướng tới giả định rằng siêu bội là sản phẩm và các cam kết được thực hiện ở cấp cao nhất, nhưng điều đó không hoạt động đặc biệt tốt khi nhiều sản phẩm sử dụng cùng một thành phần. :-)

Tôi không nghĩ rằng lược đồ này sẽ thay đổi nhiều nếu được chuyển sang git, nhưng tôi chưa thử nó trong git.

Đây là một vấn đề quản lý cấu hình, không phải là vấn đề kiểm soát sửa đổi. Như mọi khi, một lập trình viên sử dụng tuốc nơ vít để đóng đinh. Tìm ra cách bạn sẽ quản lý các cấu hình của mình, điều khiển sửa đổi sẽ tự xử lý.

Các đơn giản nhất cách tiếp cận là sử dụng một kho lưu trữ duy nhất, vì vậy trừ khi bạn thích sự phức tạp vì sự phức tạp, sau đó mà nên là sự lựa chọn mặc định trong sự vắng mặt của đối số hấp dẫn khác.

Là sự phát triển của máy khách và máy chủ sẽ được thực hiện bởi các tổ chức khác nhau? Sẽ có nhiều triển khai của máy khách (hoặc máy chủ)? Là máy khách nguồn mở và bí mật thực hiện máy chủ? Nếu câu trả lời cho tất cả những câu hỏi này là "Không", thì bất cứ điều gì phức tạp hơn một kho lưu trữ duy nhất có khả năng chỉ mang lại sự bất tiện mà không có lợi ích.

Nếu bạn chọn duy trì các cơ sở mã riêng biệt, bạn sẽ cần các chính sách rõ ràng về cách thức quản lý này, để tránh sự không tương thích và địa ngục phụ thuộc. Sau khi thực hiện một vài trục trặc đầu tiên, cuối cùng bạn có thể phát hiện ra rằng điều an toàn nhất là luôn luôn kiểm tra cả hai kho lưu trữ, xây dựng chúng cùng nhau và triển khai chúng cùng nhau ... điều này rõ ràng đánh bại toàn bộ mục đích tách chúng ra!

Modularity là một tài sản tốt để có, nhưng chia kho không phải là một công cụ để đạt được điều đó. Như đoạn trước ngụ ý, bạn có thể có các thành phần được ghép nối cao được phân chia trên nhiều cơ sở mã (không mong muốn) và tương tự, bạn có thể có các thành phần mô đun cao trong cùng một cơ sở mã (mong muốn).

Trong nhiều lần, tôi đã ủng hộ (thành công) cho nhóm của mình để hợp nhất các kho git hiện có, bởi vì nó đơn giản hóa việc phát triển và triển khai.

Hãy quên kho lưu trữ một lát. Bạn sẽ tổ chức hai dự án trên máy như thế nào nếu bạn không chia sẻ với ai? Làm thế nào phần còn lại của đội sẽ làm điều đó? Bạn sẽ ...

• Đặt tất cả các tệp nguồn cho cả máy khách và máy chủ trong cùng một thư mục?

• Tạo một thư mục dự án chính có chứa thư mục con cho máy khách và máy chủ?

• Giữ hai dự án hoàn toàn tách biệt?

Khi bạn đạt được sự đồng thuận về điều đó với tư cách là một nhóm, bạn đã sẵn sàng kiểm tra các dự án vào kho lưu trữ mã của mình. Tất cả các công cụ kiểm soát sửa đổi mà tôi có thể nghĩ ra đều vui lòng sao chép bất kỳ cấu trúc thư mục nào bạn thích - họ không quan tâm một chút về tệp nào thuộc về dự án nào. Và sự khác biệt giữa việc có một hoặc hai (hoặc sáu) kho lưu trữ thường không lớn, ngoài những khác biệt nhỏ về quản trị.

Ví dụ, với Subversion, sự khác biệt lớn nhất giữa các kho riêng biệt cho máy khách và máy chủ và một kho lưu trữ kết hợp duy nhất là cách các số sửa đổi thay đổi. Với kho lưu trữ singe, số phiên bản sẽ tăng lên mỗi khi bạn cam kết mã cho máy khách hoặc máy chủ. Với các kho lưu trữ riêng biệt, một cam kết đối với dự án máy chủ sẽ không thay đổi số sửa đổi chính cho máy khách.