Chúng ta bắt đầu gặp phải một vấn đề khi chúng ta trở nên lớn hơn, trong đó các tính năng khiến nó được dàn dựng để thử nghiệm, nhưng đến lúc mọi thứ được kiểm tra và các tính năng mới được phê duyệt sẽ được thử nghiệm.

Điều này đang tạo ra một môi trường nơi chúng ta gần như không bao giờ có thể đẩy mạnh sản xuất vì chúng ta có sự kết hợp của các tính năng đã được kiểm tra và chưa được kiểm tra. Tôi chắc chắn đây là một vấn đề phổ biến, nhưng tôi chưa tìm thấy tài nguyên tốt nào cho chúng tôi.

Một số chi tiết cụ thể:

• GIT trên BitBucket
• Jenkins để triển khai theo kịch bản cho Azure

Điều tôi hy vọng là một cách để cô lập các tính năng khi chúng di chuyển qua các môi trường và chỉ đẩy những gì đã sẵn sàng để sản xuất.

Có vẻ như bạn có một vài vấn đề ở đây:

1. Xác định các tính năng cho một bản phát hành cụ thể

Đây là một vấn đề quản lý dự án, và một vấn đề phối hợp. Sẽ này tính năng được phát hành trước đó, đồng thời như, hoặc sau này khác tính năng? Nếu phát hành muốn xảy ra một tính năng tại một thời điểm, sau đó xác định đó. Nếu các tính năng sẽ được nhóm thành các bản phát hành, thì hãy tìm hiểu xem các nhóm đó là gì và thực thi nó với các nhà phát triển và người ra quyết định. Sử dụng theo dõi vấn đề hoặc hệ thống bán vé của bạn để gắn thẻ phát hành. Làm rõ rằng nếu một tính năng của một bản phát hành cụ thể là không có, thì tất cả chúng đều như vậy.

2. Chiến lược phân nhánh

Git-Flow là câu trả lời dễ dàng cho các vấn đề như thế này và mọi người thường sử dụng một biến thể của luồng git ngay cả khi họ không biết nó là gì. Tôi sẽ không nói rằng đó là một vấn đề cho tất cả các vấn đề, nhưng nó giúp ích rất nhiều.

Có vẻ như bạn đang gặp vấn đề với các chiến lược phát hành không xác định, trong đó các tính năng được phê duyệt scattershot và thứ gì đó đã bắt đầu phát triển từ lâu có thể được phát hành sau khi một thứ bắt đầu gần đây - tính năng nhảy vọt.

Các nhánh tính năng tồn tại lâu hoặc các nhánh phát hành đồng thời có lẽ là câu trả lời tốt nhất cho các loại vấn đề này. Hợp nhất (hoặc rebase, nếu bạn cảm thấy thoải mái với nó) mới nhất từ chủ thành các nhánh hoạt động lâu dài của bạn. Hãy cẩn thận để chỉ hợp nhất trong các tính năng đã có, nếu không bạn sẽ gặp phải các vấn đề mà bạn hiện đang gặp phải (quá nhiều tính năng lẫn lộn trên một nhánh).

Các nhánh "Hotfix" hoặc "bugfix" là một phần thiết yếu của quy trình này; sử dụng chúng cho các bản sửa lỗi nhỏ một lần có chu kỳ QA ngắn.

Từ mô tả của bạn, có thể tốt hơn nếu không duy trì một nhánh 'phát triển' chính thức. Thay vào đó, phân nhánh tất cả các tính năng của chủ và tạo các nhánh phát hành được hợp nhất sau khi một bản phát hành được xác định.

3. Môi trường

Không ghép các nhánh git với môi trường của bạn, ngoại trừ sản xuất == master. Chi nhánh 'phát triển' nên được coi là bị hỏng. Các nhánh phát hành được đẩy đến các môi trường thử nghiệm, cho dù đó là môi trường QA hay môi trường dàn dựng. Nếu bạn cần, đẩy một nhánh tính năng cụ thể đến một môi trường.

Nếu bạn có nhiều nhánh tính năng cần được phát hành riêng lẻ nhưng đang được thử nghiệm cùng một lúc ..... \ _ (ツ) _ / ¯ .... quay lên một máy chủ khác? Có thể hợp nhất chúng lại với nhau thành một nhánh vứt đi ... cam kết sửa chữa / thay đổi cho các nhánh ban đầu và hợp nhất lại thành nhánh ném đi; làm phê duyệt cuối cùng và UAT trên các chi nhánh phát hành cá nhân.

4. Xóa các tính năng không được phê duyệt khỏi chi nhánh

Đây là những gì những suy nghĩ trên đang cố gắng tránh, bởi vì đây chắc chắn là điều đau đớn nhất để thử và làm. Nếu bạn may mắn, các tính năng đã được hợp nhất vào các nhánh phát triển hoặc thử nghiệm của bạn bằng cách sử dụng các cam kết hợp nhất. Nếu bạn không may mắn, các nhà phát triển đã cam kết trực tiếp với nhánh phát triển / thử nghiệm.

Dù bằng cách nào, nếu bạn đang chuẩn bị phát hành và có những thay đổi không được chấp thuận, bạn sẽ cần sử dụng Git để sao lưu những cam kết không được chấp thuận từ chi nhánh phát hành; ý tưởng tốt nhất là làm điều đó trước khi thử nghiệm bản phát hành.

May mắn nhất.

Đây là một ý tưởng, Ngừng sử dụng các nhánh phát hành. Thay vào đó, hãy bắt đầu xây dựng tính năng bật và quản lý nó thông qua cấu hình. Bằng cách đó, bạn luôn kết hợp các nhánh tính năng thành chủ và không bao giờ có câu hỏi về phiên bản thử nghiệm hoặc sản phẩm nào. Nếu bạn có câu hỏi về những tính năng / triển khai nào đang hoạt động trong một môi trường, chỉ cần kiểm tra tệp cấu hình.

Đây phải là một vấn đề đơn giản của sự phối hợp giữa thử nghiệm và sản xuất. Nếu bạn đang sử dụng các nhánh tính năng trong Git, chỉ cần dừng đẩy các nhánh tính năng đã hoàn thành để Kiểm tra trong một chu kỳ thử nghiệm và tiếp tục khi thử nghiệm hoàn tất.

Nếu bạn cần kiểm soát tốt hơn điều này, hãy tách Kiểm tra thành máy chủ Phát triển và Máy chủ Kiểm tra chấp nhận và phối hợp các nhánh đó sẽ được đẩy đến máy chủ Kiểm tra chấp nhận với nhóm kiểm tra. Ai đó sau đó có thể chịu trách nhiệm khởi động triển khai cuối cùng từ Thử nghiệm chấp nhận đến Sản xuất.

Công việc chồng chất

Đây là một vấn đề phổ quát trong kinh nghiệm của tôi. Tôi giải quyết nó với:

• Quản lý mạnh mẽ các bản phát hành tính năng của chủ sở hữu sản phẩm
• Đảm bảo rằng các nhánh được xóa khi chúng được hợp nhất
• Giới hạn công việc đang tiến hành (với giới hạn cột trong Jira)
• Đánh giá hàng quý về vé cũ đang mòn mỏi, cả lỗi và tính năng
• Hồi tưởng để thảo luận về các thành phần của vấn đề
• Khuyến khích liên tục cho tất cả các đánh giá mã
• Ghép nối các cơ hội để giải quyết các vấn đề và vé lâu dài
• Các cuộc họp hàng quý để xem xét và làm sạch vé cũ lên
• Cách tiếp cận nhóm để có được dev, sản phẩm và QA / QE phối hợp chặt chẽ với nhau
• Báo cáo tốt và các công cụ để làm cho các tính năng sản phẩm mới và tồn đọng rõ ràng
• Xem lại các phiên để đi qua các chi nhánh cũ và xóa chúng

Chi nhánh

Bạn cần một số chi nhánh để kiểm soát quá trình đó:

• tính năng : chi nhánh này được sinh ra từ chủ. Sử dụng một số ứng dụng quản lý dự án để xác định từng nhánh tính năng với một số nhiệm vụ. Ví dụ, nếu bạn sử dụng TRAC, bạn sẽ kết thúc nếu các nhánh như: 1234-user-crud,, 1235-bug-delete-catalogv.v. Xác định các cam kết của bạn với số nhiệm vụ, điều này sẽ giúp bạn rất nhiều khi bạn gặp vấn đề trong việc hợp nhất (bạn sẽ).
• kiểm tra : tất cả các nhánh tính năng được thực hiện sẽ được hợp nhất với nhánh thử nghiệm. Bạn không bao giờ hợp nhất nhánh thử nghiệm vào một số nhánh tính năng , bởi vì bạn không muốn mã từ các tính năng khác không có trong sản xuất (chính). Điều tương tự là hợp lệ cho các releasechi nhánh.
• phát hành : khi bạn quyết định các tính năng được thử nghiệm có thể có trong sản xuất, bạn hợp nhất các nhánh này (một lần nữa ...) trong nhánh này. Bạn cần kiểm tra lại tất cả các tính năng, bởi vì sự hợp nhất này có thể mang đến những vấn đề mới. Khi bản phát hành được kiểm tra và thực hiện, bạn hợp nhất nhánh này thành chủ và tạo thẻ trên bản chính cho phiên bản.
• master : chỉ chứa mã sản xuất.

