Chiến lược phân nhánh cho môi trường thử nghiệm

Chúng tôi sẽ bắt đầu một dự án mới trong tháng này. Dự án sẽ là 1 năm và việc triển khai sản xuất sẽ chỉ diễn ra vào cuối dự án.

Chúng tôi sẽ thực hiện phát triển lặp (1 tháng cho mỗi lần lặp), vì vậy điều này có nghĩa là chúng tôi sẽ bỏ các tính năng vào môi trường Kiểm tra vào cuối mỗi lần lặp để kiểm tra QA.

Chiến lược phân nhánh của chúng tôi là:

1. Trunk - Tất cả sự phát triển sẽ xảy ra trên thân cây.
2. Nhánh tính năng - Các nhánh ngoài thân cây sẽ được tạo trên cơ sở theo nhu cầu để phát triển các tính năng lớn có khả năng bị phá vỡ nếu được thực hiện trên thân cây
3. Các nhánh phát hành QA - Vào cuối mỗi lần lặp, một nhánh của thân cây sẽ được tạo. Chi nhánh này (bao gồm số phiên bản) sẽ được phát hành cho môi trường Kiểm tra. Tất cả các lỗi nghiêm trọng và chặn được tìm thấy trong phiên bản này sẽ được sửa trên nhánh này và các bản sửa lỗi sẽ phải được hợp nhất vào thân cây. Các lỗi không quan trọng / tầm thường sẽ không được xử lý trên nhánh phát hành QA và sẽ chỉ được sửa trong thân cây vì nhánh phát hành QA sẽ bị loại bỏ sau khi kết thúc lần lặp tiếp theo nơi nhánh phát hành mới sẽ được tạo ra khỏi thân cây.
4. Chi nhánh sản xuất - đây sẽ là chi nhánh phát hành QA mới nhất vào cuối dự án. Điều này sẽ được gắn thẻ và tất cả các bản sửa lỗi sản xuất sẽ nằm trên nhánh này và được hợp nhất vào thân cây.

Đây có phải là một chiến lược phân nhánh chính xác? Có điều gì khác mà chúng tôi đã bỏ lỡ để xem xét?

Chúng tôi đang sử dụng SVN.

Chiến lược phân nhánh của bạn trông thực sự tốt với tôi. Tôi đã thực hiện chiến lược tương tự trong quá khứ và nó hoạt động tốt. Vẽ nó lên một bảng trắng và khiến tất cả các nhà phát triển của bạn hiểu nó để mọi người thực hiện đúng công việc trong nhánh phải. Dạy và giải thích cho mọi người lệnh chuyển đổi và khiến mọi người nhân đôi chi nhánh mà họ đang làm việc. (Hoặc thay vào đó chỉ cần kiểm tra toàn bộ repo ... tùy thuộc vào kích thước mã của bạn :) Hãy nhớ ... svn hoàn nguyên là người bạn tốt nhất của bạn!

Cá nhân tôi thích một người là người "hợp nhất / chi nhánh" (với một vài người dự phòng làm dự trữ) để đảm bảo rằng mọi thứ được kiểm soát và nhất quán. Hãy để người đó trở thành bậc thầy SVN của bạn và bạn sẽ đi.

Một vài gợi ý hữu ích khác:

• Khuyến khích cập nhật SVN thường xuyên và cam kết SVN. Mỗi ngày là thích hợp hơn.
• Việc hợp nhất giữa các chi nhánh cũng nên được thực hiện mỗi ngày hoặc cách khác mỗi khi sửa lỗi. Làm chúng sớm và làm chúng thường xuyên! (bạn sẽ nhận được nó rất nhanh).
• Nhận một công cụ khác biệt tốt - beyondcompare là ace. Một con rùa tiêu chuẩnSVN ... không quá tốt.
• Đừng kiểm tra những thứ thay đổi khi biên dịch (như thư mục đầu ra của bạn)
• Cố gắng dọn sạch repo của bạn trước khi bạn bắt đầu phân nhánh (loại bỏ các tệp không cần kiểm soát phiên bản - những thứ như thư viện bên ngoài, v.v.). Repo của bạn càng nhỏ thì càng tốt
• Các thay đổi đối với nhánh Sản xuất và các nhánh QA của bạn phải nhỏ và ngắn nhất có thể - đừng bắt đầu tái cấu trúc mã ở đó, chỉ cần sửa lỗi.
• Hãy chắc chắn rằng bạn phân nhánh từ cấp cao nhất của giải pháp của mình - và nếu bạn có DB, tôi hy vọng bạn đã viết kịch bản tất cả các công cụ DB của bạn (như các trình kích hoạt hoặc trình kích hoạt được lưu trữ)

Cũng nói với mọi người không di chuyển các thư mục xung quanh trừ khi nó thực sự cần thiết. Điều này sẽ làm cho việc hợp nhất của bạn dễ dàng hơn nhiều :) (Đừng làm những gì tôi đã làm, khởi chạy một thư mục lớn tái cấu trúc giữa chừng một thay đổi lớn đối với thân cây đã làm hỏng tất cả các sự hợp nhất của chúng tôi ... Tôi đã khá nổi tiếng sau đó).

Nghe có vẻ như một ý tưởng có thể không hoạt động.

Có thể hãy xem liên kết này để tìm cảm hứng: GitHub Flow Đây là cách mà github đang sử dụng hệ thống phiên bản của nó. Mặc dù họ sử dụng git thay vì svn, tôi sẽ lập luận rằng các ý tưởng đằng sau quyết định của họ sẽ được giữ vững.

(Imho) phần quan trọng nhất của bài đăng blog này liên quan đến phiên bản:

• master / trunk có thể triển khai hoặc - thậm chí tốt hơn - được triển khai
• phát triển chỉ xảy ra trên các chi nhánh
• hợp nhất chỉ xảy ra sau khi xem xét (có thể bạn có thể đặt QA tại đây)

Bằng cách này bạn có được sự ổn định. Hãy để tôi giải thích tại sao. Bạn cần một số cơ sở để phân nhánh. Bây giờ nếu cơ sở này không phải là điều tốt nhất bạn có thể làm và là ví dụ cuối cùng của mọi thứ thì nó không thực sự có ý nghĩa để làm như vậy. Nếu bạn phân nhánh từ thân cây trong khi những người khác làm việc trên nó, bạn sẽ thấy các lỗi họ giới thiệu xảy ra chưa được tìm thấy hoặc sửa chữa. Vì vậy, các thử nghiệm tích hợp (và bất cứ điều gì ở trên) có thể thất bại đối với bạn mặc dù bạn không phải là nguyên nhân, làm tăng đáng kể số lượng gỡ lỗi và thất vọng.

Hơn nữa, bạn sẽ có rất nhiều công việc giữ cho 3 chi nhánh của bạn (thân cây, QA, sản xuất) đồng bộ. Điều này có thể sẽ dẫn đến nhầm lẫn. Tôi gần như có thể đảm bảo bạn sẽ mất theo dõi tại một số thời điểm nếu bạn không thực thi điều này với tự động hóa.

Tôi sẽ đề nghị đi theo cách GitHub đang đi. Sau đó, bạn có thể gắn thẻ phiên bản nào bạn gửi tới QA để có tài liệu tham khảo khi liên lạc. Thậm chí tốt hơn có thể có QA tích hợp chặt chẽ hơn trong vòng phản hồi như đã nêu ở trên. Tôi thực sự khuyên bạn nên sử dụng hệ thống CI như Jenkins nếu bạn chưa cân nhắc sử dụng hệ thống này. Bằng cách đó, bạn giảm thiểu thời gian khứ hồi giữa đăng ký và phản hồi và bạn có thể thực thi các quy tắc mã hóa, chạy máy phân tích tĩnh để kiểm tra lỗi, v.v.

Tuyên bố từ chối trách nhiệm: Luồng git chỉ hoạt động nếu bạn không muốn sửa lỗi mà không giới thiệu các tính năng mới. Nếu bạn muốn làm điều này, phương pháp của bạn có thể phù hợp hơn.

Chiến lược phân nhánh của bạn đánh tôi là khá hợp lý. Chúng tôi đã theo đuổi một chiến lược tương tự tại công ty của tôi và nó đã làm việc tốt với chúng tôi.

Một điểm khác biệt nhỏ là chúng tôi thực hiện sửa lỗi QA trước khi phát hành trên thân vì nó ngăn chúng tôi khỏi phải hợp nhất trở lại và chúng tôi thực sự không gặp vấn đề gì với việc phát triển các tính năng mới trong khi sửa lỗi. Điều này mang lại cho QA nhiều hơn một chút mục tiêu di động về mặt những gì họ đang thử nghiệm, vì vậy mức độ khả thi này phụ thuộc vào mức độ QA tích hợp chặt chẽ với nhóm nhà phát triển. Nó hoạt động tốt cho chúng tôi bởi vì chúng tôi có một nhóm tích hợp khá và bởi vì chúng tôi đang có một lịch trình lặp lại nhanh chóng. Chúng tôi có một chi nhánh riêng cho mỗi bản phát hành để chúng tôi có thể vá môi trường sản xuất trong khi vẫn xây dựng các tính năng mới trên thân cây, nhưng dường như điều đó sẽ không cần thiết cho bạn cho đến sau này khi bạn bắt đầu phát hành ngoài QA.

Có một vài khuyến nghị bổ sung mà tôi sẽ đưa ra:

1. Khuyến khích đăng ký thường xuyên. Điều này đặc biệt hữu ích nếu bạn có nhiều người phát triển trên thân cây. Nó sẽ ngăn các nhà phát triển thoát khỏi sự đồng bộ với những gì người khác đang làm và giảm nguy cơ xung đột. Hãy chắc chắn rằng có hướng dẫn rõ ràng về thời điểm cam kết ổn và mức độ thường xuyên mà các nhà phát triển sẽ nhận được từ thân cây. Cam kết thường xuyên không phải là một vấn đề do bạn đang cố gắng cô lập các thay đổi vi phạm đối với các nhánh tính năng.
2. Viện một quá trình hội nhập liên tục. Điều này tiếp tục đảm bảo rằng bạn không phải chịu những cơn đau đầu tích hợp lớn khi kết thúc vòng lặp, cung cấp thông báo nếu có gì đó bị hỏng và hãy để bạn tự động hóa nhiều hơn QA của mình thông qua các bài kiểm tra đơn vị / chấp nhận tự động và có khả năng thông qua phân tích / mã tĩnh dụng cụ kiểm tra. Tôi đã tìm thấy CI cung cấp "tiếng nổ lớn" như một khoản đầu tư vào quy trình quản lý cấu hình. Ghi chú, có một sự căng thẳng giữa CI và sử dụng các nhánh tính năng rất nhiều vì các nhánh về cơ bản cho phép bạn giữ cho thân cây sạch sẽ, vượt qua các bài kiểm tra của bạn trong CI, nhưng vẫn tạo ra xung đột / vấn đề trong các nhánh. Việc hợp nhất thường xuyên trở lại vào thân cây có thể giúp điều này như có thể chạy CI trong nhánh và kéo ra khỏi thân cây thường xuyên, nhưng sự tăng sinh của các nhánh sẽ bắt đầu đánh bại quá trình CI bằng cách làm phức tạp việc quản lý của nó, hoặc đơn giản là bỏ qua nó trong các nhánh.

Từ những gì bạn nêu:
Mã của bạn nằm trong thân cây
Đối với mỗi tính năng / cải tiến chính - bạn cắt một nhánh khỏi thân cây - phát triển và sau đó cung cấp cho QA để kiểm tra
Tất cả các lỗi chính và quan trọng đều được sửa trong
thân cây 'QA' Đăng QA bạn ' 'mã từ chi nhánh này trở lại thân cây

Đây là một chiến lược khá ok với tôi,
chúng tôi đã thường xuyên phân nhánh, sáp nhập và chuyển đổi thành SVN bằng cách sử dụng plugin svn eclipse hoặc rùa
Có vẻ tốt với tôi

Nghe có vẻ ổn, tôi lo lắng rằng nhánh QA tương đối ngắn và tôi sẽ thực hiện tất cả các bản sửa lỗi liên quan đến bản phát hành đó trên nhánh đó để chúng được hợp nhất vào thân cây trên 1 thay vì sửa chúng trên thân cây khi chúng được tìm thấy .

Nếu bạn sửa các lỗi nhỏ trên nhánh QA thì người kiểm tra có thể thấy và đánh dấu chúng nhanh chóng. Tôi cho rằng họ nhận được các bản dựng hàng ngày / hàng tuần ngoài chi nhánh QA, vì vậy các lỗi nhỏ không nên tốn thời gian nếu thực hiện trên QA. (Tôi nói từ kinh nghiệm nơi những con bọ nhỏ nhất có thể gây ra hiệu ứng kích thích gây ra nỗi đau lớn ở nơi khác)

Một cải tiến tiềm năng mà tôi có thể đề cập là thực hiện phát triển tính năng trên một nhánh - tức là chuyển công việc bạn thường làm trên thân cây sang một nhánh chuyên dụng thay thế. Sau đó, thân cây sẽ chỉ có các hợp nhất được cam kết với nó, có thể giúp theo dõi các thay đổi đã hoàn tất.

Bạn đề cập đến một số điều có khả năng làm tăng sự lúng túng và giảm cơ hội thành công cho dự án của bạn:

Dự án sẽ là 1 năm và việc triển khai sản xuất sẽ chỉ diễn ra vào cuối dự án.

Tôi thực sự, thực sự khuyên bạn nên triển khai đến một môi trường giống như sản xuất thường xuyên nhất có thể, lý tưởng mỗi ngày. Để cái gọi là "sản xuất" đến cuối dự án thường dẫn đến những vấn đề không lường trước được. Các mô hình chống ở đây là 'tích hợp muộn' và 'triển khai sản xuất muộn'.

1 tháng cho mỗi lần lặp

Một tháng là một nhịp tim lặp lại rất dài và rất ít nhà phát triển sẽ có thể nhớ rõ những gì họ đã làm khi bắt đầu lặp lại. Tôi khuyên bạn nên đi lặp lại trong 2 tuần, phân phối theo đợt nhỏ hơn. Chống mẫu: 'kích thước lô lớn', 'thời gian chu kỳ dài'.

Chi nhánh tính năng

Bạn có thể nên tránh các nhánh tính năng, trừ khi bạn cũng sử dụng các nhánh tích hợp . Thay vào đó, lý tưởng nhất là sử dụng tính năng bật tắt và trừu tượng hóa chi nhánh. Tính năng phân nhánh có xu hướng dẫn đến các vấn đề tích hợp muộn bất ngờ. Chống mẫu: 'hội nhập muộn'.

Chúng tôi đang sử dụng SVN.

Việc hợp nhất khá khó khăn trong Subversion, ngay cả khi bạn sử dụng các tính năng theo dõi hợp nhất của v1.5 trở lên. Tôi khuyên bạn nên chuyển sang Git - bạn sẽ không bao giờ nhìn lại. Sáp nhập với Git là không đau so với Svn. Tôi đã sử dụng Subversion trong nhiều năm và ban đầu hoài nghi về Git, nhưng bây giờ tôi đã 'bán'. Điều duy nhất tôi sử dụng Svn cho hơn Git là để lưu trữ tệp nhị phân (nếu thực sự cần thiết!) Và cho những thứ như RANCID hoàn toàn kiểm soát repo. Để kiểm soát mã nguồn, Git đánh bại Subversion mỗi lần.

Gần đây tôi đã viết về công việc tôi đã thực hiện khi phát hành từ trunk / mainline / master và tránh các nhánh tính năng, điều này có thể cung cấp cho bạn thêm 'thức ăn cho suy nghĩ': Rời khỏi Nền tảng - Phân nhánh và Phát hành cho các hệ thống con độc lập

Ngoài ra, đọc một số bài viết trên trang web của Martin Fowler, chẳng hạn như ContinuousIntegration , FeatureBranch , và BranchByAbstraction .

Cuối cùng, mua một bản sao Giao hàng liên tục của Jez Humble và David Farley và làm việc thông qua các khuyến nghị - đó là một cuốn sách cực kỳ giá trị và mỗi nhà phát triển nên sở hữu một bản sao. Tôi đã thấy hữu ích khi in ra các trang Nội dung và đặt chúng lên tường để theo dõi tiến trình :) Ngay cả khi bạn không có ý định giao hàng liên tục, rất nhiều thực tiễn trong cuốn sách này thực sự lành mạnh và quan trọng để phân phối phần mềm thành công hôm nay.

Hi vọng điêu nay co ich.

M