Continuous Delivery (CD): nó là gì, khác biệt với Continuous Deployment

Continuous Delivery là gì

Continuous Delivery (CD) là một phần mở rộng của Continuous Integration, thêm tự động hóa cho tất cả các giai đoạn chuẩn bị phát hành: xây dựng bản dựng release, ký bằng chứng chỉ, làm rối, xác minh siêu dữ liệu cửa hàng ứng dụng và triển khai lên môi trường staging. Thuật ngữ này được Jez Humble và David Farley giới thiệu trong cuốn sách “Continuous Delivery” (2010), nơi họ chính thức hóa thực hành cho phép các nhóm làm cho việc phát hành có thể dự đoán trước và ít rủi ro.

Sự tiến hóa của phân phối phần mềm

Trước khi áp dụng CD, việc phát hành là một sự kiện: nhóm tập trung trong một phòng, thực hiện danh sách kiểm tra 20 mục, chạy tập lệnh thủ công và hy vọng không có gì hỏng hóc. Continuous Delivery biến việc phát hành từ một sự kiện thành một quy trình: một thay đổi nhỏ trong mã nguồn có thể được gửi đến người dùng trong vài phút, không phải vài tuần. Amazon, Netflix và Etsy là những công ty đầu tiên áp dụng CD vào những năm 2010 — ngày nay nó là tiêu chuẩn cho các nhóm sản phẩm.

Giá trị kinh doanh của CD

Phân phối tính năng nhanh chóng là một lợi thế cạnh tranh. Nếu đối thủ cạnh tranh phát hành chức năng mới trong vài ngày trong khi bạn mất vài tháng, thị trường sẽ chọn đối thủ cạnh tranh. Các chỉ số DORA cho thấy: các nhóm elite (có CD) có thời gian triển khai dưới 1 giờ, các nhóm thấp (không có CD) — từ 1 tuần đến 1 tháng. CD cũng giảm thiểu rủi ro một cách triệt để: những thay đổi nhỏ khó làm hỏng hơn một bản phát hành lớn hàng quý.

CD vs CI vs Continuous Deployment

Các thuật ngữ CI, CD và Continuous Deployment thường bị nhầm lẫn, nhưng có một ranh giới rõ ràng giữa chúng. Hiểu được sự khác biệt giúp thiết kế pipeline đúng cách và chọn mức độ tự động hóa phù hợp với độ chín của nhóm và yêu cầu kinh doanh.

Continuous Integration

CI là nền tảng mà CD được xây dựng trên đó. CI đảm bảo rằng mọi commit đều trải qua quá trình xây dựng và kiểm thử. Nếu không có CI, CD là không thể: nếu mã nguồn không được xác minh, nó không thể được phát hành. CI xác minh tính đúng đắn, CD xác minh sự sẵn sàng cho sử dụng kinh doanh.

Continuous Delivery

CD thêm vào CI các giai đoạn xây dựng bản dựng release, xác minh siêu dữ liệu, ký và triển khai lên môi trường staging hoặc cửa hàng ứng dụng để kiểm thử beta. Sự khác biệt chính — quyết định phát hành ra môi trường sản xuất do một người (quản lý, chủ sở hữu sản phẩm) đưa ra. CD làm cho việc phát hành “chỉ cách một cú nhấp chuột” — đơn giản và an toàn.

Continuous Deployment

Continuous Deployment là tự động hóa hoàn toàn: mọi thay đổi vượt qua tất cả các giai đoạn của pipeline CD sẽ tự động được gửi đến môi trường sản xuất mà không cần phê duyệt thủ công. Continuous Deployment có thể áp dụng cho các sản phẩm SaaS và dịch vụ web, nhưng hiếm khi được sử dụng trong phát triển di động do chính sách của cửa hàng ứng dụng (App Store Review, Google Play Review yêu cầu gửi thủ công).

Continuous Delivery cho ứng dụng di động

