Làm thế nào để bạn xử lý tích hợp mã từ nhiều chi nhánh / nhà phát triển mỗi lần chạy nước rút?

Vừa nhận được một cuộc gọi retro, nơi các nhà phát triển bày tỏ mối quan tâm xung quanh việc tích hợp các câu chuyện của họ vào nhánh chính mỗi lần chạy nước rút. Các nhà phát triển tất cả mã trong nhánh riêng của họ và đến cuối giai đoạn nước rút, tất cả họ hợp nhất thành một nhánh chính.

Sau đó, một nhà phát triển (thường là cùng một nhà phát triển) có nhiệm vụ đảm bảo mọi thứ được tích hợp tốt với mã của nhà phát triển khác (Hầu hết các thay đổi nằm trên cùng một trang. Ví dụ: câu chuyện hiển thị dữ liệu, câu chuyện lọc dữ liệu và một chỉ số SLA).

Làm thế nào chúng ta có thể giảm gánh nặng này và giúp mã của chúng ta dễ dàng hợp nhất với nhau hơn? Từ quan điểm của tôi, việc PO hoặc SM ưu tiên các câu chuyện theo cách hiệu quả hơn để chúng ta không có những loại phụ thuộc này trong cùng một lần chạy nước rút có thể giải quyết một số vấn đề. Làm thế nào để mọi người khác giải quyết điều này? Hay đây chỉ là một phần của quá trình?

Nếu bạn đang sử dụng Git, mỗi nhà phát triển sẽ kéo từ developchi nhánh vào nhánh tính năng của riêng họ để họ đảm bảo họ không đi quá xa đường cơ sở hiện tại. Họ có thể làm điều đó hàng ngày, để các nhiệm vụ mất hơn một vài ngày được đồng bộ hóa và các vấn đề hợp nhất được giải quyết trong khi chúng vẫn còn nhỏ.

Khi nhà phát triển hoàn thành công việc của họ, họ tạo một yêu cầu kéo . Khi được phê duyệt, điều đó sẽ được sáp nhập vào developchi nhánh.

Các developchi nhánh phải luôn luôn có mã làm việc, và sẵn sàng cho phát hành bất cứ lúc nào. Khi bạn thực sự phát hành, bạn hợp nhất developvào mastervà gắn thẻ nó.

Nếu bạn có Máy chủ tích hợp liên tục tốt, thì nó sẽ xây dựng từng nhánh khi các thay đổi được kiểm tra - đặc biệt đối với các yêu cầu kéo. Một số máy chủ xây dựng tích hợp với máy chủ Git của bạn để tự động phê duyệt hoặc từ chối yêu cầu kéo nếu quá trình xây dựng thất bại hoặc các thử nghiệm tự động không thành công. Đây là một cách khác để tìm lỗi tích hợp tiềm năng.

Tôi đã làm việc trong một nhóm mà chúng tôi phải vật lộn với cùng một vấn đề. Chúng tôi thấy rằng càng ít thời gian trước khi tích hợp, nó càng trở nên khó khăn hơn. Tôi biết hầu hết mọi người dạy tích hợp liên tục nói về việc cam kết cứ sau vài phút - chúng tôi có thể thực sự cam kết mỗi giờ hoặc lâu hơn.

Chúng tôi cũng thấy rằng chỉ cần xây dựng là không đủ. Chúng tôi cần một mức độ bao phủ thử nghiệm tốt để đảm bảo rằng chúng tôi không vô tình phá vỡ mã của nhau.

• Giữ cho các chi nhánh của bạn tồn tại trong thời gian ngắn (có vẻ như bạn đã làm điều này).
• Hãy để kết quả kiểm tra của bạn nói cho chính họ.
• Đừng chờ kết thúc nước rút.

Bạn thậm chí không cần phải đăng ký TDD cho cái này. Tất cả những gì bạn cần là một số thử nghiệm chứng minh rằng các tính năng của nhà phát triển của bạn đang hoạt động chính xác. Chúng có thể bao gồm Kiểm tra đơn vị và Kiểm tra tích hợp nhưng lý tưởng nhất là một vài thử nghiệm tự động từ đầu đến cuối của các tính năng quan trọng. Tiêu chuẩn gói hồi quy.

Sau đó, khi việc hợp nhất của bạn đã được hoàn thành, bạn có thể kiểm tra báo cáo thử nghiệm tự động hóa cùng nhau và xác minh rằng mọi thứ đã được tích hợp thành công.

Tôi đồng ý với một trong những câu trả lời khác mà tác giả đã nêu Git PRs sẽ giải quyết vấn đề này bằng cách khiến mỗi nhà phát triển hợp nhất công việc của họ.

Một điểm khác mà tôi tin là đủ quan trọng để lại cho đến đoạn cuối cùng. Tôi đề nghị bạn nên chạy thử nghiệm thủ công qua các bản dựng hàng đêm của mình, thay vì chờ đến khi kết thúc nước rút. Các nhà phát triển nên hợp nhất ngay khi tính năng hoàn tất để có thể tích hợp, triển khai và thử nghiệm càng sớm càng tốt.

