1. Tổng quan về App Release & Deployment

Trong quá trình phát triển ứng dụng phần mềm, việc hoàn thành code và chạy ứng dụng thành công trên máy tính của lập trình viên mới chỉ là một phần của toàn bộ quy trình. Để người dùng thực sự có thể sử dụng ứng dụng, ứng dụng cần được chuẩn bị, kiểm thử, đóng gói, phát hành và triển khai lên môi trường phù hợp. Toàn bộ quá trình này được gọi là App Release & Deployment.

App Release & Deployment là một giai đoạn quan trọng trong vòng đời phát triển phần mềm, đặc biệt đối với ứng dụng di động được xây dựng bằng Flutter, React Native, Android Native hoặc iOS Native. Quá trình này giúp chuyển đổi sản phẩm từ môi trường phát triển sang một phiên bản hoàn chỉnh mà người dùng có thể cài đặt, truy cập và sử dụng trong thực tế.

Trong một dự án Flutter, chẳng hạn, lập trình viên có thể hoàn thành giao diện, tích hợp API, xử lý đăng nhập, lưu trữ dữ liệu và kiểm thử các chức năng. Tuy nhiên, ứng dụng vẫn chưa thể được xem là sẵn sàng phát hành nếu chưa được cấu hình môi trường production, kiểm tra quyền truy cập, thiết lập chữ ký ứng dụng, tối ưu dung lượng, xử lý lỗi và chuẩn bị các gói cài đặt phù hợp với từng nền tảng.

App Release & Deployment thường bao gồm nhiều hoạt động như:

• Chuẩn bị ứng dụng trước khi phát hành.

• Quản lý phiên bản và số hiệu bản build.

• Cấu hình môi trường Development, Staging và Production.

• Kiểm thử bản phát hành trên thiết bị thực tế.

• Tạo file cài đặt hoặc gói phân phối ứng dụng.

• Ký ứng dụng bằng chứng thư số.

• Phát hành ứng dụng lên Google Play hoặc Apple App Store.

• Triển khai ứng dụng đến người dùng hoặc hệ thống phân phối nội bộ.

• Theo dõi lỗi, hiệu suất và phản hồi sau khi phát hành.

• Phát hành bản cập nhật và khôi phục phiên bản khi xảy ra sự cố.

Điểm quan trọng cần hiểu là Release và Deployment có liên quan chặt chẽ nhưng không hoàn toàn giống nhau. Release tập trung vào việc chuẩn bị và đưa một phiên bản phần mềm ra sử dụng, trong khi Deployment tập trung vào việc đưa phiên bản đó đến môi trường hoặc hệ thống đích. Trong thực tế, hai hoạt động này thường được thực hiện liên tiếp hoặc phối hợp trong cùng một quy trình.

2. Vai trò của App Release & Deployment trong vòng đời phần mềm

Một ứng dụng không chỉ cần hoạt động đúng trong môi trường phát triển mà còn phải duy trì sự ổn định khi được sử dụng bởi nhiều người dùng, trên nhiều thiết bị và trong các điều kiện mạng khác nhau.

App Release & Deployment đóng vai trò kết nối giữa hoạt động phát triển phần mềm và quá trình vận hành sản phẩm thực tế.

2.1. Chuyển đổi sản phẩm từ môi trường phát triển sang môi trường sử dụng thực tế

Trong môi trường Development, lập trình viên thường xuyên chỉnh sửa code, sử dụng dữ liệu thử nghiệm, bật các công cụ debug và kết nối với máy chủ dành cho quá trình phát triển.

Những cấu hình này không phù hợp để đưa trực tiếp đến người dùng cuối. Một ứng dụng production cần sử dụng cấu hình chính xác, endpoint API chính thức, chính sách bảo mật phù hợp và các tài nguyên cần thiết để vận hành ổn định.

Ví dụ, một ứng dụng bán hàng có thể sử dụng API thử nghiệm trong quá trình phát triển. Khi phát hành, ứng dụng cần chuyển sang API production để truy xuất sản phẩm, tạo đơn hàng và xử lý thanh toán thực tế.

Nếu quá trình chuyển đổi này không được thực hiện chính xác, ứng dụng có thể cài đặt thành công nhưng không thể đăng nhập, không tải được dữ liệu hoặc gửi yêu cầu đến sai máy chủ.

2.2. Đảm bảo chất lượng của phiên bản phát hành

Phiên bản chạy thành công trên máy của lập trình viên chưa chắc đã hoạt động chính xác trên thiết bị của người dùng.

Sự khác biệt về hệ điều hành, kiến trúc thiết bị, quyền truy cập, kết nối mạng, cấu hình máy chủ và dữ liệu thực tế có thể tạo ra những lỗi không xuất hiện trong quá trình phát triển.

Release giúp xác định một phiên bản cụ thể đã được chuẩn bị và kiểm tra trước khi phân phối. Nhờ đó, nhóm phát triển có thể xác định chính xác phiên bản nào đang được kiểm thử, phiên bản nào đã phát hành và phiên bản nào cần sửa lỗi.

2.3. Hỗ trợ quản lý và bảo trì ứng dụng lâu dài

Sau khi phát hành, ứng dụng vẫn cần được duy trì, cập nhật và cải tiến. Các hệ điều hành có thể thay đổi, thư viện có thể xuất hiện lỗ hổng bảo mật, API có thể được nâng cấp và người dùng có thể báo cáo những lỗi mới.

Một quy trình Release & Deployment rõ ràng giúp nhóm phát triển quản lý các thay đổi có hệ thống, giảm nguy cơ phát hành nhầm phiên bản và hỗ trợ truy vết khi sự cố xảy ra.

2.4. Giảm rủi ro trong quá trình triển khai

Một bản cập nhật không được kiểm soát có thể khiến nhiều người dùng gặp lỗi cùng lúc. Chẳng hạn, ứng dụng mới có thể gặp vấn đề khi đăng nhập, mất khả năng tải dữ liệu hoặc không tương thích với phiên bản backend hiện tại.

Quy trình triển khai chuyên nghiệp giúp hạn chế rủi ro bằng cách sử dụng môi trường staging, kiểm thử trước khi phát hành, triển khai theo từng giai đoạn khi nền tảng hỗ trợ và theo dõi lỗi sau khi cập nhật.

3. Phân biệt Release, Build, Deployment và Distribution

Bốn thuật ngữ này thường xuất hiện cùng nhau nhưng mô tả những công việc khác nhau.

Các hoạt động này không phải lúc nào cũng diễn ra theo một thứ tự cứng nhắc. Một phiên bản có thể được build nhiều lần trước khi được duyệt release. Tương tự, việc triển khai backend và phát hành ứng dụng di động có thể được thực hiện ở các thời điểm khác nhau.

Hiểu rõ sự khác biệt này giúp lập trình viên xây dựng quy trình phát hành dễ quản lý và xác định chính xác công việc cần thực hiện khi xảy ra sự cố.

4. Các môi trường trong quy trình phát hành ứng dụng

Trong một dự án chuyên nghiệp, ứng dụng thường không được chuyển thẳng từ máy lập trình viên đến người dùng cuối. Thay vào đó, phần mềm đi qua nhiều môi trường khác nhau nhằm kiểm soát chất lượng, xác minh cấu hình và giảm thiểu lỗi.

4.1. Development Environment

Development là môi trường được sử dụng trong quá trình xây dựng và chỉnh sửa ứng dụng. Lập trình viên thường xuyên thay đổi mã nguồn, kiểm tra giao diện, xử lý lỗi và thử nghiệm các chức năng mới tại đây.

Đặc điểm phổ biến của môi trường Development gồm:

• Sử dụng dữ liệu thử nghiệm hoặc tài khoản dành riêng cho lập trình viên.

• Có thể bật debug logging và các công cụ hỗ trợ phát triển.

• Kết nối với API hoặc cơ sở dữ liệu development.