CD cho ứng dụng di động có các đặc điểm phân biệt nó với các pipeline web và backend. Các bản phát hành di động phải đi qua các cửa hàng ứng dụng (App Store Review, Google Play Review), điều này thêm một rào cản về thời gian và quy trình. CD tự động hóa mọi thứ có thể tự động hóa trước khi gửi đi xem xét để tối đa hóa cơ hội vượt qua xác minh ngay lần đầu tiên.

Chuẩn bị xuất bản trên Google Play

Pipeline CD Android bao gồm: xây dựng AAB (Android App Bundle), ký bằng khóa release, làm rối qua R8/ProGuard, kiểm tra kích thước APK và các lớp multidex, tạo ghi chú phát hành. Sử dụng product flavors của Gradle (free/paid, dev/staging/prod) cho phép quản lý nhiều cấu hình từ một pipeline duy nhất.

Chuẩn bị xuất bản trên App Store

CD iOS yêu cầu ký bằng chứng chỉ qua Fastlane match, kiểm tra tuân thủ biểu tượng (yêu cầu của App Store — 1024×1024 px), xác thực siêu dữ liệu (tên, mô tả, từ khóa), kiểm tra không có API riêng tư. Xác thực kỹ thuật được thực hiện qua altool --validate-app mà không tải lên App Store Connect, cung cấp phản hồi nhanh chóng.

# Fastfile — pipeline CD hoàn chỉnh cho iOS và Android
platform :ios do
  desc "CD iOS — chuẩn bị phát hành và tải lên TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "CD Android — xây dựng AAB và tải lên Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight thu thập ảnh chụp màn hình, lấy chứng chỉ qua match, xây dựng IPA và tải lên TestFlight. Lane deliver_to_internal cho Android xây dựng Release AAB qua Gradle và tải nó lên đường ray nội bộ của Google Play Console. Cả hai pipeline đều chạy từ CI sau khi vượt qua các bài kiểm thử.

Các thành phần của pipeline CD

Pipeline CD bao gồm các giai đoạn tuần tự, mỗi giai đoạn thêm sự tin tưởng rằng bản phát hành đã sẵn sàng cho người dùng. Các giai đoạn được chia thành kỹ thuật (xây dựng, ký) và sản phẩm (siêu dữ liệu, ảnh chụp màn hình, xác minh mô tả). Bỏ qua bất kỳ giai đoạn nào làm tăng nguy cơ bản phát hành bị từ chối bởi cửa hàng ứng dụng.

Quản lý phiên bản

Một thành phần quan trọng của CD là quản lý phiên bản tự động. Tăng phiên bản (versionCode và versionName cho Android, CFBundleVersion và CFBundleShortVersionString cho iOS) được thực hiện dựa trên thẻ Git hoặc phiên bản trước đó trong cửa hàng. Fastlane increment_version_number và các lệnh Gradle (versionCode auto-increment) tự động hóa bước này.

Siêu dữ liệu cửa hàng

Google Play Console và App Store Connect yêu cầu: mô tả ứng dụng, từ khóa, danh mục, xếp hạng, liên kết chính sách bảo mật. CD bao gồm việc kiểm tra sự hiện diện và tính chính xác của siêu dữ liệu. Fastlane deliver và supply tự động hóa việc tải lên mô tả, ảnh chụp màn hình và biểu tượng cùng với bản dựng.

Kiểm tra cổng

Trước khi gửi đi xem xét, pipeline thực hiện kiểm tra cổng: kiểm tra kích thước bản dựng (APK > 200 MB bị Google Play từ chối), sự hiện diện của tất cả bản địa hóa, không có ký hiệu gỡ lỗi trong bản dựng release, kiểm tra tệp ánh xạ ProGuard để giải mã nhật ký sự cố. Nếu bất kỳ kiểm tra nào thất bại — pipeline sẽ chặn bản phát hành.

Kiểm thử tự động cho CD

