Các nhà phát triển bị chặn bằng cách chờ mã để hợp nhất từ ​​một chi nhánh khác bằng GitFlow

Nhóm chúng tôi vừa thực hiện chuyển đổi từ FogBugz & Kiln / Mercurial sang Jira & Stash / Git. Chúng tôi đang sử dụng mô hình Git Flow để phân nhánh, thêm các nhánh con ra khỏi các nhánh tính năng (liên quan đến các nhiệm vụ Jira của các tính năng Jira). Chúng tôi đang sử dụng Stash để chỉ định người đánh giá khi chúng tôi tạo yêu cầu kéo để hợp nhất trở lại vào nhánh cha (thường phát triển nhưng cho các nhiệm vụ trở lại vào nhánh tính năng).

Vấn đề chúng tôi tìm thấy là ngay cả với việc lập kế hoạch và phân tích các trường hợp tính năng tốt nhất, khi nhiều nhà phát triển đang làm việc cùng một tính năng, hãy nói về front-end và back-end, nếu họ đang làm việc với mã phụ thuộc lẫn nhau trong các nhánh riêng biệt, một nhà phát triển sẽ chặn người kia.

Chúng tôi đã cố gắng kéo giữa các chi nhánh của nhau khi chúng tôi phát triển. Chúng tôi cũng đã thử tạo các nhánh tích hợp cục bộ mà mỗi nhà phát triển có thể lấy từ nhiều nhánh để kiểm tra sự tích hợp khi họ phát triển. Cuối cùng, và điều này dường như có thể hoạt động tốt nhất cho chúng ta cho đến nay, mặc dù với chi phí cao hơn một chút, chúng tôi đã cố gắng tạo một nhánh tích hợp từ nhánh tính năng ngay lập tức. Khi một nhánh con (ngoài nhánh tính năng) đã sẵn sàng cho yêu cầu kéo và xem xét mã, chúng tôi cũng sẽ hợp nhất các bộ thay đổi đó vào nhánh tích hợp tính năng này. Sau đó, tất cả các nhà phát triển quan tâm có thể kéo từ nhánh tích hợp đó vào các nhánh con phụ thuộc khác. Điều này ngăn không cho bất kỳ ai chờ đợi bất kỳ chi nhánh nào mà họ phụ thuộc để vượt qua đánh giá mã.

Tôi biết đây không nhất thiết là vấn đề Git - nó liên quan đến việc làm việc với mã phụ thuộc lẫn nhau trong nhiều nhánh, pha trộn với quá trình làm việc và văn hóa của chính chúng ta. Nếu chúng tôi không có chính sách rà soát mã nghiêm ngặt để phát triển (nhánh tích hợp thực sự) thì nhà phát triển 1 có thể hợp nhất để phát triển cho nhà phát triển 2. Một điều phức tạp khác là chúng tôi cũng được yêu cầu thực hiện một số thử nghiệm sơ bộ như một phần của quy trình xem xét mã trước khi chuyển tính năng này cho QA. Điều này có nghĩa là ngay cả khi nhà phát triển front-end 1 đang trực tiếp rút khỏi chi nhánh của nhà phát triển back-end 2 khi họ đi, nếu nhà phát triển back-end 2 kết thúc và yêu cầu kéo của anh ấy / cô ấy đang chờ xem xét mã trong một tuần, thì về mặt kỹ thuật, nhà phát triển front-end 2 về mặt kỹ thuật không thể tạo yêu cầu kéo / đánh giá mã của anh ấy bởi vì người đánh giá mã của anh ấy / cô ấy không thể kiểm tra vì nhà phát triển back-end 2 '

Điểm mấu chốt là chúng ta đang tìm cho mình một cách tiếp cận nhiều hơn là cách tiếp cận song song trong các trường hợp này, tùy thuộc vào tuyến đường chúng ta đi và muốn tìm một quy trình sử dụng để tránh điều này.