• Cho phép thay đổi cấu hình thường xuyên.

• Ưu tiên tốc độ phát triển và khả năng phát hiện lỗi.

Đối với Flutter, lập trình viên có thể sử dụng lệnh flutter run để chạy ứng dụng ở chế độ debug. Trong chế độ này, Flutter hỗ trợ hot reload, kiểm tra lỗi và cung cấp thông tin phục vụ quá trình phát triển.

Tuy nhiên, bản debug không nên được sử dụng thay thế cho bản phát hành production. Hai loại build có thể khác nhau về hiệu suất, cấu hình, khả năng quan sát lỗi và cách xử lý tài nguyên.

4.2. Staging Environment

Staging là môi trường được sử dụng để kiểm thử ứng dụng trước khi phát hành chính thức. Môi trường này thường được cấu hình gần với production nhằm phát hiện các vấn đề chỉ xuất hiện khi ứng dụng vận hành trong điều kiện thực tế.

Staging có thể sử dụng:

• API staging riêng biệt.

• Cơ sở dữ liệu thử nghiệm.

• Tài khoản và dữ liệu mô phỏng người dùng.

• Cấu hình bảo mật tương tự production.

• Phiên bản backend gần với phiên bản chuẩn bị triển khai.

• Hệ thống ghi nhận lỗi và giám sát hoạt động.

Ví dụ, một ứng dụng thương mại điện tử có thể sử dụng staging để kiểm tra toàn bộ quy trình mua hàng, từ xem sản phẩm, thêm vào giỏ hàng, tạo đơn đến nhận thông báo kết quả thanh toán giả lập.

Nếu tất cả chức năng hoạt động đúng trong staging, nhóm phát triển có thêm cơ sở để đánh giá khả năng phát hành. Tuy nhiên, staging không đảm bảo tuyệt đối rằng ứng dụng sẽ không phát sinh lỗi trong production.

4.3. Production Environment

Production là môi trường vận hành thực tế, nơi ứng dụng phục vụ người dùng cuối.

Đối với ứng dụng di động, production thường gắn với bản ứng dụng được phân phối chính thức hoặc được phát hành đến nhóm người dùng thực tế. Đối với backend, đây là hệ thống máy chủ xử lý yêu cầu thật và sử dụng dữ liệu thật.

Môi trường production cần chú trọng:

• Bảo mật dữ liệu và thông tin xác thực.

• Tính ổn định của hệ thống.

• Hiệu suất và khả năng mở rộng.

• Giám sát lỗi và thời gian phản hồi.

• Sao lưu dữ liệu đối với hệ thống có lưu trữ.

• Quản lý quyền truy cập và nhật ký hoạt động.

• Khả năng khôi phục khi xảy ra sự cố.

Một nguyên tắc quan trọng là không đưa thông tin nhạy cảm, tài khoản quản trị hoặc dữ liệu cá nhân thực vào môi trường thử nghiệm nếu chưa có biện pháp bảo vệ phù hợp.

4.4. Quản lý cấu hình giữa các môi trường

Ứng dụng có thể sử dụng cùng một mã nguồn nhưng cần các cấu hình khác nhau cho từng môi trường.

Ví dụ:

class AppConfig {
  static const String environment =
      String.fromEnvironment(
    'APP_ENV',
    defaultValue: 'development',
  );

  static const String apiBaseUrl =
      String.fromEnvironment(
    'API_BASE_URL',
    defaultValue: 'https://dev-api.example.com',
  );
}

Khi build, các giá trị có thể được truyền qua --dart-define:

flutter build apk \
  --release \
  --dart-define=APP_ENV=production \
  --dart-define=API_BASE_URL=https://api.example.com

Đoạn code trên minh họa cách sử dụng cấu hình tại thời điểm biên dịch. Trong dự án thực tế, cần kiểm tra kỹ cách quản lý cấu hình để tránh việc vô tình phát hành ứng dụng với API development.

Ngoài ra, --dart-define không phải là cơ chế bảo mật bí mật. Các giá trị được đưa vào ứng dụng client có thể bị trích xuất hoặc phân tích. Không nên nhúng private key, mật khẩu cơ sở dữ liệu hoặc secret có quyền truy cập cao trực tiếp vào ứng dụng.

5. Quy trình chuẩn bị ứng dụng trước khi Release

Trước khi tạo bản phát hành, nhóm phát triển cần thực hiện một bước kiểm tra tổng thể. Đây là giai đoạn quan trọng nhằm bảo đảm sản phẩm không chỉ chạy được mà còn đáp ứng các yêu cầu về chức năng, bảo mật và chất lượng.

5.1. Hoàn thiện chức năng

Tất cả tính năng thuộc phạm vi phiên bản cần phát hành phải được hoàn thiện hoặc có trạng thái xử lý rõ ràng.

Nhóm phát triển cần kiểm tra các luồng chính như đăng ký, đăng nhập, đăng xuất, truy xuất dữ liệu, gửi biểu mẫu, xử lý lỗi mạng và các chức năng đặc thù của ứng dụng.

Các chức năng chưa hoàn thành cần được loại bỏ khỏi phạm vi release hoặc được kiểm soát để không gây ảnh hưởng đến người dùng.

5.2. Kiểm tra lỗi và chất lượng mã nguồn

Đối với dự án Flutter, một số lệnh hữu ích gồm:

flutter analyze
flutter test
flutter pub get

Trong đó:

• flutter analyze kiểm tra các vấn đề tĩnh trong mã nguồn.

• flutter test chạy các bài kiểm thử được cấu hình trong dự án.

• flutter pub get tải và đồng bộ các dependency được khai báo.

Các lệnh này không thay thế cho việc kiểm thử trên thiết bị thực tế. Một dự án không có lỗi phân tích tĩnh vẫn có thể gặp lỗi giao diện, lỗi logic, vấn đề tương thích hoặc lỗi khi kết nối backend.

5.3. Kiểm tra dependency

Dependency là các thư viện và gói bên ngoài được ứng dụng sử dụng. Trước khi phát hành, lập trình viên cần kiểm tra những thư viện đang sử dụng, phiên bản của chúng và khả năng tương thích với nền tảng mục tiêu.

Cần đặc biệt chú ý đến:

• Thư viện đã ngừng bảo trì.

• Dependency có lỗ hổng bảo mật đã biết.

• Thay đổi API giữa các phiên bản.

• Plugin yêu cầu quyền truy cập mới.

• Khả năng tương thích với phiên bản Android hoặc iOS mục tiêu.

• Các thư viện có cấu hình native bổ sung.

Việc nâng cấp dependency ngay trước ngày release cần được kiểm soát cẩn thận, vì một thay đổi nhỏ cũng có thể gây ra lỗi ngoài dự kiến.

5.4. Kiểm tra tài nguyên ứng dụng

Tài nguyên có thể bao gồm hình ảnh, icon, font chữ, tệp âm thanh, tệp cấu hình và các dữ liệu được đóng gói cùng ứng dụng.

Lập trình viên cần xác nhận các tài nguyên cần thiết đã được khai báo và đóng gói đúng cách. Đối với Flutter, cần kiểm tra cấu hình assets trong pubspec.yaml, icon ứng dụng, splash screen và các tài nguyên dành riêng cho từng nền tảng.

Ngoài tính đầy đủ, cần đánh giá kích thước của tài nguyên. Hình ảnh có độ phân giải quá cao, font không cần thiết hoặc các tệp trùng lặp có thể làm tăng dung lượng cài đặt.

5.5. Kiểm tra quyền truy cập

Ứng dụng di động có thể yêu cầu quyền truy cập camera, vị trí, micro, thư viện ảnh, thông báo hoặc các tài nguyên khác của thiết bị.

Trước khi phát hành, cần xác nhận rằng:

• Chỉ yêu cầu những quyền thực sự cần thiết.

• Người dùng được giải thích rõ mục đích sử dụng quyền.

• Ứng dụng xử lý đúng trường hợp người dùng từ chối quyền.