Xem luồng git:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Môi trường

Rất đơn giản:

• kiểm tra : môi trường này sử dụng nhánh thử nghiệm.
• phát hành : môi trường này sử dụng nhánh phát hành thực tế.

Các nhà phát triển làm việc trong máy của anh ta, mỗi người sử dụng cơ sở dữ liệu của riêng mình. Nếu mỗi nhà phát triển không thể có một cơ sở dữ liệu riêng lẻ (vì giấy phép, kích thước của cơ sở dữ liệu, v.v.), bạn sẽ gặp rất nhiều vấn đề khi chia sẻ cơ sở dữ liệu giữa các nhà phát triển: khi ai đó xóa một cột hoặc một bảng trong nhánh của mình, các cột khác các nhánh vẫn được tính với cột / bảng này trong cơ sở dữ liệu.

Các vấn đề

Vấn đề lớn nhất trong quá trình này là sự hợp nhất.

Bạn cần phải làm lại sự hợp nhất tương tự trong testvà release. Điều này sẽ gây đau khổ nếu một số bộ tái cấu trúc tốt được tạo trong mã, như xóa một lớp, di chuyển / đổi tên phương thức, v.v. Vì bạn không thể lấy mã từ test(hoặc release) nhánh thành nhánh tính năng, các cam kết hợp nhất chỉ có thể được giải quyết trong các test(hoặc release). Vì vậy, cuối cùng bạn sẽ giải quyết các xung đột giống nhau ở hai nhánh khác nhau, có thể tạo ra các mã khác nhau trong mỗi hợp nhất và trong tương lai, bạn sẽ phát hiện ra rằng nhóm thử nghiệm sẽ cần kiểm tra các tính năng hai lần: trong các nhánh testvà releasebởi vì mỗi hợp nhất có thể dẫn đến các lỗi khác nhau.

Một vấn đề khác là testchi nhánh. Thỉnh masterthoảng bạn sẽ cần "tái chế" nhánh này (xóa và tạo một nhánh mới ), bởi vì một số nhánh cũ (hoặc sáp nhập cũ, các nhánh bị sáp nhập đã bị xóa) có thể gây ra nhiều vấn đề cho mã mới, chuyển hướng nhiều từ những gì trong master. Trong thời điểm này, bạn cần kiểm soát những nhánh nào bạn muốn hợp nhất lại trong test.

Giải pháp thực sự tốt nhất là nhóm kinh doanh biết những gì cần được cung cấp trong phiên bản tiếp theo và mọi người làm việc trong một chi nhánh duy nhất (phát triển chi nhánh). Thật tốt cho họ khả năng chọn tính năng "thực hiện" mà họ muốn có trong phiên bản tiếp theo bất cứ lúc nào họ muốn (tôi nghĩ đây là kịch bản của bạn), nhưng đây là cơn ác mộng đối với các nhà phát triển và (tôi tin) cho đội kiểm tra.

Âm thanh như bạn đang hợp nhất các thay đổi từ nhánh tích hợp của bạn vào nhánh sản xuất của bạn, mà IMHO không phải là một thực tiễn tốt, chính xác là vì những lý do bạn đề cập. Ngay khi một nhánh sản xuất cho một bản phát hành nhất định được rút ra từ nhánh tích hợp chính, thì nhánh tích hợp có thể, bất cứ lúc nào, phân kỳ (sau tất cả, nó được cho là sẽ phát triển thành bản phát hành tiếp theo). Hợp nhất từ ​​nhánh tích hợp vào nhánh phát hành hiện tại có thể mang lại những thay đổi không tương thích với bản phát hành đó.

IMHO một quy trình thích hợp sẽ là:

