Chiến lược phân nhánh Git tích hợp với quá trình thử nghiệm / QA

Nhóm phát triển của chúng tôi đã sử dụng chiến lược phân nhánh GitFlow và nó thật tuyệt!

Gần đây, chúng tôi đã tuyển dụng một vài người thử nghiệm để cải thiện chất lượng phần mềm của chúng tôi. Ý tưởng là mọi tính năng nên được kiểm tra / QA bởi người kiểm tra.

Trước đây, các nhà phát triển làm việc trên các tính năng trên các nhánh tính năng riêng biệt và hợp nhất chúng trở lại developnhánh khi hoàn thành. Nhà phát triển sẽ tự kiểm tra công việc của mình trên featurechi nhánh đó . Bây giờ với người kiểm tra, chúng tôi bắt đầu hỏi Câu hỏi này

Người kiểm tra nên thử nghiệm tính năng mới trên nhánh nào?

Rõ ràng, có hai lựa chọn:

• trên nhánh tính năng cá nhân
• trên developcành

Thử nghiệm trên chi nhánh phát triển

Ban đầu, chúng tôi tin rằng đây là cách chắc chắn để đi vì:

• Tính năng này được thử nghiệm với tất cả các tính năng khác được hợp nhất với developchi nhánh kể từ khi quá trình phát triển bắt đầu.
• Bất kỳ xung đột có thể được phát hiện sớm hơn sau đó
• Nó làm cho công việc của người kiểm tra trở nên dễ dàng, anh ta chỉ giao dịch với một chi nhánh ( develop) mọi lúc. Anh ta không cần hỏi nhà phát triển về chi nhánh nào dành cho tính năng nào (chi nhánh tính năng là các chi nhánh cá nhân được quản lý độc quyền và tự do bởi các nhà phát triển có liên quan)

Vấn đề lớn nhất với điều này là:

• Các develop chi nhánh bị ô nhiễm với lỗi.

  Khi người kiểm tra tìm thấy lỗi hoặc xung đột, anh ta báo cáo lại cho nhà phát triển, người đã khắc phục sự cố trên nhánh phát triển (nhánh tính năng đã bị hủy bỏ sau khi sáp nhập) và sau đó có thể có nhiều sửa chữa hơn. Nhiều lần cam kết hoặc hợp nhất (nếu một nhánh được tạo lại từ developnhánh một lần nữa để sửa lỗi) khiến việc khôi phục tính năng từ developnhánh trở nên rất khó khăn nếu có thể. Có nhiều tính năng hợp nhất và được cố định trên developnhánh tại các thời điểm khác nhau. Điều này tạo ra một vấn đề lớn khi chúng tôi muốn tạo một bản phát hành chỉ với một số tính năng trong developnhánh

Kiểm tra trên nhánh tính năng

Vì vậy, chúng tôi đã suy nghĩ lại và quyết định chúng tôi nên thử nghiệm các tính năng trên các nhánh tính năng. Trước khi kiểm tra, chúng tôi hợp nhất các thay đổi từ developnhánh sang nhánh tính năng (bắt kịp với developnhánh). Điều này là tốt:

• Bạn vẫn kiểm tra tính năng này với các tính năng khác trong dòng chính
• Phát triển hơn nữa (ví dụ sửa lỗi, giải quyết xung đột) sẽ không gây ô nhiễm cho developchi nhánh;
• Bạn có thể dễ dàng quyết định không phát hành tính năng này cho đến khi nó được kiểm tra và phê duyệt đầy đủ;

Tuy nhiên, có một số nhược điểm

• Người kiểm tra phải thực hiện việc hợp nhất mã và nếu có bất kỳ xung đột nào (rất có thể), anh ta phải yêu cầu nhà phát triển giúp đỡ. Người kiểm tra của chúng tôi chuyên kiểm tra và không có khả năng mã hóa.
• một tính năng có thể được kiểm tra mà không có sự tồn tại của một tính năng mới khác. ví dụ: Tính năng A và B đều đang được thử nghiệm cùng một lúc, hai tính năng này không biết về nhau vì cả hai tính năng này chưa được hợp nhất với developchi nhánh. Điều này có nghĩa là bạn sẽ phải kiểm tra lại developchi nhánh một lần nữa khi cả hai tính năng được hợp nhất với nhánh phát triển. Và bạn phải nhớ kiểm tra điều này trong tương lai.
• Nếu Tính năng A và B đều được kiểm tra và phê duyệt, nhưng khi sáp nhập được xác định, cả hai nhà phát triển cho cả hai tính năng đều tin rằng đó không phải là lỗi / công việc của riêng mình vì nhánh tính năng của anh ta vượt qua thử nghiệm. Có một chi phí phụ trong giao tiếp, và đôi khi bất cứ ai giải quyết xung đột đều cảm thấy thất vọng.