• Những chức năng không được cấp quyền vẫn có hành vi phù hợp.

• Khai báo quyền trong Android và iOS đúng với nhu cầu thực tế.

Việc yêu cầu quá nhiều quyền không cần thiết có thể ảnh hưởng đến trải nghiệm người dùng và quá trình xét duyệt trên cửa hàng ứng dụng.

6. Quản lý phiên bản và Build Number

Quản lý phiên bản là một phần quan trọng của App Release & Deployment. Mỗi bản phát hành cần có thông tin nhận diện rõ ràng để nhóm phát triển và người dùng phân biệt các phiên bản.

6.1. Version Name

Version Name là phiên bản được hiển thị cho người dùng, thường sử dụng định dạng như:

• 1.0.0: phiên bản phát hành đầu tiên.

• 1.1.0: phiên bản bổ sung tính năng.

• 1.1.1: phiên bản sửa lỗi.

• 2.0.0: phiên bản có thay đổi lớn.

Một cách quản lý phổ biến là Semantic Versioning, sử dụng ba thành phần MAJOR.MINOR.PATCH.

• MAJOR: thay đổi lớn có thể gây mất tương thích.

• MINOR: bổ sung tính năng theo hướng tương thích ngược.

• PATCH: sửa lỗi và các thay đổi nhỏ tương thích ngược.

Đây là quy ước phổ biến, không phải yêu cầu bắt buộc của mọi cửa hàng ứng dụng. Nhóm phát triển có thể điều chỉnh quy tắc tùy theo dự án.

6.2. Build Number

Build Number là số hiệu dùng để phân biệt các bản build. Trong nhiều hệ thống phát hành, mỗi lần tải lên một bản build mới cần bảo đảm số build phù hợp với quy tắc của nền tảng và chưa bị sử dụng theo cách gây xung đột.

Ví dụ:

Bảng trên chỉ minh họa một cách quản lý đơn giản. Trong dự án thực tế, build number có thể tăng qua mỗi lần build, kể cả khi version name không thay đổi.

6.3. Quản lý phiên bản trong Flutter

Flutter khai báo phiên bản trong tệp pubspec.yaml:

name: my_app
description: My Flutter application

version: 1.2.0+15

Trong ví dụ này:

• 1.2.0 là version name.

• 15 là build number.

Khi tạo bản release, Flutter sử dụng các thông tin này để cấu hình phiên bản ứng dụng trên nền tảng tương ứng.

Có thể chỉ định lại phiên bản khi build bằng các tùy chọn như --build-name và --build-number. Cách quản lý cần thống nhất giữa cấu hình dự án và quy trình CI/CD để tránh phát hành trùng hoặc sai phiên bản.

6.4. Quản lý phiên bản trong Git

Git giúp nhóm phát triển xác định chính xác mã nguồn được dùng để tạo ra một bản phát hành.

Một số thao tác thường gặp:

git status
git log --oneline
git tag v1.2.0
git push origin v1.2.0

Tag v1.2.0 có thể được sử dụng để đánh dấu một mốc phát hành. Trước khi tạo tag, cần bảo đảm đang đứng tại commit đúng và các thay đổi đã được xác nhận.

Trong dự án lớn, có thể kết hợp Git tag với CI/CD để tự động tạo bản build từ đúng commit, lưu lại thông tin phát hành và hỗ trợ truy vết khi cần sửa lỗi.

7. Flutter Build Modes và bản phát hành Release

Flutter hỗ trợ nhiều chế độ build phục vụ những mục đích khác nhau. Việc hiểu rõ các chế độ này giúp lập trình viên lựa chọn đúng cách chạy ứng dụng trong quá trình phát triển và phát hành.

7.1. Debug Mode

Debug Mode được sử dụng chủ yếu trong quá trình phát triển. Chế độ này hỗ trợ hot reload, công cụ debug và khả năng kiểm tra hoạt động của ứng dụng.

Ưu điểm của Debug Mode là giúp lập trình viên sửa lỗi nhanh chóng. Tuy nhiên, hiệu suất và hành vi của ứng dụng trong chế độ này có thể khác với bản release.

Vì vậy, không nên chỉ dựa vào kết quả chạy debug để kết luận rằng ứng dụng đã sẵn sàng phát hành.

7.2. Profile Mode

Profile Mode được sử dụng để phân tích hiệu suất ứng dụng. Chế độ này phù hợp khi cần kiểm tra thời gian dựng khung hình, mức sử dụng tài nguyên và các vấn đề hiệu năng.

Đối với ứng dụng có nhiều hoạt ảnh, danh sách dữ liệu lớn hoặc xử lý hình ảnh, việc profile giúp phát hiện các vấn đề khó quan sát trong quá trình phát triển thông thường.

7.3. Release Mode

Release Mode tạo ra phiên bản hướng đến việc phân phối và sử dụng thực tế. Các tính năng hỗ trợ debug có thể bị loại bỏ hoặc hạn chế, đồng thời quá trình biên dịch và tối ưu hóa được thực hiện phù hợp với nền tảng.

Đối với Flutter, có thể tạo bản release bằng những lệnh như:

flutter build apk --release

Hoặc tạo Android App Bundle:

flutter build appbundle --release

Đối với iOS:

flutter build ipa --release

Lệnh build iOS cần môi trường và công cụ phù hợp, thông thường là macOS với Xcode được cấu hình đúng. Việc tạo được gói build không đồng nghĩa với việc ứng dụng đã được ký, tải lên cửa hàng hoặc được phê duyệt phát hành.

7.4. Những điểm cần kiểm tra trên bản Release

Một số lỗi chỉ xuất hiện khi chạy bản release, chẳng hạn:

• Ứng dụng không kết nối được API production.

• Một số thành phần phụ thuộc vào cấu hình debug.

• Plugin native hoạt động khác với môi trường phát triển.

• Tài nguyên bị thiếu hoặc đường dẫn không chính xác.

• Cấu hình tối ưu hóa làm lộ ra lỗi trong code.

• Hệ thống đăng nhập hoặc xác thực không hoạt động do cấu hình ký ứng dụng.

• Ứng dụng bị hệ điều hành chặn do thiếu cấu hình cần thiết.

Do đó, bản release cần được cài đặt và kiểm thử thực tế trước khi phát hành chính thức.

8. Android App Release

Đối với Android, quá trình phát hành thường xoay quanh việc cấu hình ứng dụng, tạo gói cài đặt, ký ứng dụng và phân phối thông qua Google Play hoặc các kênh phù hợp khác.

Hai định dạng phổ biến là APK và Android App Bundle (AAB).

8.1. Android Package Kit (APK)

APK là định dạng gói cài đặt Android có thể được cài đặt trực tiếp lên thiết bị tương thích.

APK thường được sử dụng để:

• Cài đặt ứng dụng trên thiết bị thử nghiệm.

• Phân phối ứng dụng nội bộ.

• Kiểm tra bản release trước khi đưa lên cửa hàng.

• Phân phối trực tiếp trong các trường hợp phù hợp.

Trong Flutter, có thể tạo APK release bằng lệnh:

flutter build apk --release

Sau khi build thành công, file APK thường được tạo tại:

build/app/outputs/flutter-apk/app-release.apk

Nếu cần kiểm tra nhiều kiến trúc hoặc tạo các APK riêng biệt theo ABI, Flutter hỗ trợ tùy chọn --split-per-abi. Cách đóng gói này có thể giúp giảm dung lượng mỗi gói cài đặt, nhưng cần bảo đảm người nhận sử dụng đúng gói tương thích.

8.2. Android App Bundle (AAB)

AAB là định dạng đóng gói được sử dụng phổ biến khi phát hành ứng dụng Android qua Google Play.

Thay vì cung cấp một APK duy nhất cho mọi cấu hình thiết bị, AAB cho phép hệ thống phân phối tạo ra các APK phù hợp hơn với cấu hình của từng thiết bị.

