Chiến lược đối phó với các thử nghiệm A / B và Gitflow


8

Tôi muốn biết những chiến lược nào bạn sử dụng để đối phó với các thử nghiệm A / B của ứng dụng và gitflow của bạn.

Tổng quat:

Chúng tôi là một nhóm gồm 6 lập trình viên phát triển và duy trì một Ứng dụng lớn. Cho đến nay chúng tôi đã làm việc trên gitflow với một vài tiện ích bổ sung cho quy trình được thêm vào bởi chúng tôi hoạt động hoàn hảo trong một vài năm. Theo cách đơn giản, chúng tôi sử dụng:

  • thạc sĩ ngành (chỉ mã của phiên bản được xuất bản)
  • phát hành chi nhánh hợp nhất trong tổng thể sau khi kiểm tra dự phòng cuối cùng
  • hotfix chỉ tương tác với nhánh chính trong trường hợp cực đoan
  • phát triển tích lũy các mô-đun đã phát triển khi chúng được hoàn thành và thử nghiệm, cuối cùng hợp nhất thành phát hành.
  • / tính năng là một nhóm các tính năng phân nhánh phát triển và một khi chúng được hoàn thành và vượt qua các giai đoạn thử nghiệm khác nhau, hợp nhất trở lại để phát triển thêm chức năng
  • / fix_develop là một nhóm các tính năng có chứa các bản sửa lỗi cho các lỗi gặp phải từ các phiên bản trước đó không quá khẩn cấp để bắt đầu một hotfix.

Bây giờ, khi ứng dụng phát triển, với nhóm UX và các nhóm bên liên quan khác, chúng tôi đang áp dụng chiến lược thử nghiệm A / B mạnh mẽ hơn, nơi các bản phát hành mới sẽ có 2 phiên bản và dựa trên cách người dùng của chúng tôi thích một phiên bản hoặc phiên bản kia sẽ trở thành chủ nhân cuối cùng phiên bản miễn là chúng có ý nghĩa đối với người dùng của chúng tôi.

Đã giải thích điều đó, câu hỏi là : Những chiến lược nào bạn đã sử dụng hoặc đề xuất để quản lý mã của các phiên bản thử nghiệm A / B trong gitflow?

Các tùy chọn mà tôi đã xem xét không nhất quán bằng cách nào đó, ví dụ: phân nhánh nhánh A và B từ chủ và sau đó nối nhánh phát hành này sang nhánh khác, trong đó tôi không biết cách xử lý tách mã có chứa từ nhánh phát hành để làm nổi bật chi nhánh. Một tùy chọn khác là tạo các nhánh A và B phát hành và phát triển các nhánh A và B nghe có vẻ như quá nhiều nhánh và gây nhầm lẫn cho các đồng đội của tôi.

Tôi nghe ý kiến ​​của bạn, cảm ơn!

Cập nhật: Ứng dụng chúng tôi phát triển là Ứng dụng Android và chúng tôi đang triển khai thử nghiệm A / B bằng nền tảng PlayStore để thử nghiệm A / B, yêu cầu tạo hai APK và tải lên một trong số chúng với tỷ lệ%. Ngoài ra để giữ mọi thứ đơn giản hơn và vì các thay đổi đôi khi có thể lớn hơn chỉ là vị trí nút, chúng tôi đã quyết định không thêm công tắc riêng cho thử nghiệm A và B trong một APK duy nhất.


Không phải chúng chỉ đơn giản là tính năng chi nhánh?
Robert Harvey

1
điều là các nhánh này sẽ đi đến cửa hàng, vì vậy sẽ phải phá vỡ tất cả các giao thức thử nghiệm nếu tôi chỉ tải lên mã từ các nhánh tính năng. bạn nghĩ sao?
alexm

Bạn sẽ trải qua toàn bộ quá trình kiểm tra cho một chi nhánh có thể không bao giờ trở thành một sản phẩm thực tế? Điều đó không thực sự tăng gấp đôi công việc của bạn?
Robert Harvey

Dù sao đây chỉ là cách tôi nhìn thấy bây giờ, ý tưởng của tôi với bài viết là tìm hiểu cách người khác giải quyết vấn đề này và áp dụng những gì tôi nghĩ sẽ có ý nghĩa với chúng tôi
alexm

nó làm tăng gấp đôi công việc, nhưng có những điều thiết yếu chúng ta cần kiểm tra và chứng minh nếu chúng hoạt động cho người dùng của chúng tôi khá phức tạp, thì tất cả đều được thực hiện để phóng to phần dưới của fanel hoạt động của chúng tôi, vì vậy nó rất nhiều công việc, nhưng có ý nghĩa để kiểm tra
alexm

Câu trả lời:


11

Cách tôi luôn thấy nó được thực hiện là có một cơ sở mã duy nhất có khả năng phục vụ cả hai trang / lượt xem / biểu mẫu.

I E. Tính năng của nó được gắn cờ và triển khai với hai hoặc nhiều cấu hình hoặc 'chính người dùng có được phương thức A hoặc B' là một phần của ứng dụng.

Trong trường hợp này, bạn chỉ có một phiên bản mã, vì vậy kiểm soát nguồn của bạn không hoạt động.

Điều này là tốt hơn nhiều so với việc thay thế giữ nhiều phiên bản của cơ sở mã với các tính năng khác nhau. Chúng có xu hướng phân kỳ rất nhanh và cuối cùng bạn phải thực hiện các tính năng tương tự nhiều lần.

Nói chung, tôi sẽ cẩn thận và hạn chế phạm vi khác biệt A và B có thể có cả hai để chúng có thể được cắm vào một phương thức chuyển đổi chung (ví dụ xem A hoặc xem B) và để bạn có thể hiểu lý do cho bất kỳ số liệu thống kê khác nhau nào bạn ra khỏi thử nghiệm của bạn. ví dụ: sự gia tăng doanh số được liên kết với màu nút hoặc công thức định giá?

Biên tập. để làm rõ ứng dụng

Bạn vẫn có thể có các cờ tính năng trong ứng dụng cửa hàng chơi và đóng gói cơ sở mã vào nhiều hơn một apk.


3
Vâng, đây là những gì tôi sẽ đề xuất: gắn cờ tính năng. Vấn đề duy nhất với nó là nó làm tăng sự phức tạp của phần mềm của bạn, trừ khi bạn có ý định loại bỏ (các) tính năng (không sử dụng) trong bản phát hành tiếp theo.
Robert Harvey

1
vâng, tôi thường không ủng hộ cờ tính năng, nhưng đây là cách tôi đã thực hiện và thấy nó được thực hiện. Tôi chắc rằng tất cả chúng ta đều đã thấy sự khủng khiếp mà bạn có thể có khi có nhiều phiên bản trực tiếp của cùng một sản phẩm trong các chi nhánh. Vì vậy, tôi tự nhiên sẽ né tránh cách tiếp cận đó.
Ewan

2
bạn vẫn có thể có các cài đặt cấu hình và nhận hai apks từ cùng một cơ sở mã. Chắc chắn ứng dụng của bạn sẽ lớn hơn, nhưng .... việc duy trì nhiều cơ sở mã là thách thức để nói rằng ít nhất
Ewan

2
chắc chắn dòng chảy đó có thể được trừu tượng hóa thành một khung nhìn
Ewan

1
Vâng, đối với một nhóm phát triển doanh nghiệp, tôi sẽ đề nghị như vậy. Đối với tôi, trong một môi trường phát triển doanh nghiệp cam kết mạnh mẽ, dòng phát triển cơ sở thân cây dễ dàng hơn nhiều. Kiểm tra tại đây: trunkbaseddevelopment.com . Sam Newman đã có một cuộc nói chuyện thú vị về việc chuyển đổi tính năng trong youtube: youtube.com/watch?v=lqRQYEHAtpk .
ivenxu

1

Tôi đồng ý với @Ewan rằng cờ tính năng là con đường để đi. Bằng cách đó, bạn có thể thêm một cái gì đó trong quá trình xây dựng sẽ triển khai APK cho thử nghiệm A hoặc thử nghiệm B. Nhưng nếu muốn một ý tưởng không sử dụng cờ tính năng, thì đây là một ý tưởng mà tôi chưa thử.

Bạn có thể kéo mã chung ra một thư viện riêng trong một kho lưu trữ riêng. Sau đó, mỗi phiên bản thử nghiệm có kho lưu trữ riêng với nhánh gitflow và master chính có thể được triển khai.

Điều này sẽ mất nhiều nỗ lực hơn vào lúc đầu vì tất cả các mã phổ biến sẽ phải được rút ra (các) thư viện sau đó được tham chiếu trong kho lưu trữ. Nhưng sau khi thiết lập ban đầu, tôi tin rằng điều này có thể hợp lý hóa việc phát triển các tính năng mới vào thử nghiệm A / B.

** Một lần nữa, đây chỉ là một ý tưởng và không phải là điều mà tôi đã làm cá nhân.


Đúng vậy, chúng tôi có một thư viện với chức năng chính (C ++) và sau đó là Ứng dụng tiêu dùng (Android và iOS) chỉ đóng vai trò là nhà triển khai giao diện và dịch vụ, những gì chúng tôi đang thay đổi chỉ là cách ứng dụng được trình bày cho người dùng, vì vậy, có, nó sẽ hoạt động cho các thử nghiệm A / B trong Android. Tuy nhiên, tôi đang tìm cách để mã tập trung trong một kho lưu trữ, vì vậy tôi đang tìm kiếm một chiến lược gitflow ở giữa: "sao chép tất cả các nhánh cho A và B" và "chỉ có một tính năng A và B hoặc nhánh thông thường có nghĩa là một repo bẩn ".
alexm

0

Vì ứng dụng của bạn đã chạy và có một số người dùng, tôi đề xuất một trong các tùy chọn sau:

  • Tôi thực sự khuyên bạn nên suy nghĩ thiết kế trước khi thực hiện một tính năng lớn mới;
  • Nếu bạn vẫn cần thực hiện kiểm tra A / B, tôi khuyên bạn nên tiếp tục với gitflow bình thường và có nhánh Anhánh B ;

Kiểm soát nguồn

Xem xét thử nghiệm A / B, điều tôi muốn làm rõ là:

  • Chi nhánh : chứa mã liên quan đến Phiên bản của ứng dụng. EG: A_HomeActivity, A_SinstallActivity, v.v.
  • Nhánh B : chứa mã liên quan đến phiên bản B của ứng dụng. EG: B_HomeActivity, B_SinstallActivity, v.v.

Từ thời điểm này, bạn có thể sử dụng 2 chiến lược:

  • Tạo hai phiên bản hoàn toàn khác nhau: A.apkB.apk ; hoặc là
  • Làm cho nhánh B cũng chứa mã từ nhánh A và cung cấp một ứng dụng có khả năng sử dụng hai luồng . Người dùng chỉ tải xuống một ứng dụng và có tùy chọn bật luồng mới cho mục đích đánh giá. Tôi đã thấy một cái gì đó như thế này được thực hiện bởi Bitbucket , trên đó một điều hướng hoàn toàn mới có sẵn cho một số người dùng để đánh giá; sau một thời gian điều hướng mới này đã trở thành điều hướng mặc định.

Dù bằng cách nào, sau khi thử nghiệm, bạn chỉ cần xóa mã cho tính năng / luồng lỗi thời.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.