Do DVCSes không khuyến khích tích hợp liên tục?

Nói rằng có một nhóm mười nhà phát triển nhanh nhẹn. Mỗi ngày, mỗi người chọn một nhiệm vụ từ hội đồng quản trị, thực hiện một số thay đổi so với nhiệm vụ đó, cho đến khi (đến cuối ngày) họ đã hoàn thành nhiệm vụ. Tất cả các nhà phát triển đăng ký trực tiếp với trung kế (kiểu Google, mỗi cam kết là một ứng cử viên phát hành, sử dụng tính năng bật tắt, v.v.).

Nếu họ đang sử dụng CVS tập trung như SVN, mỗi khi một trong số họ cam kết, máy chủ xây dựng sẽ tích hợp và kiểm tra các thay đổi của họ đối với công việc của chín nhà phát triển khác. Máy chủ xây dựng sẽ hoạt động khá nhiều liên tục cả ngày.

Nhưng nếu họ đang sử dụng một DCVS như git, nhà phát triển có thể đợi cho đến khi họ hoàn thành nhiệm vụ trước khi đẩy tất cả các cam kết cục bộ của họ lên tới kho lưu trữ trung tâm. Những thay đổi của họ sẽ không được tích hợp cho đến cuối ngày.

Trong kịch bản này, nhóm SVN liên tục - tích hợp thường xuyên hơn và phát hiện ra các vấn đề tích hợp nhanh hơn nhiều so với nhóm git.

Điều này có nghĩa là DVCS không phù hợp với các nhóm liên tục hơn các công cụ tập trung cũ hơn? Làm thế nào để các bạn có được xung quanh vấn đề đẩy lùi này?

Tuyên bố miễn trừ trách nhiệm: Tôi làm việc cho Atlassian

DVCS không khuyến khích Tích hợp liên tục miễn là nhà phát triển đẩy từ xa một cách thường xuyên đến chi nhánh của chính họ và máy chủ CI được thiết lập để xây dựng các nhánh hoạt động đã biết.

Theo truyền thống, có hai vấn đề với DVCS và CI:

• Sự không chắc chắn của trạng thái tích hợp - trừ khi nhà phát triển thường xuyên hợp nhất từ ​​chủ và chạy bản dựng, bạn không biết trạng thái của các thay đổi kết hợp là gì. Nếu nhà phát triển phải thực hiện việc này một cách thủ công, nhiều khả năng nó sẽ không được thực hiện đủ thường xuyên để nhận vấn đề đủ sớm.
• Sao chép và trôi cấu hình bản dựng - nếu cấu hình bản dựng phải được sao chép từ bản dựng 'chính' để tạo bản dựng nhánh, cấu hình cho nhánh có thể nhanh chóng không đồng bộ với bản dựng được sao chép từ đó.

Trong Bamboo, chúng tôi đã giới thiệu khả năng cho máy chủ xây dựng phát hiện các nhánh mới do chúng được tạo bởi các nhà phát triển và tự động thiết lập các bản dựng cho nhánh dựa trên cấu hình xây dựng cho chủ (vì vậy nếu bạn thay đổi cấu hình thạc sĩ, nó cũng thay đổi cấu hình nhánh để phản ánh sự thay đổi).

Chúng tôi cũng có một tính năng gọi là Chiến lược hợp nhất có thể được sử dụng để cập nhật chi nhánh với các thay đổi từ chủ trước khi xây dựng chi nhánh chạy hoặc tự động đẩy các thay đổi trong nhánh xây dựng thành công thành chủ, đảm bảo các thay đổi giữa các chi nhánh được kiểm tra cùng nhau càng sớm càng tốt .

Dù sao đi nữa, nếu bạn quan tâm đến việc tìm hiểu thêm, hãy xem bài đăng trên blog của tôi "Tạo các nhánh tính năng hiệu quả với tích hợp liên tục"

Nhóm nhỏ của tôi đã chuyển sang DVCS một hoặc hai năm trước và phần còn lại của công ty tôi đã làm theo một vài tháng trước. Theo kinh nghiệm của tôi:

• Những người sử dụng một VCS tập trung vẫn có xu hướng giữ các cam kết khi họ đang thực hiện một dự án lớn. Đây không phải là vấn đề duy nhất đối với DVCS. Họ sẽ có các bộ thay đổi phải chờ vài ngày trước khi thực hiện cam kết. Sự khác biệt lớn là nếu họ mắc lỗi tại một thời điểm nào đó trong thời gian này hoặc nếu máy tính gặp sự cố, nó đòi hỏi nhiều nỗ lực hơn để khắc phục nó.
• Chúng tôi sử dụng một quy trình công việc cam kết trong đó mỗi nhà phát triển làm việc trên nhánh có tên riêng của họ và chỉ người đã xem lại mã của họ mới được phép hợp nhất các thay đổi của họ vào đầu. Điều này làm giảm khả năng cam kết gây ra sự cố, vì vậy mọi người thực sự chú ý khi máy chủ xây dựng tạo ra thông báo lỗi. Điều đó cũng có nghĩa là các nhà phát triển khác có thể tiếp tục làm việc trên các nhánh của riêng họ cho đến khi phần đầu được sửa.
• Trên DVCS, mọi người thường có xu hướng dành nhiều thời gian hơn để lập trình trước khi hợp nhất mã của họ với người đứng đầu. Vì vậy, nó có xu hướng giới thiệu một chút độ trễ vào tính liên tục của bản dựng. Nhưng sự khác biệt không đủ quan trọng để chống lại những lợi thế của DVCS.

Gần đây tôi đã quan sát khoảng 19 dự án sử dụng Mercurial trên SubVersion (tôi là một người đam mê lật đổ ): các nhà phát triển bắt đầu trở thành những người theo chủ nghĩa cá nhân thực sự bằng cách làm việc trên chi nhánh của riêng họ và chỉ tích hợp sau vài ngày hoặc vài tuần. Điều này gây ra những rắc rối và mối quan tâm tích hợp nghiêm trọng.

Một vấn đề khác chúng tôi gặp phải là với máy chủ tích hợp liên tục. Chúng tôi đã được thông báo về các sự cố (ví dụ như không kiểm tra), chỉ khi đồng bộ hóa các cam kết được thực hiện với máy chủ.

Có vẻ như Martin Fowler đã viết về nó trên trang web của mình.

Điều đó nói rằng, một số dự án tôi đề cập đã thực hiện đồng bộ hóa ít nhất một lần một ngày để giảm các vấn đề. Vì vậy, để trả lời câu hỏi của bạn, tôi nghĩ rằng DVCS có thể không khuyến khích hội nhập liên tục và tăng chủ nghĩa cá nhân. Tuy nhiên, DVCS không phải là nguyên nhân trực tiếp.

Nhà phát triển vẫn chịu trách nhiệm bất kể VCS họ sử dụng.

Ý tưởng bạn dựa trên lý luận của bạn là rất run rẩy, nói nhẹ nhàng. Đó là vấn đề của nhóm / quản lý / quy trình mà nhà phát triển có thể đợi cho đến khi họ hoàn thành nhiệm vụ .

Thực hiện bằng cách này hay cách khác, "chờ đợi" hoặc "vội vàng", chia sẻ thân cây hoặc nhánh bị cô lập, được gọi là chiến lược phân nhánh và nếu bạn nghiên cứu thông tin có sẵn trực tuyến , bạn sẽ thấy rằng việc chọn chiến lược cụ thể về cơ bản không liên quan gì VCS đang được tập trung hoặc phân phối.

Giả sử, đối với các VCS phân tán như Mercurial, bạn có thể dễ dàng tìm thấy đề xuất mạnh mẽ cho việc hợp nhất thường xuyên :

Đầu tiên, hợp nhất thường xuyên! Điều này làm cho việc hợp nhất dễ dàng hơn cho mọi người và bạn tìm hiểu về xung đột (thường bắt nguồn từ các quyết định thiết kế không tương thích) trước đó ...

Nghiên cứu các khuyến nghị như trên, người ta có thể dễ dàng phát hiện ra rằng những lời kêu gọi này đối với những cân nhắc không liên quan gì đến việc Mercurial được phân phối.

Bây giờ, hãy xem xét tình hình bên cạnh VSC tập trung, Subversion. Nghiên cứu thông tin trực tuyến, người ta có thể tìm thấy trong số các chiến lược phổ biến hàng đầu được gọi là thân cây ổn định và thân cây không ổn định - mỗi chiến lược có tác động ngược lại đến tần suất sáp nhập. Bạn thấy đấy, mọi người chọn một hoặc một cách làm việc khác mà không chú ý đến việc VCS được tập trung hóa.

• ^{Tôi đã thấy sự hợp nhất bị trì hoãn nghiêm trọng xảy ra (thậm chí được khuyến khích bởi quản lý khập khiễng) với VCS tập trung, cũng như việc sáp nhập thường xuyên được thực hiện với DVCS khi nhóm / quản lý chỉ nghĩ rằng đó là cách đúng đắn. Tôi đã thấy rằng không ai quan tâm nếu VCS được phân phối hoặc tập trung khi quyết định cách này hay cách khác.}

Đưa ra ở trên, có vẻ như câu trả lời đúng cho Do DVCSes không khuyến khích tích hợp liên tục? sẽ là Mu .