Có thể tạo AAB bằng lệnh:

flutter build appbundle --release

File đầu ra thường nằm tại:

build/app/outputs/bundle/release/app-release.aab

AAB không được cài trực tiếp theo cách thông thường như APK. Để kiểm thử, có thể sử dụng công cụ phù hợp để tạo APK từ bundle hoặc sử dụng các kênh kiểm thử của Google Play.

Đối với ứng dụng phát hành trên Google Play, AAB là định dạng được sử dụng phổ biến và thường được yêu cầu đối với ứng dụng mới, tùy theo chính sách áp dụng cho từng trường hợp.

8.3. Cấu hình Android Manifest

Android Manifest là tệp khai báo thông tin quan trọng về ứng dụng Android. Tệp này có thể xác định quyền truy cập, các thành phần ứng dụng, cấu hình hoạt động và những thuộc tính cần thiết cho hệ điều hành.

Một số nội dung cần kiểm tra trước khi phát hành gồm:

• Tên ứng dụng.

• Application ID.

• Quyền truy cập thiết bị.

• Cấu hình activity.

• Deep links và intent filters.

• Cấu hình mạng.

• Phiên bản SDK mục tiêu.

• Các thành phần native được sử dụng.

Cần chú ý đến applicationId, vì đây là định danh quan trọng của ứng dụng trên Android. Khi đã phát hành, việc thay đổi định danh này có thể khiến cửa hàng xem ứng dụng như một ứng dụng khác thay vì bản cập nhật của ứng dụng hiện tại.

8.4. Cấu hình SDK và khả năng tương thích

Android sử dụng các thông số như minSdk, targetSdk và compileSdk để xác định phạm vi tương thích và cách ứng dụng được xây dựng.

• minSdk: phiên bản Android thấp nhất mà ứng dụng hỗ trợ.

• targetSdk: phiên bản API mà ứng dụng khai báo nhắm đến để áp dụng hành vi tương ứng của Android.

• compileSdk: phiên bản API dùng để biên dịch ứng dụng.

Các giá trị này cần được cấu hình phù hợp với yêu cầu kỹ thuật và chính sách phát hành hiện hành. Không nên tùy ý tăng hoặc giảm SDK mà chưa kiểm tra plugin, API và các thay đổi hành vi của hệ điều hành.

9. App Signing và bảo mật bản phát hành Android

App Signing là quá trình sử dụng chữ ký số để xác định nguồn gốc và tính toàn vẹn của gói ứng dụng. Đây là một thành phần quan trọng trong quy trình phát hành Android.

9.1. Vai trò của chữ ký ứng dụng

Chữ ký ứng dụng giúp Android xác minh rằng bản cập nhật thuộc cùng một danh tính ký hợp lệ theo các quy tắc của nền tảng.

Khi phát hành ứng dụng, lập trình viên cần bảo vệ khóa ký và bảo đảm quy trình tạo chữ ký được kiểm soát. Nếu khóa cần thiết bị mất hoặc bị sử dụng sai cách, quá trình cập nhật có thể bị ảnh hưởng, tùy theo cấu hình ký và cơ chế quản lý khóa đang áp dụng.

9.2. Keystore và Key Alias

Keystore là nơi lưu trữ thông tin liên quan đến khóa ký. Trong quy trình Android truyền thống, lập trình viên có thể tạo một tệp keystore và sử dụng key alias để xác định khóa cần dùng.

Một ví dụ tạo keystore bằng keytool:

keytool -genkeypair \
  -v \
  -keystore upload-keystore.jks \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000 \
  -alias upload

Lệnh trên minh họa cách tạo một khóa ký. Các thông tin thực tế cần được thiết lập phù hợp với chính sách bảo mật của dự án.

Không đưa keystore, mật khẩu keystore hoặc thông tin bí mật liên quan vào Git repository công khai. Những dữ liệu này cần được lưu trữ an toàn và giới hạn quyền truy cập.

9.3. Cấu hình ký trong Flutter

Dự án Flutter Android có thể sử dụng cấu hình Gradle để ký bản release. Thông tin nhạy cảm nên được cung cấp qua cơ chế quản lý secret hoặc cấu hình bảo mật thích hợp thay vì ghi trực tiếp vào mã nguồn.

Quy trình cơ bản gồm:

1. Tạo hoặc thiết lập khóa ký.

2. Cấu hình thông tin ký trong dự án Android.

3. Kiểm tra cấu hình Gradle.

4. Tạo bản release.

5. Xác minh chữ ký của gói đầu ra.

6. Lưu trữ khóa và tài liệu quản lý khóa an toàn.

Trong quy trình phát hành qua Google Play, cần phân biệt upload key và app signing key khi sử dụng Play App Signing. Đây là hai vai trò có thể khác nhau; khóa dùng để tải gói lên không nhất thiết là khóa cuối cùng dùng để ký APK phân phối đến người dùng.

9.4. Quản lý khóa trong CI/CD

Khi tự động hóa quá trình build, hệ thống CI/CD cần có cách cung cấp thông tin ký an toàn.

Các nguyên tắc quan trọng gồm:

• Lưu secret trong kho bí mật của nền tảng CI/CD.

• Giới hạn quyền truy cập theo vai trò.

• Không in mật khẩu hoặc nội dung khóa ra log.

• Không lưu tệp khóa vào artifact công khai.

• Theo dõi những lần sử dụng khóa ký.

• Có quy trình sao lưu và khôi phục phù hợp.

Một pipeline build tự động chỉ thực sự an toàn khi thông tin xác thực được quản lý đúng cách.

10. iOS App Release

Đối với iOS, quy trình phát hành thường sử dụng Xcode, Apple Developer Program và hệ thống phân phối ứng dụng của Apple.

Ứng dụng iOS có các yêu cầu riêng về chữ ký, provisioning profile, định danh ứng dụng và quyền truy cập hệ thống.

10.1. Bundle Identifier

Bundle Identifier là định danh của ứng dụng trên hệ sinh thái Apple. Ví dụ:

com.example.myapp

Bundle Identifier cần được cấu hình chính xác trong dự án iOS. Khi phát hành bản cập nhật, cần giữ đúng định danh ứng dụng hiện có để hệ thống nhận diện phiên bản mới thuộc cùng một ứng dụng.

10.2. Signing Certificate

Signing Certificate là chứng thư được sử dụng trong quy trình ký ứng dụng. Tùy hình thức phát hành, Apple quy định các loại chứng thư và cơ chế ký phù hợp.

Lập trình viên cần kiểm tra chứng thư, quyền truy cập và cấu hình ký tương ứng với mục tiêu phân phối, chẳng hạn thử nghiệm nội bộ hoặc phát hành qua App Store.

10.3. Provisioning Profile

Provisioning Profile liên kết những thông tin cần thiết để cho phép ứng dụng được ký và sử dụng theo một hình thức phân phối nhất định.

Trong các quy trình iOS, provisioning profile có thể liên quan đến App ID, chứng thư và các thiết bị được phép sử dụng ứng dụng trong những hình thức phân phối cụ thể.

Việc cấu hình sai provisioning profile có thể khiến quá trình archive, export hoặc cài đặt ứng dụng thất bại.

10.4. Archive và Export

Trong Xcode, Archive là bước đóng gói ứng dụng để phục vụ phân phối. Sau khi archive, lập trình viên có thể xác minh thông tin bản build và export gói ứng dụng theo phương thức được hỗ trợ.

Với Flutter, lệnh sau có thể được sử dụng để tạo IPA:

flutter build ipa --release

Quy trình cụ thể có thể yêu cầu cấu hình signing trong Xcode và tài khoản nhà phát triển phù hợp. File IPA được tạo ra vẫn cần được phân phối theo đúng phương thức, chẳng hạn thông qua App Store Connect hoặc hệ thống phân phối được hỗ trợ.

10.5. Kiểm thử trên thiết bị iOS

