Home Check list release ứng dụng
Post
Cancel

Check list release ứng dụng

Dưới đây là các công việc cần chuẩn bị khi release một phiên bản ứng dụng nhằm đảm bảo phiên bản được ổn định, dễ kiểm soát.

Chuẩn bị

Trước khi release, cần trả lời một số câu hỏi sau nhằm đảm bảo bạn nắm được những sự thay đổi về mặt tính năng và mục đích của lần release này:

  • Release này có mục đích gì? (Thêm tính năng mới, sửa lỗi, cải thiện hiệu năng, phục vụ test, hotfix?)
  • Có những tính năng mới nào?
  • Đã sửa những lỗi gì?
  • Đã loại bỏ những tính năng gì?

Review chất lượng code

Ở bước này, bạn cần chắc chắn rằng những sự thay đổi về mã nguồn là tương ứng với thay đổi về mặt tính năng đã xác định trong phần trước. Bạn cần trả lời các câu hỏi sau:

  • Các nhánh mã nguồn thay đổi đã đúng với yêu cầu release chưa? Có phần nào bị thừa / thiếu không?
  • Chất lượng mã nguồn có được đảm bảo không?
  • Có lỗi tiềm ẩn về tính năng / hiệu năng không?

Viết Change log

Sau khi đảm bảo được chất lượng mã nguồn và các thay đổi đã được merge vào nhánh chính, bạn cần viết change log để ghi nhận sự thay đổi này.

  • Có tính năng gì mới?
  • Những lỗi nào đã được sửa?
  • Có tính năng gì bị loại bỏ?

Đánh số phiên bản

Việc đánh số phiên bản nhằm ghi nhận đây là một release mới với version name (tên phiên bản) và version code (mã phiên bản, hay còn gọi là build number) mới. Version name nên được đặt tuân theo semantic versioning. (semver)

Một cách ngắn gọn, semver là phương pháp đánh số phiên bản với 3 chữ số dạng x.y.z, trong đó:

  • x (major): con số thể hiện sự thay đổi lớn và không tương thích với bản trước (breaking changes)
  • y (minor): con số thể hiện có tính năng mới và các tính năng cũ vẫn tương thích với bản trước
  • z (patch): con số thể hiện có lỗi đã được sửa. Dựa trên những sự thay đổi về mặt tính năng / nghiệp vụ và kĩ thuật, bạn cần đánh giá các thay đổi ở 3 mức độ như trên để tăng các chỉ số semver tương ứng.

Ví dụ: Nếu ứng dụng hiện tại đang ở phiên bản 1.0.0:

  • Phiên bản làm lại của nó sẽ phải bắt đầu từ 2.0.0
  • Phiên bản bổ sung tính năng của nó sẽ bắt đầu từ 1.1.0 và dưới 2.0.0
  • Phiên bản sửa lỗi sẽ bắt đầu từ 1.0.1 và dưới 1.1.0

Đánh giá backward-compatibility

Backward-compatibility là tính tương thích ngược với các phiên bản cũ. Sau khi đánh số phiên bản, bạn cần đánh giá backward-compatibility của release mới với các câu hỏi sau:

  • Những phiên bản cũ nào có thể được cập nhật trực tiếp lên phiên bản mới này mà không gặp vấn đề gì?
  • Những phiên bản nào có thể được cập nhật gián tiếp lên phiên bản này bằng các cách khác nhau và cụ thể là cách nào? (cập nhật từng bước, cập nhật thủ công, gỡ đi cài lại, …)
  • Những phiên bản nào không còn được hỗ trợ nữa?

Đánh giá backward-compatibility sẽ giúp bạn kiểm soát được vòng đời của ứng dụng và có một kế hoạch cập nhật chi tiết, cẩn thận và an toàn dành cho từng phiên bản cũ đang hoạt động.

Thực hiện release (Creating release)

Tại bước này, bạn chỉ cần thực hiện release và sửa các lỗi kĩ thuật phát sinh hoặc ghi nhận các vấn đề gặp phải. Bạn cũng có thể đánh giá các tình huống hoặc lỗi ẩn có thể xảy ra để có kế hoạch cho lần release tiếp theo.

Kiểm thử release (Testing)

Sau khi thực hiện release, bạn cần kiểm tra lại một lần nữa để đảm bảo người dùng không gặp vấn đề khi cập nhật ứng dụng lên phiên bản mới này.

Đưa tới người dùng (Rolling-out to production)

Sau khi đã kiểm tra ở bước trên và không còn lỗi phát sinh, bạn có thể roll-out ứng dụng tới người dùng.

Và cuối cùng, bước này có thể không nằm trong quy trình, nhưng tôi nghĩ bạn cũng nên thắp hương các cụ cũng như ăn uống và ngủ nghỉ đủ giấc trước khi thực hiện release để có thể giữ một tâm lý thoải mái, vững vàng và một sức khoẻ tốt trong quá trình release. Chúc các bạn release an toàn.

This post is licensed under CC BY 4.0 by the author.
Trending Tags