Làm thế nào chúng ta chỉ có thể bao gồm các tính năng sẵn sàng được phát hành trong các bản phát hành sản xuất của chúng tôi mỗi tuần?

Tôi là nhà phát triển phần mềm trong một nhóm nhanh nhẹn (chúng tôi có tám nhà phát triển tích cực thay đổi một kho lưu trữ mã). Cứ sau hai tuần, chúng tôi lại đưa phiên bản mới của phần mềm vào sản xuất. Đây là quy trình làm việc hiện tại của chúng tôi:

• Khi bắt đầu một nhiệm vụ mới, các nhà phát triển tạo ra một "nhánh tính năng" từ nhánh phát triển chính (chúng tôi sử dụng git ) và làm việc với nhánh mới này
• Khi nhà phát triển đã hoàn thành công việc của họ, họ hợp nhất nhánh tính năng của họ trở lại nhánh phát triển
• Nhà phát triển sáp nhập nhánh phát triển vào nhánh QA.
• Một bản dựng được kích hoạt ngoài nhánh QA. Đầu ra của bản dựng này được triển khai vào môi trường QA của chúng tôi để cho phép người kiểm tra bắt đầu thử nghiệm.

Việc những người thử nghiệm của chúng tôi tìm thấy các vấn đề với các tính năng mới này đã được sáp nhập vào chi nhánh QA là khá phổ biến. Điều này có nghĩa là tại bất kỳ thời điểm nào, môi trường QA có thể chứa một số tính năng mới - một số tính năng đã được kiểm tra và không có lỗi và một số bị hỏng. Điều này làm cho việc phát hành trở nên khó khăn vì hiếm khi bản dựng QA ở trạng thái sẵn sàng sản xuất.

Để giảm thiểu điều này, chúng tôi đã cố gắng bắt đầu "đóng băng QA", nghĩa là các nhà phát triển không hợp nhất chi nhánh phát triển của chúng tôi vào chi nhánh QA một vài ngày trước khi phát hành. Sửa lỗi cho môi trường QA được thực hiện trực tiếp trên nhánh QA và sáp nhập xuống nhánh phát triển. Về mặt lý thuyết, điều này giúp các tính năng mới, bị hỏng ra khỏi QA trong khi vẫn cho phép chúng tôi khắc phục các sự cố đã có trong QA.

Mặc dù khái niệm "QA đóng băng" này đã thành công một phần, thật khó để phối hợp và mọi người thường bối rối về việc liệu họ có được phép hợp nhất với QA hay không. Thật khó để đặt ra thời hạn "QA đóng băng" - mọi người đều thích ý tưởng về một phòng thở giữa lúc đóng băng và phát hành, nhưng trên thực tế, họ muốn có tính năng của họ trong bản phát hành tiếp theo hơn là tôn trọng thời hạn.

Có cách nào tốt hơn để đảm bảo rằng chúng tôi có bản dựng sạch cho các bản phát hành của mình mỗi tuần không?

Có một vài vấn đề nổi xung quanh điều này đang gây ra vấn đề mà bạn đang gặp phải.

Đầu tiên là chi nhánh QA chạy dài. Có một nhánh chạy dài song song với đường chính phát triển có thể là một nguồn gây nhầm lẫn bởi vì có những nỗ lực khác nhau cần được nhân rộng trong cả nhánh QA và đường chính. Điều này có nghĩa là hoặc bạn đang kiểm tra các bản sửa lỗi cho nhánh QA cần được sáp nhập vào đường chính (không phải là điều xấu) hoặc bạn đang kiểm tra đường chính được sáp nhập vào nhánh QA (nguồn gây ra lỗi có thể xảy ra) .

Vấn đề khác với nhánh song song chạy dài là các tệp có thể bị mất đồng bộ vĩnh viễn. Một bản sửa lỗi mã không bao giờ được hợp nhất trở lại hoặc cấu hình cần thiết cho các bản dựng sản xuất không bao giờ được kiểm tra và là một phần của dòng chính phát triển.

Tiếp theo, bạn đã có những vai trò đang được áp dụng. Điều này có nghĩa là vai trò đóng gói (nhiều hơn về điều này sau này) sẽ không được cách ly đầy đủ.