Trước khi phát hành, nên kiểm thử ứng dụng trên các thiết bị và phiên bản iOS phù hợp với phạm vi hỗ trợ.

Các nội dung cần xác minh gồm:

• Đăng nhập và đăng xuất.

• Quyền truy cập camera, vị trí và thông báo.

• Hiển thị trên nhiều kích thước màn hình.

• Deep links và điều hướng.

• Xử lý khi ứng dụng chạy nền hoặc được mở lại.

• Kết nối API và xử lý lỗi mạng.

• Hoạt động của các plugin native.

• Khả năng cài đặt và cập nhật phiên bản.

Không nên chỉ dựa vào Simulator để đánh giá toàn bộ hành vi của ứng dụng, bởi một số chức năng và vấn đề phần cứng chỉ có thể được xác minh đầy đủ trên thiết bị thực tế.

11. Phát hành ứng dụng lên Google Play

Google Play là một trong những kênh phân phối ứng dụng Android phổ biến. Quá trình phát hành cần chuẩn bị cả gói ứng dụng lẫn thông tin phục vụ người dùng và quá trình xét duyệt.

11.1. Chuẩn bị trang ứng dụng

Trang ứng dụng thường bao gồm:

• Tên ứng dụng.

• Mô tả ngắn và mô tả đầy đủ.

• Icon ứng dụng.

• Ảnh chụp màn hình.

• Thông tin nhà phát triển.

• Thông tin hỗ trợ người dùng.

• Chính sách quyền riêng tư khi được yêu cầu.

• Khai báo dữ liệu và quyền truy cập phù hợp.

Thông tin cung cấp phải phản ánh chính xác chức năng thực tế của ứng dụng. Những tuyên bố sai lệch hoặc thiếu thông tin bắt buộc có thể ảnh hưởng đến quá trình xét duyệt.

11.2. Chuẩn bị bản phát hành

Trước khi tải gói ứng dụng lên Google Play Console, cần kiểm tra:

• AAB được build thành công.

• Chữ ký và cấu hình ứng dụng hợp lệ.

• Version name và version code phù hợp.

• API production hoạt động chính xác.

• Các yêu cầu về SDK và chính sách được đáp ứng.

• Nội dung trang ứng dụng đã hoàn thiện.

• Các khai báo về quyền và dữ liệu được cung cấp đầy đủ.

11.3. Các kênh kiểm thử

Google Play hỗ trợ các hình thức phân phối phục vụ kiểm thử trước khi phát hành rộng rãi, chẳng hạn Internal testing, Closed testing và Open testing, tùy theo khả năng và điều kiện áp dụng.

• Internal testing: phục vụ kiểm thử trong nhóm nhỏ.

• Closed testing: phân phối cho nhóm người thử nghiệm được kiểm soát.

• Open testing: cho phép nhóm người thử nghiệm rộng hơn tham gia theo điều kiện của chương trình.

Các kênh này giúp thu thập phản hồi trước khi phát hành chính thức. Một số tài khoản nhà phát triển hoặc ứng dụng có thể phải đáp ứng những điều kiện kiểm thử cụ thể trước khi được phép phát hành production.

11.4. Production Release

Sau khi hoàn tất kiểm thử và đáp ứng yêu cầu phát hành, nhóm phát triển có thể gửi bản release đến quy trình xét duyệt và triển khai production.

Cần lưu ý rằng việc tải gói lên thành công không đồng nghĩa với việc ứng dụng đã xuất hiện công khai trên cửa hàng. Trạng thái xét duyệt, lịch phát hành và cách triển khai có thể ảnh hưởng đến thời điểm người dùng nhìn thấy phiên bản mới.

11.5. Staged Rollout

Staged Rollout là phương thức triển khai bản cập nhật đến một tỷ lệ người dùng trước khi mở rộng phạm vi phát hành, nếu nền tảng và loại bản phát hành hỗ trợ.

Ví dụ, nhóm phát triển có thể bắt đầu với một tỷ lệ nhỏ người dùng, theo dõi các chỉ số ổn định rồi tăng dần phạm vi triển khai.

Cách làm này giúp hạn chế tác động nếu phiên bản mới xuất hiện lỗi nghiêm trọng. Tuy nhiên, nó không thay thế cho việc kiểm thử và không đảm bảo mọi sự cố đều được phát hiện trước khi ảnh hưởng đến người dùng.

12. Phát hành ứng dụng lên Apple App Store

Apple App Store là kênh phân phối chính thức cho nhiều ứng dụng iOS. Quá trình phát hành thường được quản lý thông qua App Store Connect và các công cụ thuộc hệ sinh thái Apple.

12.1. Chuẩn bị App Store Connect

Trước khi phát hành, cần chuẩn bị thông tin ứng dụng trên App Store Connect, bao gồm:

• Tên và mô tả ứng dụng.

• Icon và ảnh chụp màn hình.

• Thông tin phiên bản.

• Thông tin hỗ trợ.

• Phân loại độ tuổi phù hợp.

• Khai báo quyền riêng tư.

• Thông tin liên quan đến việc sử dụng dữ liệu.

• Thông tin bổ sung phục vụ quá trình xét duyệt khi cần.

Tùy loại ứng dụng, Apple có thể yêu cầu thêm các thông tin hoặc cấu hình liên quan đến chức năng đặc thù.

12.2. Upload bản build

Sau khi tạo archive phù hợp, lập trình viên có thể tải bản build lên App Store Connect bằng các công cụ được Apple hỗ trợ.

Sau khi upload, bản build có thể cần thời gian xử lý trước khi xuất hiện để lựa chọn trong quy trình phát hành.

Nhóm phát triển cần kiểm tra đúng bundle identifier, phiên bản, build number và cấu hình ký để tránh nhầm lẫn giữa các bản build.

12.3. App Review

Apple thực hiện quy trình xét duyệt nhằm đánh giá ứng dụng theo các yêu cầu và hướng dẫn hiện hành.

Ứng dụng có thể bị từ chối nếu gặp vấn đề như:

• Chức năng không hoạt động đúng.

• Nội dung hoặc mô tả gây hiểu nhầm.

• Khai báo quyền riêng tư không chính xác.

• Thiếu thông tin cần thiết cho quá trình đánh giá.

• Vi phạm các yêu cầu liên quan đến bảo mật hoặc nội dung.

• Gặp lỗi trong quá trình đăng nhập, thanh toán hoặc sử dụng chức năng chính.

Khi bị từ chối, nhóm phát triển cần xem xét nội dung phản hồi, sửa các vấn đề liên quan và gửi lại phiên bản phù hợp.

12.4. Phát hành phiên bản chính thức

Sau khi đáp ứng yêu cầu xét duyệt, ứng dụng có thể được phát hành theo cấu hình đã lựa chọn.

Tùy thiết lập, nhóm phát triển có thể lựa chọn thời điểm phát hành phù hợp hoặc sử dụng các phương thức triển khai theo từng giai đoạn được nền tảng hỗ trợ.

Sau khi phát hành, vẫn cần theo dõi tình trạng ứng dụng, phản hồi người dùng và các chỉ số ổn định để xác định có cần sửa lỗi hoặc chuẩn bị phiên bản tiếp theo hay không.

13. Testing trước khi phát hành

Testing là bước xác minh ứng dụng hoạt động đúng với các yêu cầu đã đặt ra. Trong quy trình Release & Deployment, kiểm thử cần được thực hiện trên bản build gần với bản sẽ phân phối, thay vì chỉ kiểm thử trên môi trường debug.

13.1. Functional Testing

Functional Testing tập trung vào việc xác minh từng chức năng của ứng dụng.

Ví dụ, đối với ứng dụng bán hàng, các trường hợp cần kiểm thử bao gồm:

• Hiển thị danh sách sản phẩm.

• Tìm kiếm và lọc sản phẩm.

• Thêm và xóa sản phẩm khỏi giỏ hàng.

• Đăng nhập và đăng xuất.

• Tạo đơn hàng.

• Xử lý kết quả thanh toán.

• Hiển thị lịch sử đơn hàng.

• Xử lý trường hợp API trả về lỗi.

Mỗi chức năng cần được kiểm tra với cả dữ liệu hợp lệ và dữ liệu không hợp lệ. Những trường hợp ngoại lệ cũng cần được xem xét để bảo đảm ứng dụng không bị treo hoặc đóng đột ngột.

13.2. Regression Testing

Regression Testing là kiểm thử hồi quy, được thực hiện để xác minh rằng những thay đổi mới không làm hỏng chức năng đã hoạt động trước đó.

Ví dụ, khi cập nhật thư viện xử lý đăng nhập, nhóm phát triển cần kiểm tra lại đăng nhập, đăng xuất, khôi phục phiên đăng nhập và các chức năng liên quan đến xác thực.

Kiểm thử hồi quy đặc biệt quan trọng đối với những ứng dụng có nhiều module và dependency. Một thay đổi nhỏ ở phần dùng chung có thể ảnh hưởng đến nhiều chức năng khác nhau.

13.3. Compatibility Testing

Compatibility Testing kiểm tra khả năng tương thích của ứng dụng trên các thiết bị, kích thước màn hình và phiên bản hệ điều hành khác nhau.

Những nội dung cần chú ý gồm:

• Giao diện trên điện thoại màn hình nhỏ.

• Giao diện trên thiết bị màn hình lớn.

• Khác biệt về phiên bản Android và iOS.

• Bàn phím ảo và vùng nhập liệu.

• Xoay màn hình nếu ứng dụng hỗ trợ.

• Hành vi khi chuyển ứng dụng xuống nền.

• Quyền truy cập và thông báo.

• Khả năng hoạt động trên thiết bị có tài nguyên hạn chế.

Không phải dự án nào cũng cần kiểm thử trên mọi thiết bị có mặt trên thị trường. Nhóm phát triển nên xác định tập thiết bị đại diện dựa trên đối tượng người dùng và phạm vi hỗ trợ.

13.4. Performance Testing

Performance Testing đánh giá hiệu suất của ứng dụng trong các điều kiện sử dụng khác nhau.

Các chỉ số có thể được quan tâm gồm:

• Thời gian khởi động ứng dụng.

• Thời gian tải dữ liệu.

• Độ mượt của hoạt ảnh.

• Mức sử dụng CPU và RAM.

• Mức tiêu thụ pin.

• Dung lượng cài đặt.

• Khả năng xử lý danh sách dữ liệu lớn.

Đối với Flutter, nên sử dụng Profile Mode và các công cụ phân tích hiệu suất phù hợp để đo đạc trên thiết bị thực tế.

13.5. Network Testing

Ứng dụng di động thường phụ thuộc vào API và các dịch vụ bên ngoài. Vì vậy, kiểm thử mạng là một phần quan trọng trước khi phát hành.

Những trường hợp cần kiểm tra bao gồm:

• Mạng hoạt động bình thường.

• Mạng chậm.

• Mất kết nối giữa lúc gửi yêu cầu.

• API trả về lỗi máy chủ.

• Yêu cầu hết thời gian chờ.

• Token xác thực hết hạn.

• Người dùng gửi yêu cầu nhiều lần.

• Dữ liệu trả về không đúng định dạng dự kiến.

Ứng dụng cần cung cấp phản hồi phù hợp cho người dùng, tránh hiển thị màn hình trắng hoặc trạng thái tải vô hạn khi gặp sự cố.

14. CI/CD trong App Release & Deployment

CI/CD là phương pháp tự động hóa các bước tích hợp, kiểm thử, build và phát hành phần mềm. Đối với ứng dụng di động, CI/CD giúp giảm số thao tác thủ công, tăng khả năng tái lập quy trình và hạn chế những sai sót do cấu hình không nhất quán.

14.1. Continuous Integration (CI)

Continuous Integration là quá trình tích hợp các thay đổi mã nguồn thường xuyên vào một nhánh hoặc hệ thống quản lý mã nguồn chung, kết hợp với các bước kiểm tra tự động.

Một pipeline CI cho Flutter có thể bao gồm:

1. Lấy mã nguồn từ Git.

2. Thiết lập phiên bản Flutter phù hợp.

3. Tải dependency.

4. Chạy kiểm tra mã nguồn.

5. Chạy unit test.

6. Build ứng dụng.

7. Lưu kết quả và báo cáo kiểm thử.

Nếu một bước quan trọng thất bại, pipeline có thể dừng để nhóm phát triển xử lý lỗi trước khi tiếp tục.

14.2. Continuous Delivery

Continuous Delivery là cách tổ chức quy trình để phần mềm luôn có thể được chuẩn bị cho phát hành sau khi vượt qua các bước kiểm tra cần thiết.

Quá trình này có thể tự động hóa việc tạo artifact, lưu trữ gói build và chuẩn bị thông tin phát hành. Tuy nhiên, việc đưa phiên bản đến người dùng có thể vẫn yêu cầu người có thẩm quyền xác nhận.

14.3. Continuous Deployment

Continuous Deployment là hình thức tự động đưa các thay đổi đáp ứng điều kiện của pipeline vào môi trường đích mà không yêu cầu một bước phê duyệt thủ công cho từng lần triển khai.

Trong ứng dụng di động, cần phân biệt việc tự động build hoặc upload bản phát hành với việc tự động phân phối bản cập nhật đến toàn bộ người dùng. Các cửa hàng ứng dụng có quy trình xét duyệt và điều kiện phát hành riêng, nên không phải mọi thay đổi đều có thể được đưa đến người dùng ngay lập tức.

14.4. Ví dụ pipeline CI cho Flutter

Có thể sử dụng GitHub Actions để tự động kiểm tra mã nguồn khi có push hoặc pull request.

Tệp .github/workflows/flutter-ci.yml có thể được xây dựng như sau:

name: Flutter CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable

      - name: Install dependencies
        run: flutter pub get

      - name: Analyze code
        run: flutter analyze

      - name: Run tests
        run: flutter test

      - name: Build APK
        run: flutter build apk --release

Đây là ví dụ cơ bản minh họa cách tự động kiểm tra và build ứng dụng. Khi triển khai thực tế, nên cố định phiên bản Flutter, rà soát phiên bản của các GitHub Actions, quản lý dependency và bổ sung các bước kiểm tra phù hợp với dự án.

Pipeline trên chưa thực hiện ký ứng dụng bằng khóa phát hành, tải gói lên cửa hàng hoặc phát hành đến người dùng. Những công việc đó cần được cấu hình riêng, đi kèm cơ chế quản lý quyền truy cập và secret an toàn.

15. Deployment Strategy

Deployment Strategy là chiến lược triển khai phần mềm được lựa chọn nhằm giảm rủi ro và bảo đảm quá trình đưa phiên bản mới vào sử dụng diễn ra có kiểm soát.

15.1. Direct Deployment

Direct Deployment là phương thức triển khai trực tiếp phiên bản mới đến môi trường mục tiêu.

Cách tiếp cận này phù hợp với dự án nhỏ, hệ thống nội bộ hoặc các thay đổi có phạm vi ảnh hưởng thấp.

Tuy nhiên, nếu phiên bản mới có lỗi nghiêm trọng, phạm vi ảnh hưởng có thể lớn. Vì vậy, ngay cả khi triển khai trực tiếp, nhóm phát triển vẫn cần có bước kiểm thử, giám sát và kế hoạch xử lý sự cố.

15.2. Staged Rollout

Staged Rollout triển khai phiên bản đến một phần người dùng trước khi mở rộng phạm vi.

Phương pháp này phù hợp với ứng dụng di động khi nền tảng phân phối hỗ trợ. Nhóm phát triển có thể theo dõi lỗi, đánh giá phản hồi và quyết định tiếp tục hoặc tạm dừng triển khai theo các điều kiện đã xác định.