Trên đây là câu chuyện của chúng tôi. Với nguồn lực hạn chế, tôi muốn tránh thử nghiệm mọi thứ ở mọi nơi. Chúng tôi vẫn đang tìm kiếm một cách tốt hơn để đối phó với điều này. Tôi rất thích nghe cách các đội khác xử lý loại tình huống này.

Cách chúng tôi làm như sau:

Chúng tôi kiểm tra các nhánh tính năng sau khi chúng tôi hợp nhất mã nhánh phát triển mới nhất trên chúng. Lý do chính là chúng tôi không muốn "gây ô nhiễm" phát triển mã chi nhánh trước khi một tính năng được chấp nhận. Trong trường hợp một tính năng sẽ không được chấp nhận sau khi thử nghiệm nhưng chúng tôi muốn phát hành các tính năng khác đã được hợp nhất để phát triển sẽ là địa ngục. Phát triển là một nhánh mà từ đó một bản phát hành được thực hiện và do đó tốt hơn nên ở trạng thái đáng tin cậy. Phiên bản dài là chúng tôi thử nghiệm trong nhiều giai đoạn. Phân tích kỹ hơn:

1. Nhà phát triển tạo một nhánh tính năng cho mọi tính năng mới.
2. Nhánh tính năng được (tự động) triển khai trên môi trường TEST của chúng tôi với mọi cam kết để nhà phát triển kiểm tra.
3. Khi nhà phát triển hoàn thành việc triển khai và tính năng đã sẵn sàng để được thử nghiệm, anh ta hợp nhất nhánh phát triển trên nhánh tính năng và triển khai nhánh tính năng chứa tất cả các thay đổi phát triển mới nhất trên TEST.
4. Người kiểm tra kiểm tra trên TEST. Khi hoàn thành, anh ta "chấp nhận" câu chuyện và hợp nhất nhánh tính năng đang phát triển. Do nhà phát triển trước đó đã sáp nhập nhánh phát triển trên tính năng, chúng tôi thường không mong đợi quá nhiều xung đột. Tuy nhiên, nếu đó là trường hợp nhà phát triển có thể giúp đỡ. Đây là một bước khó khăn, tôi nghĩ cách tốt nhất để tránh nó là giữ các tính năng nhỏ / cụ thể nhất có thể. Các tính năng khác nhau cuối cùng phải được hợp nhất, bằng cách này hay cách khác. Tất nhiên quy mô của đội đóng vai trò trong sự phức tạp của bước này.
5. Chi nhánh phát triển cũng (tự động) được triển khai trên TEST. Chúng tôi có một chính sách rằng mặc dù các tính năng xây dựng nhánh có thể thất bại nhưng nhánh phát triển không bao giờ thất bại.
6. Khi chúng tôi đã đạt đến một tính năng đóng băng, chúng tôi tạo một bản phát hành từ phát triển. Điều này được tự động triển khai trên STAGING. Các thử nghiệm mở rộng từ đầu đến cuối diễn ra ở đó trước khi triển khai sản xuất. (ok có thể tôi phóng đại một chút họ không rộng lắm nhưng tôi nghĩ họ nên như vậy). Lý tưởng nhất là người thử nghiệm / đồng nghiệp beta, tức là người dùng thực sự nên thử nghiệm ở đó.

Bạn nghĩ gì về phương pháp này?

Trước khi thử nghiệm, chúng tôi hợp nhất các thay đổi từ nhánh phát triển sang nhánh tính năng

Không. Đừng, đặc biệt nếu "chúng tôi" là người kiểm tra QA. Việc hợp nhất sẽ liên quan đến việc giải quyết các xung đột tiềm năng, được thực hiện tốt nhất bởi các nhà phát triển (họ biết mã của họ) chứ không phải bởi người kiểm tra QA (người nên tiến hành kiểm tra càng nhanh càng tốt).

Làm cho nhà phát triển thực hiện một cuộc nổi loạn của featurechi nhánh của anh ấy / cô ấydevel và đẩy featurechi nhánh đó (đã được nhà phát triển xác nhận là biên dịch và làm việc trên đỉnh của develtrạng thái chi nhánh gần đây nhất ).
Điều đó cho phép:

• một tích hợp rất đơn giản trên nhánh tính năng (hợp nhất chuyển tiếp nhanh tầm thường).
• hoặc, theo khuyến nghị của Aspasia bên dưới trong các nhận xét , yêu cầu kéo (GitHub) hoặc yêu cầu hợp nhất (GitLab) : người duy trì thực hiện hợp nhất giữa nhánh PR / MR tính năng và develop, nhưng chỉ khi GitHub / GitLab không phát hiện xung đột.

Mỗi lần kiểm tra phát hiện lỗi, anh / cô ấy sẽ báo cáo cho nhà phát triển và xóa nhánh tính năng hiện tại.
Nhà phát triển có thể:

• sửa lỗi
• rebase trên đỉnh của một nhánh phát triển được tìm nạp gần đây (một lần nữa, để chắc chắn rằng mã của anh ấy / cô ấy hoạt động tích hợp với các tính năng được xác thực khác)
• đẩy featurecành cây.

Ý tưởng chung: đảm bảo phần hợp nhất / tích hợp được thực hiện bởi nhà phát triển, để lại thử nghiệm cho QA.

Cách tiếp cận tốt nhất là tích hợp liên tục , trong đó ý tưởng chung là hợp nhất các nhánh tính năng vào nhánh nhà phát triển càng thường xuyên càng tốt. Điều này làm giảm chi phí của các cơn đau sáp nhập.

Dựa vào các bài kiểm tra tự động càng nhiều càng tốt, và các bản dựng sẽ tự động khởi động với các bài kiểm tra đơn vị của Jenkins. Yêu cầu các nhà phát triển thực hiện tất cả công việc với việc hợp nhất các thay đổi của họ vào nhánh chính và cung cấp các thử nghiệm đơn vị cho tất cả mã của họ.

Người kiểm tra / QA có thể tham gia đánh giá mã, kiểm tra các bài kiểm tra đơn vị và viết các bài kiểm tra tích hợp tự động để được thêm vào bộ hồi quy khi các tính năng được hoàn thành.

Để biết thêm thông tin kiểm tra liên kết này .

Chúng tôi sử dụng cái mà chúng tôi gọi là "vàng", "bạc" và "đồng". Điều này có thể được gọi là prod, dàn dựng và qa.

Tôi đã đến để gọi đây là mô hình nồi nấu chảy. Nó hoạt động tốt cho chúng tôi bởi vì chúng tôi có nhu cầu rất lớn về QA trong lĩnh vực kinh doanh vì các yêu cầu có thể khó hiểu so với các kỹ thuật.

Khi một lỗi hoặc tính năng đã sẵn sàng để thử nghiệm, nó sẽ chuyển sang "đồng". Điều này kích hoạt một bản dựng jenkins đẩy mã đến một môi trường được xây dựng trước. Nhân viên kiểm tra của chúng tôi (không phải siêu công nghệ) chỉ cần nhấn vào một liên kết và không quan tâm đến việc kiểm soát nguồn. Bản dựng này cũng chạy thử nghiệm, v.v. Chúng tôi đã quay đi quay lại bản dựng này thực sự đẩy mã đến môi trường \ qa thử nghiệm nếu các thử nghiệm (đơn vị, tích hợp, selen) không thành công. Nếu bạn kiểm tra trên một hệ thống riêng biệt (chúng tôi gọi là khách hàng tiềm năng), bạn có thể ngăn những thay đổi bị đẩy vào môi trường qa của mình.

Nỗi sợ hãi ban đầu là chúng ta sẽ có nhiều xung đột giữa các tính năng này. Nó đã xảy ra là tính năng X làm cho nó có vẻ như tính năng Y bị phá vỡ, nhưng nó không đủ thường xuyên và thực sự có ích. Nó giúp có được một loạt các thử nghiệm bên ngoài những gì dường như là bối cảnh của sự thay đổi. Nhiều lần may mắn, bạn sẽ tìm ra cách thay đổi của bạn ảnh hưởng đến sự phát triển song song.

Khi một tính năng vượt qua QA, chúng tôi chuyển nó thành "bạc" hoặc dàn dựng. Một bản dựng được chạy và các bài kiểm tra được chạy lại. Hàng tuần, chúng tôi đẩy những thay đổi này đến cây "vàng" hoặc cây prod và sau đó triển khai chúng vào hệ thống sản xuất của chúng tôi.

