Dừng các nhà phát triển cam kết với chi nhánh sai trên DVCS

Vấn đề

Tôi đang tham gia một dự án phần mềm có khoảng 10 nhà phát triển, chúng tôi chia sẻ mã nguồn thông qua Mercurial. Chúng tôi có một chi nhánh phát triển và sản xuất mỗi phát hành. Lặp đi lặp lại trong suốt quá trình của dự án, chúng tôi đã có mã nguồn từ một nhánh, tức là v1 vào các nhánh vá và bảo trì để phát hành phần mềm trước đó, v2.

Điều này dẫn đến việc mất thời gian sao lưu cam kết sai hoặc mã sai (có thể không phải là QAd) tiếp cận và được triển khai ở nhánh sai nếu chúng tôi không nhận thấy rằng mã đã đi sai nhánh.

Chi nhánh của chúng tôi và hợp nhất thiết kế / phương pháp

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

Do đó, chúng tôi sẽ làm việc trên một nhánh phát triển phát hành, cho đến khi nó được coi là sẵn sàng , phân nhánh nó cho một nhánh thử nghiệm / UAT / Sản xuất, trong đó tất cả các bản phát hành và bảo trì được thực hiện. Thẻ được sử dụng để xây dựng các bản phát hành của chi nhánh này. Trong khi v1 đang được thử nghiệm, một nhánh sẽ được tạo cho v2 và các nhà phát triển sẽ bắt đầu làm việc trên các tính năng mới.

Điều có xu hướng xảy ra là một nhà phát triển cam kết làm việc do nhánh v2-dev thành v1-dev hoặc v1-prod, hoặc tệ hơn, họ hợp nhất v2-dev thành v1-prod (hoặc các lỗi tương tự như vậy).

Chúng tôi nói với hầu hết các nhà phát triển không truy cập vào các nhánh -prod , tuy nhiên mã vẫn lẻn vào. Một nhóm các nhà phát triển cao cấp hơn 'chăm sóc' nhánh -prod.

Cần lưu ý rằng trong khi v2 mới bắt đầu phát triển, vẫn có thể có một số bản vá khá lớn đi vào v1 để khắc phục sự cố. Tức là v1 có thể không chỉ nhận được các bản vá nhỏ lẻ.

Những gì chúng tôi đã cố gắng cho đến nay

• Có một chi nhánh riêng, với người gác cổng. Chi nhánh -prod sẽ đưa ra cảnh báo thông qua tên của nó và hầu hết các nhà phát triển không cần phải ở trong chi nhánh đó. Điều này đã không thực sự làm giảm vấn đề.
• Nâng cao nhận thức về vấn đề này trong số các nhà phát triển, để cố gắng và làm cho họ cảnh giác hơn. Một lần nữa điều này đã không được rất thành công.

Những lý do có thể tôi thấy đối với các nhà phát triển cam kết sai chi nhánh

• Thiết kế chi nhánh quá phức tạp
• Có sự phát triển tích cực trong nhiều ngành song song. (Dự án thể hiện các triệu chứng của việc sử dụng mô hình tuyết lở .)
• Các nhà phát triển không hiểu rõ về DVCS

Những câu hỏi tôi đã đọc có liên quan

Tôi đã đọc câu hỏi này về việc không cam kết sai chi nhánh và tôi cảm thấy rằng các câu trả lời liên quan đến tín hiệu thị giác có thể hữu ích. Tuy nhiên tôi không hoàn toàn tin rằng các vấn đề chúng ta gặp phải không phải là triệu chứng của một vấn đề cơ bản hơn.

Với các manh mối trực quan, chúng ta có thể kết hợp chúng vào dòng lệnh một cách dễ dàng, tuy nhiên khoảng một nửa đội sử dụng nhật thực mà tôi không chắc chắn cách kết hợp các tín hiệu thị giác.

Câu hỏi

Những phương pháp nào, dưới dạng phần mềm, quản lý dự án hoặc quản trị mà chúng ta có thể sử dụng để giảm (dừng lý tưởng) cam kết với chi nhánh sai chiếm thời gian của chúng tôi hoặc làm bẩn mã triển khai của chúng tôi?

Nhận xét cụ thể về lý do tôi tin rằng có thể đóng góp như đã nêu ở trên sẽ được đánh giá cao, nhưng điều này không nên giới hạn câu trả lời của bạn.

Vấn đề là bạn đang thay đổi ý nghĩa của một nhánh là một phần trong suốt quá trình.

Ban đầu, v1 devchi nhánh là để phát triển. Tất cả các tính năng mới đi đến đó. Tại một số thời điểm trong tương lai, nó trở thành một chi nhánh bảo trì cho v1 releasechi nhánh. Đây là mấu chốt của vấn đề.