15.3. Canary Deployment

Canary Deployment là phương pháp đưa phiên bản mới đến một nhóm nhỏ người dùng hoặc một phần lưu lượng trước khi triển khai rộng rãi.

Chiến lược này thường được sử dụng cho backend và các hệ thống có khả năng điều phối lưu lượng.

Ví dụ, một API mới có thể được cung cấp cho một tỷ lệ nhỏ lưu lượng. Nếu các chỉ số ổn định, hệ thống tiếp tục mở rộng phạm vi. Nếu xuất hiện lỗi vượt ngưỡng, nhóm vận hành có thể dừng triển khai và chuyển lưu lượng trở lại phiên bản cũ.

15.4. Blue-Green Deployment

Blue-Green Deployment sử dụng hai môi trường triển khai có khả năng phục vụ cùng một ứng dụng.

• Blue là môi trường đang phục vụ phiên bản hiện tại.

• Green là môi trường được chuẩn bị cho phiên bản mới.

Sau khi kiểm tra môi trường Green, hệ thống có thể chuyển lưu lượng sang phiên bản mới. Nếu xảy ra sự cố, lưu lượng có thể được chuyển về Blue khi các điều kiện kỹ thuật cho phép.

Phương pháp này thường phù hợp với backend và hạ tầng có khả năng duy trì hai môi trường. Nó không phải là cơ chế khôi phục trực tiếp cho ứng dụng di động đã được cài trên thiết bị người dùng.

16. Triển khai Backend và phối hợp với ứng dụng di động

Trong nhiều dự án, ứng dụng di động không hoạt động độc lập mà phụ thuộc vào backend để xác thực người dùng, xử lý nghiệp vụ và lưu trữ dữ liệu.

Vì vậy, phát hành ứng dụng cần được phối hợp với quá trình triển khai backend.

16.1. Quản lý API Endpoint

Bản release cần sử dụng đúng API endpoint của môi trường production. Cần tránh các địa chỉ chỉ hoạt động trên máy lập trình viên, chẳng hạn localhost, vì địa chỉ này trên thiết bị di động thường trỏ đến chính thiết bị chứ không phải máy tính đang chạy backend.

Nhóm phát triển cũng cần xác minh DNS, HTTPS, chứng chỉ TLS, cấu hình CORS khi có liên quan và khả năng kết nối từ mạng thực tế.

16.2. Tương thích giữa phiên bản ứng dụng và backend

Một ứng dụng đã phát hành có thể tiếp tục được người dùng sử dụng trong nhiều tháng hoặc nhiều năm. Vì vậy, backend không thể giả định rằng tất cả người dùng đều đã cập nhật lên phiên bản ứng dụng mới nhất.

Các nguyên tắc nên áp dụng gồm:

• Duy trì khả năng tương thích ngược khi phù hợp.

• Tránh xóa hoặc đổi tên API đang được sử dụng mà không có kế hoạch chuyển đổi.

• Kiểm thử tương thích giữa ứng dụng cũ và backend mới.

• Có chiến lược thông báo khi ứng dụng cần nâng cấp bắt buộc.

• Triển khai thay đổi cơ sở dữ liệu theo từng bước an toàn.

16.3. Database Migration

Database Migration là quá trình thay đổi cấu trúc hoặc dữ liệu của cơ sở dữ liệu theo yêu cầu của phiên bản mới.

Một migration có thể thêm cột, tạo bảng, bổ sung chỉ mục hoặc thay đổi cách lưu trữ dữ liệu. Nếu thực hiện không đúng, quá trình triển khai có thể làm gián đoạn dịch vụ hoặc gây mất dữ liệu.

Trước các migration quan trọng, cần đánh giá tác động, sao lưu phù hợp và xác định cách khôi phục. Với hệ thống đang vận hành, nên ưu tiên các thay đổi có khả năng tương thích với phiên bản ứng dụng đang được sử dụng.

17. Bảo mật trong quá trình Release & Deployment

Bảo mật cần được xem xét xuyên suốt quá trình phát triển và phát hành, không chỉ ở bước kiểm tra cuối cùng.

17.1. Quản lý Secret

Secret có thể bao gồm API key, private key, token, mật khẩu dịch vụ hoặc thông tin xác thực dùng trong hệ thống build và triển khai.

Những thông tin này cần được lưu trữ trong hệ thống quản lý secret phù hợp. Không nên ghi trực tiếp secret vào mã nguồn, tệp cấu hình công khai hoặc log của pipeline.

Đặc biệt, ứng dụng di động là phần mềm được phân phối đến thiết bị người dùng. Vì vậy, không thể xem những giá trị được nhúng vào binary là bí mật tuyệt đối.

Các khóa có quyền truy cập cao nên được giữ ở backend hoặc hệ thống bảo mật chuyên dụng, thay vì phân phối trực tiếp trong ứng dụng client.

17.2. HTTPS và TLS

Ứng dụng production nên sử dụng HTTPS để bảo vệ dữ liệu truyền giữa ứng dụng và máy chủ.

Nhóm phát triển cần kiểm tra chứng chỉ TLS, cấu hình máy chủ và cách ứng dụng xử lý lỗi kết nối bảo mật. Không nên vô hiệu hóa xác minh chứng chỉ chỉ để khắc phục lỗi kết nối trong môi trường phát hành.

17.3. Bảo vệ dữ liệu người dùng

Các dữ liệu như thông tin tài khoản, token đăng nhập, thông tin cá nhân và dữ liệu nghiệp vụ cần được xử lý theo nguyên tắc tối thiểu hóa dữ liệu.

Ứng dụng nên lưu thông tin xác thực bằng cơ chế phù hợp với nền tảng, chẳng hạn Keychain trên iOS hoặc Android Keystore thông qua các thư viện phù hợp. Không nên lưu mật khẩu hoặc token nhạy cảm dưới dạng văn bản thuần trong vùng lưu trữ không an toàn.

17.4. Kiểm tra dependency và artifact

Trước khi phát hành, nhóm phát triển nên kiểm tra các thư viện phụ thuộc, nguồn gốc của artifact và quyền truy cập vào pipeline.

Nếu pipeline bị xâm phạm hoặc dependency độc hại được đưa vào dự án, bản phát hành có thể chứa mã không mong muốn. Vì vậy, việc quản lý dependency và bảo vệ quy trình build cũng là một phần của bảo mật chuỗi cung ứng phần mềm.

18. Monitoring và xử lý sự cố sau phát hành

Quá trình Release & Deployment không kết thúc ngay sau khi người dùng cài đặt ứng dụng. Sau khi phát hành, nhóm phát triển cần theo dõi hoạt động của ứng dụng để phát hiện lỗi và đánh giá chất lượng phiên bản mới.

18.1. Crash Reporting

Crash Reporting giúp ghi nhận thông tin về những lần ứng dụng bị đóng bất thường.

Các hệ thống như Firebase Crashlytics có thể hỗ trợ thu thập báo cáo lỗi, stack trace và thông tin phiên bản để lập trình viên xác định nguyên nhân.

Khi sử dụng hệ thống báo cáo lỗi, cần hạn chế thu thập dữ liệu nhạy cảm không cần thiết và cấu hình quyền truy cập phù hợp.

18.2. Performance Monitoring

Performance Monitoring giúp theo dõi các chỉ số như thời gian phản hồi, độ trễ mạng và những vấn đề hiệu suất.

Đối với ứng dụng phụ thuộc vào API, việc theo dõi thời gian phản hồi có thể giúp xác định liệu sự cố đến từ ứng dụng, mạng hay backend.

18.3. Phân tích mức độ ổn định

Nhóm phát triển có thể theo dõi các chỉ số như:

• Tỷ lệ người dùng gặp crash.

• Số lượng lỗi theo phiên bản.

• Thời gian khởi động ứng dụng.

• Tỷ lệ yêu cầu API thất bại.

