Đưa app lên cửa hàng · Project Handbook

Điều làm chặng này khác mọi chặng khác

Ở mọi chặng trước, ta sửa sai trong vài phút. Ở chặng này, giữa ta và người dùng có một bên thứ ba mà ta không điều khiển được:

	App Store	Google Play
Thời gian duyệt thường gặp	24–48 giờ	Vài giờ tới 24 giờ
Khi bị từ chối	Mất trọn vòng duyệt để nộp lại	Tương tự
Cập nhật khẩn	Có thể xin duyệt nhanh, không chắc được	Không có kênh riêng

Hệ quả trực tiếp: mọi thứ có thể kiểm tra trước khi nộp thì phải kiểm tra trước khi nộp. Đây là điểm shift left rõ nhất của chặng release — một lỗi siêu nhỏ trong phần mô tả quyền riêng tư cũng làm mất hai ngày.

Và đó cũng là lý do feature flag là bắt buộc: khi bản đã nằm trên máy người dùng, cờ là cách duy nhất còn lại để tắt một thứ đang hỏng.

Đánh số phiên bản

Dùng MAJOR.MINOR.PATCH cộng một số dựng tăng đều:

1.4.0 (238)
│ │ │   └── số dựng, tăng mỗi lần nộp, không bao giờ lặp lại
│ │ └────── sửa lỗi, không đổi hành vi
│ └──────── thêm tính năng, vẫn tương thích
└────────── thay đổi lớn, hoặc đổi cấu trúc dữ liệu không tương thích

Luật:

Số dựng không bao giờ dùng lại, kể cả cho bản bị từ chối.
Mỗi bản nộp lên cửa hàng có một tag trong git trỏ đúng commit đã dựng ra nó.
Bản dựng để nộp phải sinh ra từ CI, không phải từ máy cá nhân. Bản dựng từ máy cá nhân không tái tạo được, và không ai chứng minh được nó chứa đúng code nào.

Danh sách kiểm tra trước khi nộp

Kỹ thuật

Mục cuối là mục gây trễ nhiều nhất mà không ai ngờ tới. Đặt lịch nhắc trước hạn 60 ngày.

Nội dung trên cửa hàng

Ảnh chụp màn hình khớp với giao diện thật của bản này.
Mô tả tính năng không hứa thứ chưa có trong bản này.
Ghi chú phiên bản viết cho người dùng, không phải cho dev.
Chính sách quyền riêng tư còn truy cập được và khớp với dữ liệu app thật sự thu thập.
Khai báo loại dữ liệu thu thập đúng với thực tế — sai chỗ này là lý do bị gỡ app.
Phân loại độ tuổi phù hợp.
Có tài khoản thử cho bên duyệt, còn hoạt động, và dữ liệu mẫu đủ để họ thấy tính năng.

Mục cuối là lý do bị từ chối phổ biến nhất: người duyệt đăng nhập không được, hoặc đăng nhập được nhưng tài khoản trống rỗng nên họ không tìm thấy tính năng mô tả trong ghi chú.

Ghi chú phiên bản viết thế nào

Xấu:  Sửa lỗi và cải thiện hiệu năng.
Tốt:  - Tin nhắn gửi khi mất mạng nay tự gửi lại khi có mạng trở lại.
      - Mở danh sách đơn hàng nhanh hơn khoảng hai lần.
      - Sửa lỗi hiển thị sai hạn công việc với người dùng ở múi giờ khác.

Người dùng đọc phần này để quyết định có cập nhật hay không. "Sửa lỗi và cải thiện hiệu năng" không cho họ lý do nào.

Nộp và theo dõi

Nộp bản, ghi lại thời điểm nộp.
Chờ duyệt. Không sửa gì trên main liên quan tới bản này trong lúc chờ.
Được duyệt thì chưa mở 100% — dùng cơ chế phát hành theo tỷ lệ của cửa hàng: ngày 1 mở 5%, ngày 2 mở 20%, ngày 3 mở 50%, ngày 4 mở 100%.
Ở mỗi nấc, xem chỉ số như ở release từng phần.
Chỉ số xấu đi thì dừng mở rộng ngay trên bảng điều khiển cửa hàng, rồi tắt cờ của tính năng nghi ngờ.

Lưu ý quan trọng: dừng mở rộng chỉ ngăn người chưa cập nhật. Người đã cập nhật rồi vẫn đang chạy bản có lỗi. Vì vậy cờ vẫn là công cụ rút lui thật sự, còn tỷ lệ phát hành chỉ là công cụ giới hạn thiệt hại.

Khi bị từ chối

Đọc kỹ lý do, đừng đoán. Bên duyệt thường trích đúng điều khoản.
Ghi lý do vào một danh sách chung của đội — lý do bị từ chối có xu hướng lặp lại.
Sửa, tăng số dựng, nộp lại.
Nếu tin là bên duyệt hiểu nhầm, dùng kênh khiếu nại kèm bằng chứng cụ thể, đừng nộp lại y nguyên.

Sau mỗi lần bị từ chối, thêm một mục vào danh sách kiểm tra ở trên để lần sau không lặp lại. Danh sách này chỉ dài ra bằng những lỗi đã thật sự xảy ra.

Sau khi mở 100%

Theo dõi sát trong 48 giờ đầu: crash, lỗi mạng, phiếu hỗ trợ, đánh giá mới.
Trả lời các đánh giá 1–2 sao trong 24 giờ.
Ghi lại các con số của bản này: kích thước gói, thời gian khởi động, tỷ lệ phiên không crash — để so với bản sau.
Xoá các cờ release đã bật 100%, theo đúng hạn.