Không phải là các nhà phát triển cẩu thả, mà là các quyền và vai trò của chi nhánh là cẩu thả và có thể thay đổi.

Những gì bạn cần làm là thiết lập vai trò của từng chi nhánh và duy trì vai trò đó. Nếu vai trò thay đổi, chi nhánh.

Ví dụ:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

Trong mô hình này, các nhà phát triển luôn cam kết với dev. Nếu bạn đang xây dựng một bản vá, bạn kiểm tra bản vá vào nhánh của bản phát hành đó (hoặc tốt hơn nữa, phân nhánh nhánh phát hành cho một bản vá và sau đó hợp nhất nó lại vào nhánh phát hành).

Một bài viết mà bạn nên đọc (và có lẽ nó là một cách nói chưa đúng về 'nên') là Chiến lược phân nhánh SCM nâng cao của Stephen Vance.

^{Trong bài báo này, trước tiên tôi định nghĩa phân nhánh theo nghĩa chung. Sau đó tôi sẽ thảo luận về các chiến lược khác nhau để phân nhánh, bắt đầu với sự rõ ràng và chuyển sang một số chiến lược phù hợp hơn cho các nỗ lực phát triển lớn hơn. Trên đường đi, tôi thảo luận về ưu và nhược điểm của từng chiến lược, sử dụng chúng để thúc đẩy những thay đổi tạo nên các chiến lược phức tạp hơn ...}

Trong bài viết này, ông xác định năm vai trò mà các chi nhánh có thể có. Đôi khi một nhánh có thể lấp đầy hai vai trò và vai trò không nhất thiết cần một nhánh mới miễn là các chính sách vai trò không thay đổi giữa nhánh (đôi khi bạn sẽ thấy đề cập đến "nhánh trên chính sách không tương thích").

Những vai trò này là:

1. Chính tuyến. Đây là nơi các chi nhánh được làm từ. Luôn phân nhánh từ tuyến chính giúp việc hợp nhất trở nên dễ dàng hơn vì hai nhánh sẽ có một tổ tiên chung không phân nhánh trên các nhánh.
2. Phát triển. Đây là nơi các nhà phát triển kiểm tra mã. Một người có thể có nhiều nhánh phát triển để cô lập những thay đổi rủi ro cao từ những thay đổi thường xuyên và trần tục.
3. Bảo trì. Sửa lỗi trên một môi trường sản xuất hiện có.
4. Tích lũy. Khi sáp nhập hai chi nhánh, người ta có thể không muốn mạo hiểm gây mất ổn định tuyến chính. Vì vậy, phân nhánh tuyến chính, hợp nhất các nhánh vào bộ tích lũy và hợp nhất trở lại tuyến chính sau khi mọi việc được giải quyết.
5. Bao bì. Đóng gói một bản phát hành xảy ra trong các ngành đóng gói. Điều này thường trở thành bản phát hành và phục vụ để cô lập nỗ lực phát hành khỏi sự phát triển. Xem Làm thế nào để đối phó với các cam kết không mong muốn phá vỡ các bản dựng phát hành dài hạn? cho một ví dụ về nơi bao bì xung đột với sự phát triển.

Trong ví dụ của bạn, bạn đã có một dòng chính xếp tầng (đây là một vấn đề - nó làm cho việc hợp nhất trở nên khó khăn hơn - điều gì xảy ra nếu bạn muốn hợp nhất một bản sửa lỗi cho v1 vào v2 và v3?), Một nhánh dev trở thành một nhánh bảo trì ( thay đổi chính sách, đây là một vấn đề).

Ok, bạn nói, điều đó thật tuyệt, nhưng điều này được viết cho lực lượng là một VCS tập trung - Tôi đang sử dụng DVCS.

Hãy nhìn vào mô hình dòng chảy git và xem nó áp dụng như thế nào.

Nhánh chính (màu xanh) là nhánh phát hành - để gắn thẻ. Nó không phải là chính. Dòng chính thực sự là nhánh phát triển (màu vàng). Các nhánh phát hành (màu xanh lá cây) là vai trò đóng gói. Phát triển rủi ro thấp xảy ra trong dòng chính, phát triển rủi ro cao xảy ra trong các nhánh tính năng (màu hồng). Trong mô hình này, tích lũy được thực hiện trong nhánh phát triển. Bảo trì được coi là "sửa chữa nóng" có màu đỏ.

Mặc dù các chính sách vai trò không khớp chính xác (mỗi sản phẩm có vòng đời hơi khác nhau), chúng là một đối sánh.

Làm điều này sẽ đơn giản hóa chính sách phân nhánh của bạn và giúp mọi người tham gia dễ dàng hơn.