• Mức độ sử dụng các chức năng chính.

• Phản hồi và đánh giá của người dùng.

Các chỉ số cần được lựa chọn theo đặc thù dự án. Không nên chỉ nhìn vào số lượt tải ứng dụng mà bỏ qua chất lượng trải nghiệm thực tế.

18.4. Xử lý sự cố production

Khi phát hiện lỗi nghiêm trọng, nhóm phát triển cần xác định mức độ ảnh hưởng, khoanh vùng nguyên nhân và lựa chọn phương án khắc phục.

Đối với backend, có thể tạm dừng triển khai, chuyển lưu lượng về phiên bản ổn định hoặc thực hiện rollback nếu kiến trúc cho phép.

Đối với ứng dụng di động, không phải lúc nào cũng có thể thu hồi tức thì phiên bản đã cài đặt trên thiết bị người dùng. Nhóm phát triển có thể cần phát hành bản sửa lỗi, tạm dừng rollout hoặc sử dụng cơ chế vô hiệu hóa tính năng từ xa nếu đã được thiết kế an toàn.

19. Rollback và Hotfix

Rollback và Hotfix là hai phương án xử lý thường gặp khi phiên bản mới phát sinh sự cố.

19.1. Rollback

Rollback là quá trình quay lại phiên bản hoặc trạng thái triển khai trước đó khi phiên bản mới không đáp ứng yêu cầu vận hành.

Rollback thường dễ thực hiện hơn với backend có nhiều phiên bản triển khai và cơ chế điều phối lưu lượng. Tuy nhiên, việc quay lại phiên bản cũ cần xem xét khả năng tương thích với dữ liệu đã được thay đổi.

Đối với ứng dụng di động, rollback không đồng nghĩa với việc tự động hạ cấp ứng dụng trên mọi thiết bị. Người dùng có thể đã cài bản mới, trong khi cửa hàng ứng dụng và nền tảng hệ điều hành có các quy tắc riêng về cập nhật.

19.2. Hotfix

Hotfix là bản sửa lỗi được ưu tiên phát hành nhằm xử lý một vấn đề quan trọng mà không cần chờ chu kỳ phát hành tính năng tiếp theo.

Một quy trình hotfix thường gồm:

1. Xác định lỗi và phạm vi ảnh hưởng.

2. Tạo nhánh sửa lỗi hoặc quy trình thay đổi phù hợp.

3. Sửa lỗi và kiểm thử.

4. Tạo bản build mới.

5. Cập nhật version hoặc build number khi cần.

6. Phát hành qua kênh phù hợp.

7. Theo dõi kết quả sau khi triển khai.

Hotfix cần được thực hiện nhanh nhưng vẫn phải có kiểm soát. Việc bỏ qua toàn bộ bước kiểm thử có thể khiến bản sửa lỗi tạo ra vấn đề nghiêm trọng hơn.

20. Những lỗi thường gặp trong App Release & Deployment

20.1. Sai API Endpoint

Ứng dụng vẫn sử dụng API development sau khi phát hành, khiến dữ liệu không chính xác hoặc các chức năng chính không hoạt động.

Cách khắc phục: quản lý cấu hình theo môi trường, kiểm tra giá trị thực tế trong bản build và xác minh API production trước khi phát hành.

20.2. Sai Version hoặc Build Number

Bản phát hành có version hoặc build number không đáp ứng yêu cầu của cửa hàng ứng dụng.

Cách khắc phục: thiết lập quy tắc tăng phiên bản rõ ràng và xác minh thông tin trước khi tạo artifact.

20.3. Lỗi ký ứng dụng

Ứng dụng không thể được cài đặt, cập nhật hoặc tải lên cửa hàng do cấu hình chữ ký không hợp lệ.

Cách khắc phục: kiểm tra khóa ký, chứng thư, cấu hình Gradle hoặc Xcode và quyền truy cập của hệ thống build.

20.4. Thiếu tài nguyên

Một số hình ảnh, font hoặc cấu hình không được đóng gói đúng cách khiến giao diện bị lỗi trong bản release.

Cách khắc phục: kiểm tra khai báo tài nguyên, build release và xác minh ứng dụng trên thiết bị thực tế.

20.5. Lỗi chỉ xuất hiện trong Release Mode

Ứng dụng chạy bình thường khi debug nhưng bị lỗi trong bản release do khác biệt cấu hình, tối ưu hóa hoặc dependency.

Cách khắc phục: kiểm thử bản release trước khi phân phối và sử dụng crash reporting để thu thập thông tin khi có lỗi.

20.6. Không có kế hoạch xử lý sự cố

Nhóm phát triển phát hiện lỗi sau khi phát hành nhưng không có phương án khoanh vùng, sửa lỗi hoặc khôi phục.

Cách khắc phục: chuẩn bị quy trình incident response, thiết lập theo dõi lỗi và xác định trước cách xử lý theo mức độ nghiêm trọng.

21. Quy trình App Release & Deployment hoàn chỉnh cho dự án Flutter

Để áp dụng kiến thức vào thực tế, có thể tổ chức quy trình phát hành một ứng dụng Flutter theo các giai đoạn sau.

Đối với dự án nhỏ, một phần quy trình có thể được thực hiện thủ công. Khi dự án phát triển lớn hơn, việc tự động hóa bằng CI/CD giúp giảm công việc lặp lại, tăng tính nhất quán và hỗ trợ truy vết các bản phát hành.

22. Kinh nghiệm xây dựng quy trình Release chuyên nghiệp

Một quy trình Release & Deployment hiệu quả không nhất thiết phải phức tạp. Điều quan trọng là quy trình phù hợp với quy mô dự án và có đủ cơ chế kiểm soát các rủi ro quan trọng.

Một số nguyên tắc nên áp dụng:

• Chuẩn hóa quy trình: xác định rõ các bước build, test, ký và phát hành.

• Tự động hóa hợp lý: tự động hóa những thao tác lặp lại và dễ xảy ra sai sót.

• Quản lý phiên bản rõ ràng: liên kết bản phát hành với commit và build tương ứng.

• Bảo vệ thông tin nhạy cảm: kiểm soát quyền truy cập vào secret và khóa ký.

• Kiểm thử bản Release: không chỉ dựa vào kết quả chạy debug.

• Theo dõi sau phát hành: xác định cách phát hiện và đánh giá sự cố.

• Chuẩn bị phương án khắc phục: có quy trình hotfix, rollback hoặc dừng rollout phù hợp.

• Ghi nhận kinh nghiệm: lưu lại vấn đề phát sinh và cải thiện quy trình ở lần tiếp theo.

Ngoài ra, không nên xem việc ứng dụng xuất hiện trên Google Play hoặc App Store là dấu hiệu duy nhất chứng minh quá trình phát hành đã thành công. Một bản release tốt cần hoạt động ổn định, đáp ứng yêu cầu bảo mật và mang lại trải nghiệm phù hợp cho người dùng.

23. Kết luận

App Release & Deployment là giai đoạn đưa phần mềm từ quá trình phát triển đến môi trường sử dụng thực tế. Quy trình này bao gồm việc chuẩn bị mã nguồn, quản lý phiên bản, cấu hình môi trường, build ứng dụng, ký gói phát hành, kiểm thử, phân phối và theo dõi sau khi triển khai.

Đối với lập trình viên Flutter, kiến thức về APK, AAB, IPA, signing, versioning, Google Play, App Store và CI/CD là nền tảng quan trọng để hoàn thiện kỹ năng phát triển ứng dụng di động.

Khi xây dựng được một quy trình phát hành rõ ràng, nhóm phát triển có thể giảm lỗi do thao tác thủ công, tăng khả năng truy vết, cải thiện độ ổn định và xử lý sự cố hiệu quả hơn. Đây không chỉ là bước cuối cùng của quá trình lập trình mà còn là một phần thiết yếu trong việc duy trì và phát triển sản phẩm phần mềm lâu dài.