GitHub Actions — nó là gì, đường ống CI/CD và tự động hóa

GitHub Actions là gì?

GitHub Actions là nền tảng tự động hóa quy trình làm việc được tích hợp trong GitHub và ra mắt vào năm 2019. Nó cho phép bạn xác định các đường ống CI/CD trong các tệp YAML được lưu trữ trực tiếp trong kho lưu trữ. Mỗi workflow được kích hoạt bởi một sự kiện: push, pull request, tạo thẻ hoặc theo lịch trình. Không như Jenkins hay TeamCity, không cần cơ sở hạ tầng riêng để lưu trữ máy chủ CI.

Trong bối cảnh phát triển di động, GitHub Actions tự động hóa việc xây dựng APK và IPA, chạy kiểm thử đơn vị và kiểm thử UI trên trình giả lập, kiểm tra mã nguồn bằng lint, ký và xuất bản lên Google Play và App Store. Nền tảng cung cấp phút miễn phí cho các kho lưu trữ công khai và cho riêng tư tùy theo gói cước. Đối với các dự án di động mã nguồn mở, đây là giải pháp CI/CD hoàn chỉnh mà không tốn chi phí.

Kiến trúc GitHub Actions: Workflows, Jobs và Steps

Kiến trúc GitHub Actions bao gồm bốn cấp độ. Workflow là tệp YAML gốc xác định tự động hóa. Workflow bao gồm các Jobs, mỗi Job chạy trên một Runner riêng. Bên trong Job, các Steps được thực thi — các lệnh tuần tự hoặc các hành động bên ngoài. Events xác định các trình kích hoạt: push, pull_request, schedule, workflow_dispatch. Một workflow cũng có thể được kích hoạt thủ công qua tab Actions trong giao diện GitHub.

GitHub cung cấp các runner được lưu trữ với hệ điều hành được cài đặt sẵn: Ubuntu, macOS và Windows. Đối với xây dựng iOS, bắt buộc phải có runner macOS, đối với Android — Linux hoặc macOS. Các self-hosted runner cho phép bạn chạy các công việc trên máy chủ riêng với môi trường tùy chỉnh, hữu ích cho các dự án lớn với yêu cầu phần cứng đặc biệt. GitHub cũng hỗ trợ các nhóm self-hosted runner để tổ chức hàng đợi thực thi công việc.

Cấu trúc tệp workflow

Một tệp workflow cơ bản chứa các phần: name, on (trình kích hoạt), jobs. Mỗi công việc chỉ định runs-on (loại runner), strategy (ma trận), steps (danh sách hành động). Steps có thể là lệnh shell hoặc các hành động có sẵn từ chợ, được kết nối qua cú pháp owner/repo@version.

Xây dựng ứng dụng di động trong GitHub Actions

Đối với xây dựng Android, một workflow thường bao gồm các bước: checkout kho lưu trữ, cài đặt JDK, cấu hình bộ nhớ đệm Gradle, chạy assembleRelease. Đối với iOS cần có runner macOS, cài đặt Xcode qua xcode-select, giải quyết provisioning profile và chạy xcodebuild. Sự phức tạp của xây dựng iOS nằm ở code signing và quản lý chứng chỉ. Cài đặt cụ thể cho Apple bao gồm quản lý provisioning profile qua apple-actions/import-codesign-certs.

Matrix strategy cho phép chạy xây dựng trên nhiều phiên bản cùng lúc. Ví dụ: ma trận với các phiên bản iOS (15.0, 16.0, 17.0) và Xcode (14, 15). Điều này tăng tốc xác minh tính tương thích của ứng dụng với các phiên bản OS khác nhau, mặc dù làm tăng mức tiêu thụ phút của runner. Đối với các dự án có ngân sách CI hạn chế, ma trận có thể được giới hạn ở các cấu hình chính.

Thiết lập môi trường cho Android

GitHub Actions cung cấp hành động setup-java để cài đặt JDK và caching để lưu trữ đệm Gradle. Android SDK đã được cài đặt sẵn trên các runner Ubuntu. Đối với các cấp độ API tùy chỉnh, sdkmanager được sử dụng trong một bước riêng. Nên tạo các workflow riêng biệt cho xây dựng Android và iOS vì chúng sử dụng các runner và công cụ xây dựng khác nhau.

GitHub Marketplace và các hành động có sẵn

GitHub Marketplace chứa hơn 15.000 hành động được tạo bởi cộng đồng và các nhà phát triển chính thức. Đối với phát triển di động, các danh mục chính bao gồm: Code signing (apple-actions/import-codesign-certs), kiểm thử (react-native-community/action), triển khai (google-github-actions/release-google-play), thông báo (slackapi/slack-github-action). Các hành động cho Firebase App Distribution, tải lên TestFlight và Fastlane cũng có sẵn. Mỗi hành động có nhãn tương thích với một hệ điều hành runner cụ thể.

Mỗi hành động có phiên bản, mô tả, README và giấy phép. Khi chọn hành động, nên ưu tiên các hành động chính thức từ nhà cung cấp (Google, Apple, Microsoft) và đã được xác minh qua Verified Badge. Điều quan trọng là chỉ định phiên bản chính cố định (actions/checkout@v4), không phải @main, để tránh các thay đổi bất ngờ. Nếu hành động cần thiết không có trong Marketplace, bạn có thể tạo một hành động tùy chỉnh — cục bộ trong kho lưu trữ (Docker action hoặc JavaScript action) hoặc xuất bản lên Marketplace.

Các hành động phổ biến cho CI/CD di động