VCS được phân phối hay không không có tác động đáng kể đến điều đó.

Kinh nghiệm của tôi hoàn toàn ngược lại , các nhóm sử dụng svn sẽ không thúc đẩy trong nhiều ngày, bởi vì mã họ đang làm việc sẽ khiến cho thân cây không biên dịch cho mọi người khác mà không lãng phí thời gian cho việc hợp nhất thủ công. Sau đó, gần cuối cuộc đua nước rút, mọi người sẽ cam kết, sự hợp nhất điên rồ sẽ diễn ra, mọi thứ sẽ được viết quá mức và bị mất và phải được phục hồi. Hệ thống CI sẽ chuyển sang màu đỏ và ngón tay trỏ sẽ xảy ra.

Không bao giờ có vấn đề này với Git / Gitorious.

Git cho phép bạn kéo và hợp nhất các thay đổi của người khác một cách thuận tiện, không phải vì người khác đã kiểm tra một cái gì đó và bạn muốn đăng nhập nhưng bạn có 20 phút để hợp nhất thủ công để thực hiện.

Git cũng cho phép bạn lấy các cam kết của người khác, hợp nhất mã của bạn và sau đó đẩy phiên bản hoạt động cho mọi người khác để họ không phải đoán xem họ nên hợp nhất dựa trên những gì bạn đã thay đổi.

Có một cái gì đó như Gitorious như một trung gian để đánh giá mã thông qua các yêu cầu hợp nhất làm cho việc quản lý nhiều chi nhánh và nhiều người đóng góp rất khó khăn.

Thiết lập Jenkins / Hudson để theo dõi tất cả các nhánh hoạt động trong kho Git cũng rất dễ dàng. Chúng tôi đã có thêm lực kéo với CI và phản hồi thường xuyên hơn về trạng thái của các kho lưu trữ khi chúng tôi chuyển đến Git từ SVN.

Xây dựng máy chủ có giá rẻ. Chỉ cần có máy chủ CI của bạn nhận tất cả các chi nhánh bạn biết.

Jenkins có hỗ trợ để kiểm tra nhiều kho lưu trữ git và nhận được 'bản mới nhất' từ bất kỳ ai trong một công việc. Tôi chắc chắn có những giải pháp tương tự với các công cụ khác.

Câu hỏi cũ này chỉ được đánh dấu là một bản sao của một câu hỏi mới, và vì rất nhiều câu trả lời tham khảo một số ý tưởng lỗi thời, tôi nghĩ rằng tôi đã đăng một bản cập nhật.

Một điều dường như không phổ biến năm năm trước là chạy thử nghiệm CI trên các nhánh yêu cầu kéo trước khi hợp nhất chúng thành chủ. Tôi nghĩ rằng điều này phản ánh một thái độ thay đổi mà mặc dù việc hợp nhất thường xuyên là mong muốn, chia sẻ mọi thay đổi với mọi người , ngay khi bạn thực hiện nó , không phải là tối ưu.

DVCS đã tạo ra một chế độ phân cấp hơn để tích hợp các cam kết của bạn. Ví dụ, tôi thường làm việc với các nhiệm vụ rất chặt chẽ với nhà phát triển ngồi cạnh tôi. Chúng tôi sẽ kéo từ các chi nhánh của nhau vài lần mỗi ngày. Hôm nay, chúng tôi đã hợp tác với một nhà phát triển khác thông qua các thay đổi được đẩy sang yêu cầu kéo cứ sau vài giờ.

Chúng tôi đã thực hiện các thay đổi lớn cho các tập lệnh xây dựng. Jenkins hợp nhất cục bộ mọi chi nhánh PR với chủ và chạy thử nghiệm, vì vậy chúng tôi đã nhận được phản hồi tự động theo cách đó, mà không làm phiền bất kỳ nhà phát triển nào khác cần một bản dựng sạch. Có lẽ sẽ còn một ngày nữa trước khi PR sẵn sàng hợp nhất để làm chủ và chia sẻ bên ngoài nhóm ba nhà phát triển của chúng tôi.

Tuy nhiên, nếu ai đó không thể chờ đợi các thay đổi của chúng tôi hợp nhất thành chủ, vì thay đổi của họ phụ thuộc vào chúng tôi, họ có thể hợp nhất chi nhánh dev của chúng tôi tại địa phương và tiếp tục công việc của họ. Đây là điều mà rất nhiều người đã quen với CVCS bỏ lỡ. Với CVCS, cách duy nhất để chia sẻ các thay đổi của bạn là hợp nhất chúng vào repo trung tâm và đó là lý do tại sao việc hợp nhất thường trở nên quan trọng hơn. Với DVCS, bạn có các tùy chọn khác.

