Sử dụng Git để phân phối hàng đêm được xây dựng để một studio

Question

phiên bản ngắn

Cần phân phối hàng đêm được xây dựng để 70+ người mỗi buổi sáng, muốn sử dụng git để cân bằng tải chuyển nhượng, và muốn biết nếu có những lời khuyên, cạm bẫy, hoặc sai sót với ý tưởng trước khi tôi bắt đầu thiết kế hệ thống.

Long phiên bản

Mỗi buổi sáng chúng ta cần phải phân phối xây dựng hàng đêm của chúng tôi đến studio của 70+ người (nghệ sĩ, xét nghiệm, lập trình viên, sản xuất vv). Cho đến bây giờ, chúng tôi đã sao chép bản dựng lên máy chủ và đã viết một chương trình đồng bộ hóa tìm nạp nó (sử dụng Robocopy bên dưới); thậm chí với việc thiết lập gương, tốc độ truyền tải không thể chấp nhận được với thời gian lên tới một giờ hoặc lâu hơn để đồng bộ vào thời gian cao điểm (thời gian ngoài giờ cao điểm là khoảng 15 phút), là điểm bị tắc nghẽn phần cứng I/O.

Ý tưởng tuyệt vời (mặc dù chắc chắn không phải nguyên gốc) mà tôi có là phân phối tải trong toàn bộ studio. Sau khi nghiên cứu viết một client sử dụng giao thức bit-torrent khét tiếng, một ý nghĩ khác xảy ra với tôi rằng tôi chỉ có thể sử dụng git như thiết kế nó sẽ cho chúng ta phân phối quản lý xây dựng và sửa đổi.

Câu hỏi

1. Làm thế nào để bạn bắt đầu sử dụng git? Tôi có kinh nghiệm với các hệ thống kiểm soát nguồn có vị trí trung tâm như Perforce và SVN. Đọc tài liệu, có vẻ như tất cả những gì bạn cần làm là chạy git init path\\to\folder và sau đó trên một máy khác chạy git clone url?

2. Tôi lấy số url cho lệnh git clone ở trên ở đâu? Tôi có thể xác định? Tôi tìm thấy khái niệm có một url lạ như git không có một máy chủ trung tâm - hay không? ví dụ. tương tự như một trình theo dõi bit-torrent?

3. Điều gì sẽ là tùy chọn tốt hơn để xác định bản dựng, sử dụng số hoặc danh sách thay đổi?

4. Có thể giới hạn số lượng bản chỉnh sửa được lưu trữ không? Điều này sẽ hữu ích như ngoài các bản dựng hàng đêm, chúng tôi cũng có một số CI xây dựng trong suốt cả ngày mà chúng tôi muốn phân phối, tuy nhiên không có ý nghĩa để có các bản sửa đổi số vô hạn kéo dài xung quanh. Trong Perforce bạn có thể giới hạn các bản chỉnh sửa bằng cách đặt thuộc tính.

Answer 1

Tôi không nghĩ rằng git sẽ thực sự hữu ích trong trường hợp của bạn. Có, nó được phân phối, nhưng không phải trong trường hợp "phân phối một cái gì đó cho nhiều người càng tốt". Nó không giúp bạn giảm tải băng thông, cũng sẽ có một tải bổ sung nếu bạn sẽ sử dụng git trên ssh. Có thể bạn nên lùi bước và tạo cơ hội khác cho giao thức bittorrent.

Answer 2

1. bạn có thể sử dụng giao thức tập tin ("local protocol") nếu tất cả các khách hàng của bạn có quyền truy cập chia sẻ máy chủ của bạn.
2. nếu bạn có thể thực hiện một thư mục hoặc ls từ khách hàng của bạn ... bạn có url bạn cần.
3. thẻ: một khi bạn sao chép một repo, bạn có thể kiểm tra nó vào một thẻ nhất định.
4. không thực sự, bạn sẽ tìm nạp mỗi sáng các cam kết mới để có được toàn bộ lịch sử.

Lưu ý: việc đặt các tệp nhị phân vào repo được phân phối không phải là giải pháp will scale well in time, repo ngày càng lớn. (bạn có alternative git setups here).
Lợi thế là tính toán đồng bằng bằng repo Git trung tâm (sẽ phải nhanh hơn một robocopy) và gửi delta như một câu trả lời cho một git fetch được thực hiện bởi một repo ở hạ nguồn.

Answer 3

1. Vâng, đó là bản chất của nó. Tạo một kho lưu trữ ở đâu đó và sau đó bạn có thể sao chép nó từ một nơi khác.

2. Kho lưu trữ bạn bắt đầu bằng 1) phải có thể truy cập được từ máy mà bạn đang nhân bản. Git là máy chủ ít hơn nhưng mỗi kho lưu trữ phải có được công cụ của họ từ một nơi nào đó. Vì vậy, tất cả 70 máy của bạn sẽ phải biết nơi họ sẽ nhận được bản dựng mới. Và nếu bạn muốn phân phối tải, bạn sẽ phải tìm ra một stategy về những người nhận được cập nhật của họ từ ai.

   URL có thể là một filepath, một networkpath, một máy chủ SSH với con đường vv

3. Thẻ sẽ làm việc tốt.

4. Có thể bạn có thể rebase git repo để xóa các bản sửa đổi cũ. Xem Completely remove (old) git commits from history

Tuy nhiên, tôi không nghĩ nó sẽ giải quyết được vấn đề ban đầu của bạn, phân phối tải. Các con đường khác nên được điều tra. Ví dụ sao chép đa hướng, có lẽ MQcast and MQcatch có thể giúp bạn?