• chỉ kéo một nhánh sản xuất khỏi nhánh tích hợp khi nó được coi là đủ gần với mức chất lượng mong muốn, do đó chỉ một số thay đổi được mong đợi sẽ hoàn thành việc phát hành. Nói cách khác, hoàn thành tính năng nên được đánh giá (liên tục) trên nhánh tích hợp, trước khi kéo nhánh sản xuất.
• sau khi nhánh sản xuất được kéo, chỉ có các thay đổi được chọn bằng cherry, được coi là thay đổi độc lập / sửa điểm - tức là đã xác minh rằng chúng thực sự hoạt động như mong đợi (chỉ vì một thay đổi hoạt động trong một nhánh không nhất thiết có nghĩa là nó cũng hoạt động ở một chi nhánh khác).

Cá nhân, điều này có vẻ như nó có thể là một vấn đề quá trình hơn là một vấn đề công cụ. Một vài điều tôi muốn đề xuất ở đây:

• Tôi không chắc nếu bạn có các nhóm Dev và QA riêng biệt. Nếu bạn làm như vậy, hãy chắc chắn rằng cả Dev và QA đều tham gia vào các cuộc họp lập kế hoạch và dự toán nước rút. Tại một trong những công ty trước đây của tôi, chúng tôi đã đảm bảo rằng số điểm câu chuyện mà chúng tôi đã chỉ định một câu chuyện chiếm cả nỗ lực phát triển và thử nghiệm. (Về mặt lý thuyết bạn cũng có thể có hai ước tính riêng cho nỗ lực dev và QA, nhưng theo cách bạn cần để ước tính của mình bao gồm cả hai; thời gian cần thiết cho một câu chuyện là thời gian cần thiết để thực sự cung cấp nó). Ngay cả khi bạn không có nhóm QA riêng biệt, vẫn đảm bảo bạn bao gồm nỗ lực kiểm tra trong các ước tính của mình.
• Cùng một tĩnh mạch tương tự như trên, đồng ý trước về số lượng câu chuyện bạn sẽ đưa vào một lần chạy nước rút cụ thể. Số lượng điểm câu chuyện bạn chấp nhận dựa trên số lượng nhà phát triển của bạn có thể hoàn thành trong lần chạy nước rút của họ và số lượng vật phẩm mà QA có thể kiểm tra trong lần chạy nước rút của họ. (Tất nhiên, tôi cho rằng nước rút QA đứng sau nước rút Dev, nhưng bạn có thể điều chỉnh quy trình này cho quy trình của mình). Nếu nhà phát triển của bạn có thể hoàn thành 200 điểm câu chuyện nhưng QA của bạn chỉ có thể hoàn thành 150 điểm câu chuyện, rõ ràng bạn chỉ có thể thực hiện 150 điểm câu chuyện trước khi công việc bắt đầu "chồng chất" và bạn kết thúc với một trường hợp như những gì bạn mô tả. (Trong trường hợp như thế này, bạn có thể muốn điều tra nguyên nhân của rào cản để cố gắng giảm thiểu nó).
• Không ai đẩy bất cứ điều gì đến QA cho đến khi mọi thứ hiện tại trong QA được kiểm tra và chuyển giao .
• Một tính năng hoàn chỉnh là một trong những gì đã được thử nghiệm và phân phối. Nếu nó không được giao thì không được.
• Rõ ràng, bạn muốn thử làm điều này trên một loại lịch trình cố định. Một trong những ý tưởng đằng sau Tích hợp liên tục và Agile là phép lặp. Theo định nghĩa, lặp đi lặp lại đòi hỏi giao hàng thường xuyên. Tích hợp thường xuyên và giao hàng giảm thiểu rủi ro của mỗi người.

Thành thật mà nói, tôi nghĩ điều quan trọng nhất sẽ là kỷ luật khi bạn giao hàng và có bao nhiêu nhiệm vụ bạn thực sự có thể hoàn thành trong một khung thời gian nhất định.

Tóm lại: chỉ cung cấp cho QA khi bạn hoàn thành thử nghiệm và cung cấp các tính năng cũ.

Khi "mọi thứ đã được kiểm tra và phê duyệt", hãy triển khai những gì đã được thử nghiệm và phê duyệt để sản xuất. Đó có thể là một cam kết cụ thể hoặc nó có thể là một vật phẩm xây dựng cụ thể được tạo bởi Jenkins.

Nó không phải là vấn đề mà sau đó cam kết trên cùng một chi nhánh chưa được thử nghiệm.