Tôi muốn nói DVCS có lợi cho việc tích hợp liên tục. Sáp nhập không gây khó chịu với chúng. Nó đòi hỏi kỷ luật nhiều hơn tuy nhiên. Bạn nên thực hiện theo một cam kết cục bộ với một lần kéo từ cơ sở để hợp nhất và sau đó đẩy khi nhiệm vụ của bạn hoàn thành (trước khi chuyển sang kế tiếp).

Khi nhóm của tôi chuyển sang Git, chúng tôi đã trình bày rõ ràng quy trình của mình sao cho một cú đẩy phải được đối xử chính xác như một cam kết trong VCS cũ hơn và các cam kết cục bộ có thể được thực hiện thường xuyên / không thường xuyên như mỗi cá nhân đã chọn. Với điều đó, không có sự khác biệt đối với hệ thống CI cho dù chúng tôi đang sử dụng DVCS hay VCS tập trung.

Câu trả lời là cả có và không.

Sự khác biệt ở đây là giữa việc cam kết trực tiếp với repo trung tâm do CI xem và đẩy các thay đổi của bạn sang repo được xem CI trung tâm. "Vấn đề" bạn có thể thấy là người dùng DVCS có thể không thực sự thực hiện việc đẩy đó thường xuyên.

Tôi muốn nói rằng đây là một tính năng thiết kế vốn có của DVCS, nó không được thiết kế để đẩy các thay đổi của bạn đến máy chủ trung tâm mọi lúc - nếu có, bạn cũng có thể sử dụng CVCS thay thế. Vì vậy, câu trả lời là thực thi một quy trình làm việc tốt hơn giữa các nhà phát triển của bạn. Nói với họ để đẩy thay đổi mỗi đêm. Đơn giản!

(và nếu người dùng SVN của bạn không cam kết mỗi đêm, hãy nói với họ - đó chính là vấn đề tương tự).

Git không ngăn cản sự tích hợp liên tục. Quy trình làm việc dựa trên thân cây của bạn là.

Điều đó nghe có vẻ trái ngược, nhưng: nếu các nhà phát triển làm việc trên các nhánh tính năng, họ có thể được khuyến khích tích hợp thường xuyên trên các máy của chính họ (và bắt buộc phải làm như vậy trước khi gửi tính năng của họ để hợp nhất). Ngược lại, một quy trình làm việc dựa trên thân cây ủng hộ các cam kết lớn hơn và do đó ít tích hợp thường xuyên hơn.

Tôi duy trì rằng quy trình làm việc dựa trên thân cây theo kiểu Google là phản tác dụng với một VCS như Git, nơi việc hợp nhất rất dễ dàng. Đây là những gì tôi khuyên thay:

• Phá vỡ các tính năng đủ nhỏ để không ai mất hơn một hoặc hai ngày để phát triển.
• Mỗi tính năng được phát triển trên một chi nhánh tư nhân.
• Nhà phát triển tích hợp thường xuyên trên nhánh riêng ( git fetch origin; git merge master). Tôi thường làm điều này nhiều lần một ngày khi làm việc theo cách này.
• Khi nhà phát triển gửi chi nhánh để hợp nhất và đánh giá, máy chủ CI sẽ tự động xây dựng. Hợp nhất chỉ xảy ra khi điều này đi qua.

Vì vậy, bạn có nó: các cam kết nhỏ, tích hợp thường xuyên và lịch sử theo dõi các cam kết thuộc về tính năng nào. Các nhánh, được sử dụng đúng cách, là chìa khóa cho tất cả những gì đáng giá về Git, vì vậy tránh chúng là một sai lầm lớn.

Có những giải pháp kỹ thuật tuyệt vời như @jdunay đã đề cập, nhưng đối với chúng tôi, đó là vấn đề của mọi người - giống như cách thúc đẩy môi trường nơi mọi người cam kết với svn thường là vấn đề của mọi người.

Điều làm việc cho chúng tôi là: (thay thế 'chủ nhân' bằng nhánh dev hiện đang hoạt động)

1. Thường xuyên sáp nhập / nổi loạn từ chủ
2. Đẩy đủ thường xuyên để làm chủ

3. Nhận thức về những thứ gây ra địa ngục hợp nhất, chẳng hạn như tái cấu trúc nhất định, và giảm thiểu điều này bằng cách giao tiếp. Ví dụ:

   • Hãy chắc chắn rằng tất cả mọi người đẩy trước khi ăn trưa
   • Thực hiện và đẩy tái cấu trúc trong bữa trưa
   • Hãy chắc chắn rằng tất cả mọi người kéo sau bữa ăn trưa