Đừng

Tùy thuộc vào ngôn ngữ của bạn và những tệp bạn đang chỉnh sửa, có thể không có ý nghĩa đối với mỗi nhà phát triển để chỉnh sửa chúng trên nhánh của họ. Ví dụ: trong C # tôi đã thấy tốt nhất chỉ một người có thể chỉnh sửa bất kỳ tệp thiết kế UI nào tại một thời điểm. Đây là các tệp được tạo tự động và do đó mã đôi khi được di chuyển xung quanh mà không có lý do rõ ràng - và điều này tàn phá hầu hết các công cụ hợp nhất.

Điều này có nghĩa là một số câu chuyện có thể chặn các câu chuyện khác cho đến khi hoàn thành công việc UI. Và / Hoặc, một câu chuyện mới được tạo ra để chỉ bố trí UI, với các câu chuyện khác thực hiện chức năng. Hoặc, có thể một nhà phát triển thực hiện tất cả UI hoạt động trong khi những người khác thực hiện chức năng của UI đó.

Trên một lưu ý liên quan, nếu bạn biết nhiều câu chuyện sẽ chạm vào cùng một tệp, bạn có thể chỉ muốn tránh làm việc trên tất cả chúng cùng một lúc. Đừng kéo tất cả chúng vào cùng một lần chạy nước rút, hoặc đừng bắt đầu làm việc với tất cả chúng cho đến khi một hoặc nhiều việc được thực hiện.

Một cách tiếp cận khả thi khác để tránh các sự hợp nhất muộn và lớn là các cờ tính năng : bạn bảo vệ các thay đổi của mình bằng một cờ có thể định cấu hình (lý tưởng nhất là động) để ngăn chúng hoạt động trước khi dự định.

Điều này cho phép bạn hợp nhất các thay đổi của bạn sớm trở lại vào một trong hai masterhoặc nhánh phát triển chung của bạn mà không phá vỡ bất cứ điều gì. Các nhà phát triển khác sau đó có thể hợp nhất các thay đổi này trở lại vào các nhánh tính năng của họ (hoặc khởi động lại các nhánh của họ theo đó).

Như các câu trả lời khác đã chỉ ra điều này nên được kết hợp với một giải pháp tích hợp liên tục.

Cờ tính năng có các lợi ích bổ sung (ví dụ: chúng giúp bạn dễ dàng thực hiện các thử nghiệm A / B). Xem bài viết này của Martin Fowler để biết thêm thông tin.

Chúng tôi đang theo cách tiếp cận của nhánh phát triển riêng cho từng tính năng và sau đó chúng tôi sẽ hợp nhất các nhánh với nhánh QA để thử nghiệm trong môi trường thử nghiệm tích hợp.

Sau khi hoàn thành kiểm tra hồi quy và tích hợp, chúng tôi dễ dàng di chuyển các tính năng đã sẵn sàng để chuyển sang nhánh phát hành.

Nếu mọi việc suôn sẻ, chúng tôi hợp nhất nhánh phát hành trở lại nhánh chính.

Nói một cách đơn giản, cam kết và sáp nhập thường làm giảm cửa sổ cơ hội cho các xung đột hợp nhất và sẽ giảm đáng kể xung đột. Phần khác thực sự được lên kế hoạch bởi người lãnh đạo, điều này có thể đảm bảo hơn nữa công việc trôi chảy.

Các câu trả lời khác cung cấp một số hiểu biết sâu sắc liên quan đến các thực tiễn tốt nhất cho các cam kết và chỉ cần làm theo những điều đó có thể sẽ làm giảm phần lớn các vấn đề hợp nhất của bạn. Nhiều sự hợp nhất gần như chắc chắn là một điều cần thiết, nhưng đối với một nhóm nhỏ hơn, cách tiếp cận chi nhánh của mỗi người có thể hoạt động đủ tốt. Tất nhiên, mặc dù không có nhiều thực hành mở rộng hơn!

Tuy nhiên, dường như không ai đã giải quyết một trong những câu hỏi quan trọng nhất của bạn - phải làm gì khi tất cả các bạn đều chạm vào cùng một khu vực mã. Đây là nơi hữu ích khi có một người dẫn đầu quen thuộc với cơ sở mã và có thể nhận ra sự phụ thuộc của các nhiệm vụ khác nhau. Nếu họ không sắp xếp thời gian làm việc và cam kết, bạn có thể sẽ kết thúc bằng xung đột hợp nhất và giải quyết theo từng dòng. Tổ chức các nhiệm vụ \ thời gian khó khăn hơn nhiều với một nhóm lớn hơn, nhưng với một nhóm nhỏ có thể xác định các nhiệm vụ xung đột này. Người dẫn đầu thậm chí có thể chuyển tất cả các nhiệm vụ liên quan sang cùng một kỹ sư, để tránh xung đột hoàn toàn.