Các nhà phát triển bắt đầu thay đổi của họ từ cây vàng. Về mặt kỹ thuật, bạn có thể bắt đầu từ việc dàn dựng vì những thứ đó sẽ tăng lên sớm.

Sửa chữa khẩn cấp được cắm trực tiếp vào cây vàng. Nếu một thay đổi là đơn giản và khó đối với QA, nó có thể chuyển trực tiếp thành bạc, nó sẽ tìm đường đến cây thử nghiệm.

Sau khi phát hành, chúng tôi đẩy các thay đổi bằng vàng (prod) sang đồng (thử nghiệm) chỉ để giữ mọi thứ đồng bộ.

Bạn có thể muốn rebase trước khi đẩy vào thư mục dàn của bạn. Chúng tôi đã phát hiện ra rằng việc thanh trừng cây thử nghiệm theo thời gian sẽ giữ cho nó sạch sẽ. Đôi khi các tính năng bị bỏ rơi trong cây thử nghiệm đặc biệt là nếu nhà phát triển rời đi.

Đối với các tính năng đa nhà phát triển lớn, chúng tôi tạo một repo chia sẻ riêng, nhưng hợp nhất nó vào cây thử nghiệm giống nhau khi tất cả chúng ta đã sẵn sàng. Mọi thứ phải có xu hướng thoát khỏi QA, vì vậy điều quan trọng là phải giữ các bộ thay đổi của bạn để bạn có thể thêm vào và sau đó hợp nhất / ép vào cây dàn của bạn.

"Nướng" cũng là một tác dụng phụ tốt đẹp. Nếu bạn có một số thay đổi cơ bản, bạn muốn ngồi một lúc thì có một nơi tốt đẹp cho nó.

Ngoài ra, hãy nhớ rằng chúng tôi không duy trì các bản phát hành trong quá khứ. Phiên bản hiện tại luôn là phiên bản duy nhất. Mặc dù vậy, bạn có thể có một cây nướng chính, nơi những người thử nghiệm hoặc cộng đồng của bạn có thể tìm hiểu xem các công cụ đóng góp khác nhau tương tác như thế nào.

Tôi sẽ không chỉ dựa vào kiểm tra thủ công. Tôi sẽ tự động hóa việc kiểm tra từng nhánh tính năng với Jenkins. Tôi thiết lập phòng thí nghiệm VMWare để chạy thử nghiệm Jenkins trên Linux và Windows cho tất cả các trình duyệt. Đó thực sự là một trình duyệt chéo tuyệt vời, giải pháp thử nghiệm đa nền tảng. Tôi kiểm tra chức năng / tích hợp với Selenium WebSearch. Các xét nghiệm selen của tôi chạy theo Rspec. Và tôi đã viết chúng đặc biệt để được tải bởi jRuby trên Windows. Tôi chạy thử nghiệm đơn vị truyền thống theo thử nghiệm Rspec và Javascript dưới Jasmine. Tôi thiết lập thử nghiệm không đầu với Phantom JS.

Trong công ty của chúng tôi, chúng tôi không thể sử dụng phát triển nhanh và cần phê duyệt cho mọi thay đổi của doanh nghiệp, điều này gây ra rất nhiều vấn đề.

Cách tiếp cận của chúng tôi để làm việc với GIT là thế này;

Chúng tôi đã thực hiện "Git Flow" trong công ty của chúng tôi. Chúng tôi sử dụng JIRA và chỉ những vé JIRA được phê duyệt mới được đưa vào sản xuất. Để phê duyệt thử nghiệm, chúng tôi đã mở rộng nó với một nhánh thử nghiệm được tạo riêng biệt.

Các bước để xử lý Vé JIRA là:

1. Tạo một Chi nhánh mới từ Chi nhánh phát triển
2. Thực hiện thay đổi mã trên Chi nhánh tính năng
3. Kéo từ Tính năng các Thay đổi sang Chi nhánh Kiểm tra / QA
4. Sau khi phê duyệt kinh doanh, chúng tôi kéo thay đổi từ chi nhánh tính năng sang phát triển
5. Sự phát triển diễn ra thường xuyên trong một bản phát hành và cuối cùng là nhánh chính

Việc phân tách từng yêu cầu trong một tính năng riêng đảm bảo, chỉ những thay đổi được phê duyệt mới được đưa vào sản xuất.

Quá trình hoàn chỉnh trông như thế này: