TestFlight: đưa bản thử tới người dùng thật

Trả lời nhanh: Test Flight là kênh chính thức để phát bản thử iOS tới người dùng trước khi lên cửa hàng. Hai nhóm người thử khác nhau ở chỗ quan trọng: nhóm nội bộ gồm người trong tài khoản của bạn, nhận bản mới gần như ngay lập tức; nhóm ngoài có thể lên tới hàng nghìn người nhưng bản dựng đầu tiên phải qua duyệt. Hai điều dễ vấp: mỗi bản dựng chỉ sống chín mươi ngày, và người thử phải cài ứng dụng riêng chứ không tải từ cửa hàng.

Trước khi mở cho cả thị trường, ai cũng muốn có vài chục người dùng thật bấm thử trên máy thật. Với iOS thì kênh hợp lệ duy nhất là công cụ này, và nó có vài quy tắc riêng mà người làm lần đầu hay vấp. Bài này đi qua đúng những chỗ đó.

Hai nhóm người thử

Nhóm nội bộ gồm những người đã có tài khoản trong tổ chức của bạn. Ưu điểm lớn nhất là bản dựng lên gần như ngay sau khi xử lý xong, không phải chờ duyệt. Dùng cho đội phát triển và đội kiểm thử.

Nhóm ngoài mở được cho số lượng lớn người dùng, mời bằng email hoặc bằng một đường liên kết công khai. Đổi lại, bản dựng đầu tiên phải qua một vòng duyệt, thường nhanh hơn duyệt phát hành chính thức nhưng vẫn tốn thời gian. Các bản sau đó thường qua nhanh nếu không thay đổi lớn.

Kinh nghiệm thực dụng: nộp bản dựng cho nhóm ngoài sớm hơn kế hoạch một tuần, vì vòng duyệt đầu tiên là thứ bạn không kiểm soát được thời gian.

Quy trình từ bản dựng tới tay người thử

1. Dựng bản đã ký trên máy Mac, vì khâu này bắt buộc, lý do nằm ở bài build iOS có cần Mac.
2. Tải lên, sau đó chờ hệ thống xử lý, thường vài phút tới nửa giờ.
3. Điền thông tin tuân thủ mã hóa. Bước nhỏ nhưng bắt buộc, và bản dựng nằm chờ nếu bạn quên.
4. Viết ghi chú phiên bản nói rõ lần này cần thử gì.
5. Gán bản dựng cho nhóm người thử.

Bước thứ ba là chỗ hay làm chậm cả buổi: bản dựng đã tải lên nhưng không ai nhận được, và người ta đi tìm lỗi ở chỗ khác. Có thể khai báo sẵn trong file cấu hình dự án để khỏi phải trả lời tay mỗi lần.

Toàn bộ quy trình này tự động hóa được, và đó là lý do công cụ tự động hóa phát hành rất phổ biến trong đội iOS, chủ đề của một bài riêng trong cụm này.

Hai giới hạn phải nhớ

Bản dựng hết hạn sau chín mươi ngày. Sau đó người thử mở ứng dụng sẽ bị báo hết hạn và không dùng được nữa. Với chu kỳ thử nghiệm dài, bạn phải nộp bản mới định kỳ ngay cả khi không có thay đổi đáng kể.

Người thử phải cài ứng dụng riêng của Apple. Đây là rào cản với người dùng phổ thông, nhất là khi bạn mời khách hàng doanh nghiệp thử. Hãy chuẩn bị sẵn một hướng dẫn ngắn có ảnh minh họa, nó tiết kiệm cho bạn rất nhiều tin nhắn giải thích.

Thêm một điểm nhỏ hay bị quên: nhóm ngoài có giới hạn số người, và một người dùng nhiều thiết bị vẫn tính là một. Với chương trình thử nghiệm lớn, hãy đếm trước.

Thu phản hồi cho có ích

Người thử gửi phản hồi ngay trong ứng dụng, kèm ảnh chụp màn hình và thông tin thiết bị. Đây là dữ liệu giá trị hơn hẳn tin nhắn kiểu ứng dụng bị lỗi.

Ba việc làm cho phản hồi hữu ích hơn:

• Ghi chú phiên bản nêu rõ cần thử gì. Viết lần này tập trung thử luồng thanh toán bằng thẻ nội địa sẽ nhận về phản hồi đúng chỗ, thay vì viết sửa vài lỗi.
• Hỏi câu cụ thể. Ví dụ màn hình nào khiến bạn phải dừng lại lâu nhất.
• Xem nhật ký sự cố mà hệ thống gom lại, thường lộ ra những lỗi mà không người thử nào báo vì họ chỉ đơn giản là bỏ ứng dụng.

Điểm cuối quan trọng: phần lớn người dùng gặp lỗi sẽ không báo, họ chỉ ngừng dùng. Nhật ký sự cố là cách duy nhất bạn biết về nhóm im lặng đó.

Ghép vào quy trình phát hành

Mô hình mà nhiều đội dùng:

• Mỗi lần gộp vào nhánh chính, hệ thống tự dựng và đẩy lên nhóm nội bộ. Đội có bản mới hằng ngày mà không ai phải làm gì.
• Mỗi cuối tuần hoặc mỗi mốc, đẩy một bản chọn lọc lên nhóm ngoài.
• Khi bản đó ổn định, dùng chính bản dựng đó nộp phát hành chính thức, không dựng lại.

Điểm cuối đáng nhấn: phát hành đúng bản dựng đã được thử, đừng dựng bản mới từ cùng mã nguồn. Hai lần dựng có thể khác nhau ở những chi tiết nhỏ, và bạn mất đi ý nghĩa của việc thử nghiệm.

Phần Android tương ứng nằm ở bài về Google Play Console, và cách dựng tự động cho cả hai nền tảng nằm ở bài runner cho CI mobile.

Bảng hai giới hạn của bản dựng thử

Giới hạn thứ hai hay làm hỏng kế hoạch: đội tưởng phát bản thử cho khách hàng là bấm nút xong ngay, rồi phát hiện phải chờ duyệt. Tính thời gian chờ vào lịch, và nộp bản đầu tiên sớm hơn dự kiến.

Hai nhóm người thử, dùng khác nhau

• Nhóm nội bộ: đội của bạn, phát ngay không cần duyệt. Dùng để kiểm bản dựng có chạy trên thiết bị thật không.
• Nhóm bên ngoài: khách hàng và người thử thật, cần qua duyệt lần đầu. Dùng để thu phản hồi thật.
• Đừng dùng nhóm bên ngoài cho việc kiểm bản dựng có chạy không. Đó là việc của nhóm nội bộ, và bạn không muốn chờ duyệt mỗi lần.

Ba việc làm phản hồi có ích hơn hẳn

# Ba viec lam cho phan hoi co ich hon han: # 1. Viet ghi chu ban thu ro rang: lan nay co gi moi,#    can thu ky phan nao. Khong co no thi nguoi thu chi mo ra roi dong lai. # 2. Nho nguoi thu ghi lai: may gi, ban he dieu hanh nao,#    lam gi truoc khi loi xay ra. Ba thong tin nay quyet dinh#    ban co tai hien duoc loi hay khong. # 3. Gan cong cu ghi nhan su co vao ban thu,#    de co nhat ky loi tu dong thay vi chi co mo ta bang loi # Doc bao cao su co sau moi dot thu, truoc khi nop ban chinh thuc

Tự động dựng và nộp sau mỗi lần ghép mã

1. Bản dựng tự động sau mỗi lần ghép mã vào nhánh chính.
2. Tự động nộp lên nhóm nội bộ, đội kiểm ngay trong ngày.
3. Mỗi tuần hoặc mỗi đợt tính năng, phát cho nhóm bên ngoài.
4. Thu phản hồi, sửa, rồi mới nộp bản chính thức.

Về phần dựng tự động, xem bài về máy chạy tác vụ tự dựng.