Điều cuối cùng tôi sẽ đề cập là chúng tôi nhận ra bằng cách chia sẻ mã trên các chi nhánh chưa được xem xét và hoàn thiện mã nhưng về bản chất chúng tôi sử dụng mã beta của người khác. Ở một mức độ nhất định, tôi không nghĩ rằng chúng ta có thể tránh điều đó và sẵn sàng chấp nhận điều đó ở một mức độ nào đó.

Vấn đề cũng có thể nằm ở sự phân tách nhiệm vụ quá cứng nhắc giữa phát triển back-end và front-end.

Nếu nhà phát triển giao diện người dùng cần API mới, không thể cho phép anh ta hoặc cô ta tạo API giả ở mặt sau (ví dụ luôn trả về cùng một giá trị) để xác thực bố cục? Sau đó, cam kết thực hiện một phần với một sơ khai và trong lần thứ hai, nhà phát triển back-end sẽ triển khai tính năng thực sự.

Bằng cách phá vỡ sự phụ thuộc, bạn sẽ có được một luồng tốt hơn và bạn không dừng mọi thứ chờ đợi cho một nhiệm vụ duy nhất hoạt động như một nút cổ chai.

Vấn đề của bạn: Nhà phát triển A chi nhánh từ Master, nhà phát triển B chi nhánh từ Master, cả hai đều hoạt động trên các tính năng liên quan chặt chẽ và thực tế là việc sáp nhập vào chi nhánh Master rất khó khăn vì những xung đột không thể tránh khỏi là điều khiến mọi người phải kìm hãm.

Nếu điều này là có thể thấy trước, thì trước tiên A và B có thể tạo một nhánh chung, sau đó mỗi nhánh cho công việc riêng biệt của chúng từ nhánh chung này, hợp nhất từng công việc riêng biệt của chúng vào nhánh chung và bây giờ bạn có một nhánh không xung đột nhiều dễ dàng hòa nhập hơn

Nếu nhà phát triển 1 hoạt động trên tính năng A và nhà phát triển 2 hoàn thành hoạt động trên tính năng B phụ thuộc vào tính năng A, thì không có cách nào khác - tính năng hợp nhất B đang bị tạm dừng. Bạn không thể kiểm tra tính năng này nếu không có tính năng A và không có điểm nào để xem xét tính năng này vì tiến bộ trong tính năng A có thể dẫn đến thay đổi tính năng B.

Tuy nhiên, điều đó không có nghĩa là nhà phát triển 2 đang bị trì hoãn! Nhà phát triển 2 có thể bắt đầu làm việc trên tính năng C và quay lại chu trình sửa lỗi đánh giá của tính năng B sau khi tính năng A hoàn tất. Tôi biết rằng chuyển đổi bối cảnh không phải là tối ưu, nhưng kể từ thời điểm đó nó sẽ làm để hoàn thiện tính năng A được thể tính bằng ngày nó không phải là xấu (bạn không phải kéo họ ra khỏi "The Zone" cho 15 phút phụ nhiệm vụ)

Một điều bạn có thể làm để giúp tình hình là hãy xem xét các cách để rút ngắn chu kỳ phát triển.

Trong trường hợp nhà phát triển đang chờ đợi một tính năng từ nhà phát triển khác, có cách nào một phần các nhà phát triển đầu tiên làm việc có thể trải qua đánh giá và tích hợp trước toàn bộ tính năng để giải phóng khối không?

Có cách nào để chia các tính năng thành các đơn vị công việc nhỏ hơn để duy trì chu kỳ tích hợp không?

Ngoài ra, quá trình tích hợp mất bao lâu? Nếu có một vòng quay dài trên một bản dựng hoặc tích hợp, điều đó có thể làm chậm toàn bộ hàng đợi. Xem nếu có bất cứ điều gì bạn có thể làm để tăng tốc thời gian xây dựng để hàng đợi được giải phóng nhanh hơn.