luồng công việc git: cách tích hợp và thử nghiệm các chi tiết tính năng mà không cần phân phối liên tục?

Question

Tôi thích "github dòng chảy" công việc được mô tả bởi Scott Chacon rất nhiều: http://scottchacon.com/2011/08/31/github-flow.html

Ông mô tả tại sao github không sử dụng các quy trình làm việc dòng chảy git được mô tả bởi Vincent Driessen (http://nvie.com/posts/a-successful-git-branching-model/), và chúng tôi không sử dụng nó cho các cùng lý do, lý do quan trọng nhất là nó không hoạt động tốt với yêu cầu kéo và không phù hợp với phát triển trang web mà bạn không có "phiên bản chính thức phát hành sản phẩm phần mềm" nhưng không ngừng cải tiến trang web.

Chúng tôi đang phát triển một cộng đồng trực tuyến lớn trong một nhóm nhỏ với rất nhiều mã cũ (một số mã hơn 10 tuổi) với phạm vi kiểm tra không tốt. Chúng tôi đang sử dụng một luồng công việc tương tự như github, hiện tại chúng tôi sử dụng các chi tiết tính năng để phát triển và sử dụng các yêu cầu kéo để tích hợp chúng vào nhánh chính, thực hiện đánh giá ngang hàng, yêu cầu phản hồi, v.v. sáp nhập vào tổng thể. Một vài lần một tuần, chúng tôi thúc đẩy chủ nhân đến một môi trường dàn dựng được sử dụng bởi những người thử nghiệm của chúng tôi, cũng như người dùng beta. Chúng tôi cố gắng phát hành nhánh chính cho công chúng hai tuần một lần, vì vậy mọi nhánh tính năng được hợp nhất đều phải được kiểm tra đủ tốt và "các nhánh tính năng nguy hiểm hơn" sẽ không được hợp nhất trong vài ngày gần đây cho đến khi phát hành ra công chúng.

Đó không phải là quy trình làm việc hoàn hảo, bởi vì khi hợp nhất "các tính năng nguy hiểm" để làm chủ bắt đầu lại, chúng tôi không thể sử dụng chính để triển khai hotfix công khai nữa.

Github sử dụng phân phối liên tục để triển khai, không phải là tùy chọn cho chúng tôi, chúng tôi cần mọi người kiểm tra tính năng trước khi chúng tôi có thể phát hành công khai.

Yêu cầu kéo chỉ có thể được hợp nhất thành một nhánh. Vì vậy, đó là một quy trình làm việc đơn giản tại github với chỉ một nhánh chạy dài là master. Có lẽ chúng ta không nên phát hành hai tuần một lần, nhưng phát hành các yêu cầu kéo khi chúng được sáp nhập vào master? Nhưng theo cách đó khó kiểm tra, chúng tôi có thể chạy thử nghiệm đơn vị chúng tôi có trên nhánh tính năng trước khi hợp nhất và chúng tôi có thể triển khai nhánh để dàn dựng cho người thử nghiệm beta, nhưng điều đó không phải lúc nào cũng dễ dàng, đôi khi bạn phải làm cơ sở dữ liệu thay đổi theo cách thủ công (chúng tôi không thể tự động thực hiện, quá rủi ro vì máy chủ dàn dựng của chúng tôi dành cho người thử nghiệm beta sử dụng cơ sở dữ liệu sản xuất), vì vậy bạn phải đợi cho đến khi quản trị viên thực hiện. Và vấn đề lớn hơn là, nếu bạn chỉ phát hành các nhánh đặc trưng cho người dùng beta, chúng không được tích hợp, chúng sẽ thấy các tính năng mới và các tính năng bị xóa có thể nhiều lần trong ngày. Không phải để nói rằng bạn không thể chạy thử nghiệm tích hợp, hoặc bạn đã chạy chúng rất muộn ngay trước khi phát hành, khi một nhánh tính năng vừa được hợp nhất thành chủ ...

Mặt khác, nếu chúng ta sử dụng 2 nhánh chạy dài như phát triển và làm chủ như được mô tả trong luồng git, chúng ta có thể giải quyết vấn đề hotfix, chúng ta có thể sử dụng pull-request để hợp nhất các chi tiết để phát triển, chúng ta có thể sử dụng pull request cho nhánh phát hành để kết hợp các thay đổi gần đây vào master, nhưng chúng ta có thể không hợp nhất các thay đổi để phát triển bằng cách sử dụng luồng công việc yêu cầu kéo.

Như bạn có thể thấy trong bài viết luồng github (# 6 - triển khai ngay lập tức sau khi xem xét), các kỹ sư github có thể triển khai không chỉ để sản xuất, mà còn với môi trường dàn dựng. Và không chỉ các kỹ sư có thể làm điều đó, mà còn hỗ trợ và thiết kế. Nhưng nó hoạt động như thế nào với chỉ một nhánh tích hợp? Bạn không cần môi trường dàn dựng nếu yêu cầu kéo cuối cùng sẽ được sản xuất trong vài giờ hoặc vài phút. Đôi khi chúng dường như triển khai các nhánh đặc trưng để dàn dựng, có ý nghĩa, nhưng chúng không được tích hợp, vì vậy những gì tôi mô tả ở trên sẽ xảy ra, bạn sẽ thấy các tính năng sắp tới và đi vào môi trường dàn dựng của bạn, ngay cả khi chúng hợp nhất các thay đổi từ chủ trước khi triển khai tính năng -branch để dàn dựng (bạn có nghĩ đây sẽ là một ý tưởng hay không?). Hay nó có ý nghĩa để có nhiều môi trường dàn dựng, một cho mọi chi nhánh tính năng? Nhưng bằng cách này một lần nữa bạn mất ưu thế từ hội nhập liên tục. Và như đã nói, tôi không nghĩ rằng bạn có thể làm điều này trong một môi trường thử nghiệm beta.

Tôi thấy vấn đề trong cả luồng công việc, luồng git và luồng github, tôi thích luồng github tốt hơn, nhưng có vẻ khó khăn nếu bạn không có vùng phủ sóng thử nghiệm tốt và cần nhiều người kiểm tra hơn.

Vì vậy, làm cách nào tôi có thể tích hợp và thử nghiệm các chi nhánh tính năng khi cần kiểm tra nhiều hơn (người thử nghiệm qa và beta)?

Answer 1

Bạn có thể có một vài người đứng đầu chi nhánh chạy dọc theo một chi nhánh tích hợp chung:

----A---B---C---D---E---F---G---H---I 
       \   \   \ 
       goodToGo testing  toBeTested