Mức độ tin cậy vào CD tỷ lệ thuận với chất lượng của các bài kiểm thử tự động. Nếu kiểm thử không phát hiện hồi quy — bản phát hành có thể làm hỏng môi trường sản xuất và nhóm mất niềm tin vào CD. CD di động yêu cầu một kim tự tháp kiểm thử ba cấp được điều chỉnh phù hợp với đặc thù của nền tảng.

Kiểm thử đơn vị

Kiểm thử đơn vị xác minh logic kinh doanh một cách độc lập. Độ bao phủ mã nguồn nên ít nhất 70% cho các mô-đun quan trọng (xác thực, thanh toán, mạng). CI chạy kiểm thử đơn vị trên mỗi lần đẩy, và nếu chúng thất bại — pipeline CD sẽ bị chặn cho đến khi được sửa.

Kiểm thử tích hợp

Chúng xác minh sự tương tác của các thành phần: lớp mạng với API thực (hoặc máy chủ giả), cơ sở dữ liệu, hệ thống tệp. Kiểm thử Room DAO cho Android, kiểm thử Core Data cho iOS là các ví dụ về kiểm thử tích hợp. Chúng chậm hơn kiểm thử đơn vị (1–5 phút) và được thực thi ở giai đoạn CD, không phải CI trên mỗi commit.

Kiểm thử giao diện và ảnh chụp màn hình

Kiểm thử ảnh chụp màn hình (snapshot testing) so sánh màn hình ứng dụng với hình ảnh tham chiếu. Nếu một thay đổi mã nguồn làm thay đổi giao diện — kiểm thử thất bại và nhà phát triển kiểm tra xem thay đổi có được mong đợi hay không. Android hỗ trợ Roborazzi và Paparazzi, iOS — SnapshotTesting của Point-Free. Kiểm thử ảnh chụp màn hình được thực thi trước khi phát hành như một phần của pipeline CD.

Các thực hành tốt nhất cho Continuous Delivery

Việc triển khai Continuous Delivery không chỉ đòi hỏi công cụ mà còn cần sự thay đổi trong văn hóa nhóm. Các thực hành dưới đây dựa trên nhiều năm kinh nghiệm của các nhóm di động tại Google, Spotify và Uber và được điều chỉnh cho các dự án ở mọi quy mô.

Feature Flags

Mã nguồn của tính năng mới được gửi đến môi trường sản xuất nhưng ẩn sau một cờ. Feature flags cho phép triển khai mã nguồn trước khi tính năng sẵn sàng cho người dùng và vô hiệu hóa ngay lập tức khi có sự cố. Thư viện: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags là yêu cầu bắt buộc cho CD trong các dự án di động.

Môi trường staging

Trước khi gửi đến môi trường sản xuất, bản dựng được triển khai lên staging — một môi trường giống hệt sản xuất nhưng với dữ liệu thử nghiệm. Các kỹ sư QA xác minh tính năng trên bản dựng staging được cài đặt qua TestFlight hoặc đường ray Internal Testing. Nếu staging vượt qua — bản dựng nhận được phê duyệt để gửi đi xem xét tại cửa hàng.

Ghi chú phát hành và changelog

CD tự động tạo ghi chú phát hành dựa trên thông điệp commit. Conventional Commits (feat:, fix:, chore:) và thẻ Git ở định dạng phiên bản ngữ nghĩa cho phép phân tích lịch sử thay đổi. Fastlane changelog_from_git_commits thu thập các thay đổi giữa hai thẻ cuối cùng và định dạng chúng cho cửa hàng ứng dụng.

Giám sát sau phát hành

CD không kết thúc với việc xuất bản — sau khi phát hành, việc giám sát bắt đầu: tỷ lệ sự cố, tỷ lệ ANR cho Android, thời gian khởi động, tỷ lệ thất bại thanh toán. Nếu các chỉ số vượt quá giới hạn bình thường — pipeline CD sẽ tự động hoàn tác bản phát hành hoặc thông báo cho nhóm. Công cụ: Firebase Crashlytics, Sentry, New Relic.

// Ví dụ về Feature Flag với Firebase Remote Config cho CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Sử dụng trong mã nguồn
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}