• actions/checkout — sao chép kho lưu trữ vào runner
• actions/setup-java — cài đặt JDK cho xây dựng Android
• gradle/actions/setup-gradle — cấu hình và lưu trữ đệm Gradle
• apple-actions/import-codesign-certs — nhập chứng chỉ cho iOS
• google-github-actions/submit-release — xuất bản lên Google Play Console

Ví dụ workflow cho dự án iOS

Khi phát triển ứng dụng iOS, điều quan trọng là thiết lập hoạt động chính xác với các trình giả lập và thiết bị. Runner macOS-14 cung cấp môi trường với Rosetta 2 để chạy các bản dựng Intel trên kiến trúc ARM. Một workflow có thể bao gồm nhiều lược đồ xây dựng — Debug cho pull request và Release cho thẻ. GitHub Actions hỗ trợ phân tích xcresult thông qua hành động xcparse/sonarqube để hiển thị kết quả kiểm thử. Để gửi thông báo trạng thái xây dựng, có thể thêm hành động Slack hoặc Telegram.

Code signing cho iOS yêu cầu nhập chứng chỉ và provisioning profile. Apple-actions cung cấp một bước để nhập chứng chỉ P12 và cài đặt provisioning profile. Chứng chỉ được lưu trữ dưới dạng secrets GitHub Actions và chỉ được giải mã ở giai đoạn xây dựng. Để tự động hóa ký, Fastlane match được sử dụng, có thể được gọi như một bước riêng trong workflow.

Hãy xem xét một workflow cho ứng dụng iOS bằng Swift, nó xây dựng dự án, chạy kiểm thử và tạo một bản dựng được lưu trữ. Workflow sử dụng runner macOS-14, Xcode 15.4 và các hành động để quản lý chứng chỉ.

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

Lưu trữ đệm phụ thuộc trong GitHub Actions

Lưu trữ đệm giảm thời gian xây dựng bằng cách giữ lại các phụ thuộc giữa các lần chạy workflow. GitHub cung cấp bộ nhớ đệm tích hợp qua actions/cache. Đối với Gradle, ~/.gradle được lưu vào bộ nhớ đệm, đối với CocoaPods — Pods/, đối với SPM — .build/. Khóa bộ nhớ đệm bao gồm băm của tệp danh sách phụ thuộc — khi phụ thuộc thay đổi, bộ nhớ đệm tự động bị vô hiệu hóa.

Cần đặc biệt chú ý đến chiến lược khôi phục bộ nhớ đệm (restore-keys). Nếu không tìm thấy khóa chính xác, GitHub Actions thử khớp một phần qua restore-keys. Điều này hữu ích khi chỉ một phụ thuộc thay đổi — bộ nhớ đệm vẫn có thể sử dụng một phần. Đối với Gradle, nên bật thêm Gradle Build Cache, nó lưu trữ đệm kết quả xây dựng giữa các mô-đun khác nhau của dự án.

Ví dụ lưu trữ đệm Gradle

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

Hiệu quả bộ nhớ đệm cho các dự án Android: lần xây dựng đầu tiên không có bộ nhớ đệm — 8–12 phút, lần tiếp theo có bộ nhớ đệm — 2–4 phút. Đối với iOS với CocoaPods, mức tiết kiệm tương tự. Nên kết hợp actions/cache với hành động setup-gradle từ Gradle để quản lý bộ nhớ đệm tối ưu. Đối với các phụ thuộc npm trong React Native, actions/cache được sử dụng với băm package-lock.json. Với cấu hình bộ nhớ đệm phù hợp, thời gian xây dựng có thể giảm tới 70%.

GitHub Actions hỗ trợ các biến môi trường ở cấp độ workflow, job và step. Các biến môi trường có thể được ghi đè: cấp độ step có ưu tiên cao nhất. Đối với dữ liệu bảo mật, luôn sử dụng secrets — chúng được mã hóa bằng AES-256 và không hiển thị trong nhật ký. Các quy tắc bảo vệ môi trường cũng có sẵn — phê duyệt thủ công bắt buộc trước khi triển khai. Để bảo mật bổ sung, có thể cấu hình phê duyệt bắt buộc từ người dùng hoặc nhóm cụ thể.

GitHub Actions cũng hỗ trợ Reusable Workflows — các đường ống có thể tái sử dụng có thể được gọi từ các workflow khác. Điều này cho phép tạo một workflow xây dựng tập trung và tái sử dụng nó trong tất cả các kho lưu trữ của tổ chức. Reusable workflow được gọi bằng một dòng và có thể chấp nhận các tham số đầu vào và secrets. Điều này đặc biệt hữu ích để chuẩn hóa các thực hành CI/CD trong các nhóm lớn.

Bảo mật và các thực hành tốt nhất

Khi cấu hình GitHub Actions cho các dự án di động, điều quan trọng là tuân theo các nguyên tắc bảo mật. OIDC (OpenID Connect) cho phép bạn loại bỏ thông tin xác thực tồn tại lâu dài và nhận mã thông báo tạm thời cho các nhà cung cấp đám mây. Không bao giờ sử dụng secrets dưới dạng văn bản thuần túy trong tập lệnh — GitHub Actions tự động che giấu secrets trong nhật ký.

Đối với các dự án di động, điều quan trọng là hạn chế quyền truy cập workflow cho các fork bên thứ ba. Sử dụng cài đặt pull_request_target một cách thận trọng — nó thực thi mã từ nhánh cơ sở, không phải từ fork. Đối với code signing ứng dụng iOS, nên lưu trữ chứng chỉ ở dạng mã hóa và chỉ giải mã chúng ở giai đoạn xây dựng qua gpg hoặc openssl.