Mặc dù bạn đã thử sử dụng một nhánh -prod riêng biệt với người gác cổng, nhưng có vẻ như một kho lưu trữ được sử dụng để thực sự xây dựng sản xuất. Nếu các bản dựng sản xuất chỉ được thực hiện từ kho lưu trữ sản xuất, chỉ có thể ghi được bởi người gác cổng thì các nhà phát triển sẽ không thể đẩy nó. Điều này đặt một tải lên người gác cổng, người sẽ chỉ đẩy vào repo sản xuất sau khi xem xét. Tất nhiên mọi người vẫn có thể rút khỏi repo sản xuất khi cần.

Khi mọi người có được kinh nghiệm, họ nên được xoay vòng qua vai trò người gác cổng, để có được sự hiểu biết sâu sắc hơn hoặc sự quan tâm mà họ dường như thiếu.

Và như một quy tắc chung, áp dụng Occam's Razor: toàn bộ cấu trúc repo nên đơn giản nhất có thể để thực hiện công việc của mình.

Xem thêm bình luận của Sean.

Có thể các nhà phát triển đơn giản là không có đủ DVCS, nhưng tôi nghĩ nhiều khả năng là bạn đơn giản đã có quá nhiều chuyện xảy ra và các nhà phát triển không thể theo dõi những gì họ đang làm từ lúc này đến lúc khác. Họ quên chi nhánh mà họ phải làm việc và những thay đổi của họ kết thúc ở sai vị trí.

Tôi đề nghị rằng bạn có một vấn đề với thực tế là mọi người đều làm việc trong tất cả các chi nhánh này một cách thường xuyên.

Đề xuất của @ andy256 về một kho lưu trữ riêng cho prod chắc chắn sẽ có ích, nhưng bạn có thể cần xem xét phân loại công việc khác nhau, hoặc có thể sắp xếp mọi thứ để không có nhà phát triển nào làm việc trên nhiều chi nhánh trong một tuần.

Điều này có vẻ như bạn đã xác định được một trong những con bọ lỗi lớn của tôi. Phần lớn các công cụ kiểm soát nguồn chính xác là như vậy, các công cụ kiểm soát nguồn. Chúng cho phép một loạt các nhà phát triển làm việc trên cùng một thư mục nguồn, thực hiện các thay đổi và xử lý xung đột. Đã có một vài cạnh khó khăn trên đường đi, nhưng cvs, lật đổ, git, thủy ngân v.v ... tất cả đều cung cấp về điều này.

Sau đó, bạn có bước tiếp theo, khi bạn cần ổn định mã để phát hành và bạn giới thiệu phân nhánh. Đây là nơi các công cụ bắt đầu thất bại các nhà phát triển. Các công cụ có khả năng tạo chi nhánh và thậm chí xác định các tập hợp thay đổi đã tích lũy trên các nhánh sau khi chúng được phân nhánh, nhưng đó không phải là vấn đề mà bạn hiện đang phải đối mặt.

Các công cụ thực sự kém trong việc lựa chọn những thay đổi cần được sao chép sang các nhánh khác và khi nào cần phải xảy ra. Git-Flow cố gắng giải quyết điều này bằng cách tạo ra một chiến lược phân nhánh, có nghĩa là khi các nhánh được hợp nhất, TẤT CẢ các thay đổi của nó được hợp nhất, và sau đó yêu cầu lập trình viên đưa ra các lựa chọn hợp lý về thời điểm và các nhánh được hợp nhất.

Trên một kho lưu trữ duy nhất nơi tất cả các nhà phát triển đang làm việc trên một dự án có một luồng phát hành duy nhất, luồng git giải quyết vấn đề, nhưng cuộc sống không đơn giản đối với nhiều công ty.

Môi trường phức tạp là nơi bạn có nhiều nhóm chịu trách nhiệm cho các khía cạnh khác nhau của tổng giải pháp, thực hiện các bản phát hành nội bộ cho các nhóm khác. git-Flow chỉ không có khả năng giải quyết loại vấn đề này.

Cách duy nhất tôi thấy công việc này là nếu mỗi nhóm chịu trách nhiệm xác định các bản phát hành của họ và kiểm soát khi sự phụ thuộc của họ thay đổi. Chỉ vì đội A đã phát hành phiên bản 1.3, đội B chỉ bắt đầu sử dụng bản phát hành 1.3 của đội A khi đội B chọn.

Trong thực tế, một nhóm các nhà phát triển xác định các nhóm thay đổi cần được di chuyển và các nhà phát triển nhận được các thay đổi xác định khi họ nhận được nhóm thay đổi.

Công cụ kiểm soát nguồn duy nhất mà tôi đã thấy thực sự mang lại điều này là chính xác - và thậm chí sau đó, hầu hết các nhà phát triển của bạn sẽ càu nhàu về nó vì GUI quá khó hiểu đối với họ và nó không hoạt động như lật đổ ...