Trong mô hình dòng chảy git , nhánh phát hành được phân nhánh từ phát triển ( không phát triển được sáp nhập với QA) và tất cả các bản sửa lỗi được kiểm tra vào nhánh phát hành và sau đó được sáp nhập trở lại nhánh phát triển.

Một số triết lý của việc phân nhánh có thể được tìm thấy trong Chiến lược phân nhánh SCM nâng cao (tôi coi là một bài đọc tuyệt vời). Điều này tập trung vào các vai trò mà mỗi chi nhánh có thể đảm nhận. Chi nhánh phát hành đảm nhận vai trò đóng gói.

Vai trò đóng gói thường bị nhầm lẫn với sự tích lũy hoặc, phổ biến hơn, vai trò chính. Khi việc phát triển và bảo trì dự định đã được thực hiện và bất kỳ sự tích lũy nào đã được thực hiện, đã đến lúc chuẩn bị mã để phát hành. Một nỗ lực như vậy có thể không tầm thường, đòi hỏi một đội ngũ kỹ sư phát hành và sửa chữa bổ sung ngoài những nỗ lực đã được thực hiện. Chính sách đối với chi nhánh đóng gói khác biệt đáng kể so với chính sách đối với chi nhánh bảo trì, như vai trò của bao bì cho thấy, chỉ cần thay đổi các thay đổi cần thiết để làm cho sản phẩm trở nên đáng tin cậy.

• Chi nhánh từ điểm phát triển đến chi nhánh phát hành. Nhánh phát hành mà QA xây dựng từ một nhánh và không có sự hợp nhất từ ​​sự phát triển.
  • Nếu bạn muốn đi theo con đường đó, với cách đặt tên và móc nhất quán, có thể ngăn việc hợp nhất được thực hiện thành một nhánh phát hành.
• Khắc phục mọi thứ cần được sửa trong nhánh phát hành và hợp nhất những thay đổi đó trở lại dòng chính.
• Khi kết thúc nỗ lực phát hành, hãy hợp nhất nhánh phát hành vào nhánh "phát hành tại đây" và gắn thẻ như vậy.
  • Một số trang web không có chi nhánh "phát hành tại đây" và chỉ để lại phần cuối của chi nhánh phát hành treo lủng lẳng với một thẻ.

Người ta nên nghiêm túc xem xét áp dụng toàn bộ dòng chảy git tại chỗ. Điều này không quá xa so với những gì đang được thực hiện và đặt một số kỷ luật và tính nhất quán vào ý nghĩa của từng chi nhánh và cách mỗi chi nhánh tương tác với các chi nhánh khác.

Vấn đề đối với tôi là bạn có một chi nhánh QA duy nhất.

Đối với mỗi bản phát hành, tạo một nhánh QA riêng biệt từ thân / chủ phát triển chính. Sau đó, hợp nhất chỉ sửa các lỗi cho các tính năng trên nhánh đó - không bao giờ là các tính năng mới. Có QA kiểm tra chi nhánh đó.

Theo cách này, "đóng băng" là khá rõ ràng - nó có trong tên chi nhánh. Bạn có thể sử dụng một cái gì đó như, tôi không biết release/26/10/2015. Sau đó, rõ ràng là không ai nên hợp nhất trong các tính năng mới sau này.

Điều này đặc biệt hữu ích nếu bạn thậm chí không rẽ nhánh cho đến khi đóng băng. Mọi người có thể hợp nhất để thành thạo bất cứ lúc nào, nó sẽ không trở thành một phần của phiên bản này nếu nó không được thực hiện đúng lúc để thử nghiệm.

Không có một chi nhánh QA hoạt động lâu dài, điều đó chỉ gây ra rắc rối. Ngã ba từ nhánh phát triển chính cho mỗi bản phát hành và QA nhánh đó.

Bạn phần nào được ánh xạ tới mô hình phân nhánh Phát triển-MAIN-Sản xuất được thấy dưới đây. Khu vực trên MAIN được cho là khu vực phát triển. Khu vực dưới MAIN là khu vực sản xuất.

Điểm nổi bật của mô hình này mà tôi cho là phù hợp với bạn:

• Các nhà phát triển của bạn cần Chuyển tiếp Tích hợp (FI) (FI = hợp nhất khỏi MAIN) thường xuyên (2-3 lần một tuần) vào các chi nhánh DEV của họ để đảm bảo các thay đổi mới nhất của họ luôn xem xét các phát triển chung mới nhất.
• Các nhà phát triển của bạn cần phải Tích hợp ngược (RI) (RI = hợp nhất với MAIN) trong nhánh TEST chỉ khi họ đã đạt được một cột mốc hoàn thành tính năng mà họ muốn đưa ra QA và họ sẵn sàng cung cấp các bản sửa lỗi kịp thời phản hồi với phản hồi QA. Các bản sửa lỗi sẽ được thực hiện trên nhánh TEST và ngay lập tức FI trong nhánh DEV của chúng.
• Không bao giờ RI từ bất kỳ chi nhánh DEV nào thành MAIN
• Luôn RI từ TEST chi nhánh thành MAIN, độc quyền khi QA của bạn coi chất lượng TEST là OK. Giữ một ngưỡng chất lượng cao để hợp nhất vào MAIN. Ít nhất, Trình quản lý sản phẩm của bạn phải luôn có thể giới thiệu phiên bản hoạt động của Sản phẩm từ cam kết mới nhất trong MAIN.
• Tạo chi nhánh trong khu vực sản xuất chỉ khi cần thiết. Máy chủ xây dựng của bạn phải luôn gắn thẻ tất cả các chi nhánh, bao gồm cả các chi nhánh từ khu vực phát triển và nguồn gốc của bất kỳ bản dựng / phát hành nào phải được nhận dạng mọi lúc bất kể chi nhánh đến từ đâu.
• Chỉ phát hành cho sản xuất từ ​​MAIN hoặc khu vực sản xuất. Nếu sau này bạn cần cung cấp bản sửa lỗi cho phiên bản được phát hành chính xác (nghĩa là bạn không thể cung cấp phiên bản mới nhất từ ​​MAIN), hãy tạo một nhánh trong khu vực sản xuất từ ​​thẻ MAIN của bản phát hành bị lỗi, khi cần sửa. Luôn khắc phục sự cố trên nhánh HotFix và sau đó ngay lập tức RI vào MAIN và FI thành TEST.

Tôi nghi ngờ bạn có vấn đề vì:

• Nhà phát triển của bạn RI vào mã TEST không hoàn thành cột mốc tính năng
• Nhà phát triển của bạn RI vào TEST mà không bật đèn xanh từ QA (tức là QA không kiểm soát được những gì được đưa vào TEST)
• Khi QA báo cáo lỗi trên TEST, các nhà phát triển của bạn sẽ sửa nó trên nhánh DEV của họ và sau đó RI vào TEST. Đây là một thực tiễn tồi tệ lớn bởi vì sự hợp nhất sẽ luôn mang lại sự tào lao không hoàn chỉnh khác. Họ phải luôn sửa nó trên TEST và sau đó FI vào nhánh DEV của họ. Nếu nó không thể sửa được trên TEST, họ đã phân phối toàn bộ crap ngay từ đầu và bạn gặp vấn đề lớn hơn.
• Các nhà phát triển của bạn không FI thường xuyên đủ từ TEST và vì vậy họ làm mất ổn định TEST bất cứ khi nào họ giao hàng ở đó. Đó là một nghệ thuật tốt cân bằng tần suất FI vào DEV. Trì hoãn nó quá nhiều và nó sẽ cực kỳ tốn kém & rủi ro ngay trước khi giao hàng, điều mà bạn không bao giờ muốn. Làm điều đó quá thường xuyên và bạn sẽ không thực hiện bất kỳ công việc phát triển thực tế nào nếu bạn chồng chéo quá nhiều với công việc được giao bởi người khác trong TEST trong thời gian đó.

Theo tôi hiểu câu hỏi bạn có hai vấn đề. (a) các tính năng bị hỏng đang được hợp nhất với các tính năng tốt mà bạn muốn phát hành; (b) bạn muốn có thể phát hành các tính năng tốt trong khi giữ lại các tính năng bị hỏng. Như một hạn chế đối với các giải pháp có thể, tôi giả sử bạn muốn thử nghiệm QA cuối cùng / chính thức của mình diễn ra trên một nhánh tích hợp có chứa tất cả các tính năng dự kiến ​​cho phiên bản tiếp theo.

Bất kể mô hình phân nhánh SCM của bạn là gì, tôi khuyên bạn nên thử một hoặc cả hai cách sau:

1. Chỉ định tài nguyên QA cho mỗi nhóm tính năng. Yêu cầu họ thực hiện một số thử nghiệm tính năng trên các bản dựng từ nhánh tính năng và cung cấp cho họ quyền quyết định khi nào một tính năng đủ tốt để hợp nhất. Lý tưởng nhất là để họ làm việc cộng tác với (phần còn lại) của nhóm tính năng, vì vậy công cụ sẽ được kiểm tra ngay sau khi được viết. (Lưu ý điều này không có nghĩa là họ phải tự thực hiện tất cả các thử nghiệm.)
2. Sử dụng các tính năng bật, thay vì các nhánh tính năng hoặc ngoài chúng. Hoàn thành đúng, các tính năng bật tắt cho phép bạn tắt một tính năng bị hỏng mà không cố gắng hợp nhất nó khỏi mã, để bạn có thể kiểm tra và phát hành các tính năng khác. Loại khách hàng mà tôi đang nói đến không thể truy cập được; bạn không muốn thử nghiệm số lượng kết hợp tăng theo cấp số nhân. Bạn đặt các nút bật trên nhánh QA để khớp với các tính năng bạn dự định phát hành và nếu kế hoạch thay đổi vì một tính năng chưa sẵn sàng, bạn thay đổi chuyển đổi đó.

Một giải pháp rất đơn giản mà tôi đã thấy làm việc trong một nhóm lớn hơn một chút so với bạn là nhờ mọi người làm việc và triển khai từ một chi nhánh.

Bạn nói rằng nhóm rất nhanh nhẹn nhưng không rõ bạn đang làm việc trong các lần chạy nước rút (ví dụ Scrum) hay cách tiếp cận dòng chảy liên tục hơn (tức là Kanban). Giả sử bạn đang thực hiện chạy nước rút, mục tiêu của nhóm là có mã có thể giải phóng được vào cuối mỗi lần chạy nước rút, để phát hành hai tuần một lần. Không có sự nhầm lẫn về việc liệu một tính năng sẽ phá vỡ một tính năng khác vì tất cả chúng đã được phát triển cùng nhau. Người kiểm tra có thể có quyền truy cập vào các tính năng trong các phần nhỏ hơn vì chi phí cho các nhà phát triển để cung cấp cho họ thấp hơn. Và bạn không thực sự cần QA-Freeze, thay vào đó mọi người đều biết khi kết thúc cuộc chạy nước rút và không nên tiếp tục công việc mà họ không thể hoàn thành hoặc để ở trạng thái có thể triển khai (nghĩa là bị vô hiệu hóa).

Rõ ràng có những ưu và nhược điểm đối với bất kỳ phương pháp nào, tôi trình bày đây là một lựa chọn không nhất thiết là 'cách tốt nhất'.

Lý do bạn gặp phải những vấn đề này là do mã của bạn được phát hành cho QA không đủ chất lượng (và là bất kỳ ai?!), Vì vậy bạn cần bắt đầu nhận bản phát hành tốt hơn cho QA để họ không cần phải nhận bigfix thường xuyên. cách đơn giản nhất để làm điều này là giới thiệu một nhánh trung gian mà bạn phát hành (hãy gọi nó là kiểm tra). Điều này vẫn đang trong giai đoạn phát triển, nhưng nó cho phép các nhà phát triển thúc đẩy nó tiếp tục hoạt động, đồng thời có một nhánh tích hợp đủ chất lượng đủ tốt để được gửi đến QA.

Kiểm thử tích hợp có thể diễn ra trên nhánh này để tìm các lỗi mà QA hiện đang tìm thấy, các lỗi có thể được sửa trên nhánh ban đầu và sau đó được hợp nhất lại và cho đến khi đúng hoặc có thể sửa lỗi trực tiếp trên nhánh này (Tôi khuyên bạn nên trước đây). Khi nó đã vượt qua một loạt các thử nghiệm cơ bản, sau đó nó có thể được gửi đến QA cho 'ngón tay người dùng và họ đã làm gì?' thử nghiệm.

Vì vậy, cách tiếp cận này được thiết kế để bảo vệ nhánh QA khỏi các tính năng phát triển bị hỏng - cho dù đó là vì tính năng này không được mã hóa đủ tốt hay liệu có vấn đề tích hợp bất ngờ nào không thành vấn đề. Chỉ các nhánh dev vượt qua kiểm tra tích hợp mới được thăng cấp lên QA.