GitLab CI: pipeline và tích hợp liên tục

GitLab CI là gì?

GitLab CI là một phần của ứng dụng DevSecOps GitLab thống nhất, bao gồm tích hợp liên tục, phân phối và triển khai. Hệ thống bắt đầu như một dự án riêng biệt vào năm 2012 nhưng sau đó được tích hợp trực tiếp vào GitLab. Nguyên tắc cốt lõi là cấu hình dưới dạng mã (Configuration as Code) thông qua tệp .gitlab-ci.yml trong thư mục gốc kho lưu trữ. GitLab CI có sẵn cả phiên bản đám mây SaaS và bản cài đặt tự quản lý.

Đối với phát triển di động, GitLab CI cung cấp tự động hóa build APK và IPA, chạy kiểm thử có công cụ, phân tích mã tĩnh, ký ứng dụng và xuất bản lên cửa hàng. Nền tảng hỗ trợ hình ảnh Docker cho môi trường tùy chỉnh, cho phép cài đặt sẵn Android SDK, NDK, Xcode và các công cụ khác. Container Registry tích hợp giúp đơn giản hóa việc lưu trữ và phân phối hình ảnh trong nhóm.

Kiến trúc GitLab CI: Runners, Pipelines và Stages

Kiến trúc GitLab CI bao gồm ba thành phần chính. GitLab Runner là tác nhân thực thi các job. Runner có thể được chia sẻ (do GitLab cung cấp), nhóm (cho một nhóm dự án) hoặc cụ thể (cho một dự án). Mỗi runner được đăng ký với một executor: Shell, Docker, Kubernetes hoặc VirtualBox. GitLab Runner hỗ trợ tự động mở rộng quy mô để xử lý tải cao điểm.

Pipeline là tập hợp các stage thực thi tuần tự. Trong một stage, các job chạy song song. Cấu trúc điển hình cho dự án di động là: build → test → deploy. Nếu một job trong stage test thất bại, deploy sẽ không được kích hoạt. Có thể cấu hình kích hoạt thủ công (when: manual) cho việc triển khai. Bộ kích hoạt pipeline đa dự án cũng được hỗ trợ cho các kịch bản CI/CD phức tạp giữa các kho lưu trữ.

Executor của GitLab Runner

Executor Docker phổ biến nhất cho CI/CD ứng dụng di động. Mỗi job chạy trong một container Docker sạch, đảm bảo cách ly và khả năng tái tạo. Đối với build Android, sử dụng hình ảnh android-sdk với SDK được cài sẵn; đối với iOS, sử dụng runner macOS với executor Shell.

Cấu hình .gitlab-ci.yml cho dự án di động

Tệp .gitlab-ci.yml xác định pipeline ở định dạng YAML. Các phần chính bao gồm: image (hình ảnh Docker), stages (danh sách giai đoạn), variables (biến môi trường), before_script (lệnh trước mỗi job) và các job với phần script, artifacts, cache. GitLab CI hỗ trợ include — bao gồm các tệp YAML bên ngoài để tái sử dụng cấu hình chung giữa các dự án.

Các biến trong GitLab CI có thể được đặt ở nhiều cấp độ: toàn cục trong giao diện người dùng, trong tệp cấu hình, trong cài đặt nhóm và dự án. Mức ưu tiên biến tuân theo hệ thống phân cấp: biến kích hoạt có mức ưu tiên cao nhất, tiếp theo là biến CI/CD từ giao diện, sau đó từ .gitlab-ci.yml. Các biến có thể được bảo vệ, chỉ có thể truy cập được từ các nhánh và thẻ được bảo vệ.

Biến cơ bản và hình ảnh

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Job build với artifact

Job generate-apk xây dựng dự án Gradle và lưu APK dưới dạng artifact. Artifact được truyền giữa các stage — job deploy có thể sử dụng APK từ stage build. Thời gian lưu giữ artifact được cấu hình qua expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: khác biệt chính

Khi lựa chọn giữa GitLab CI và GitHub Actions cho dự án di động, cơ sở hạ tầng của nhóm là yếu tố chính. GitLab CI cung cấp Container Registry tích hợp để lưu trữ hình ảnh Docker với Android SDK. GitHub Actions phụ thuộc vào GitHub Packages hoặc các registry bên ngoài. GitLab cũng có SAST (Kiểm tra bảo mật ứng dụng tĩnh) tích hợp để phân tích lỗ hổng mã.

GitLab CI cung cấp mô hình runner linh hoạt hơn — hỗ trợ executor Kubernetes, tự động mở rộng quy mô và hình ảnh tùy chỉnh. GitHub Actions vượt trội về tích hợp hệ sinh thái GitHub và thị trường hành động. GitLab CI yêu cầu cấu hình thủ công nhiều hơn cho nhiều tác vụ mà GitHub Actions giải quyết bằng các hành động có sẵn.

Từ góc độ CI/CD di động: GitLab CI phù hợp hơn cho các công ty đã sử dụng GitLab Self-Managed và cần runner tự lưu trữ với Docker/Kubernetes. GitHub Actions thuận tiện hơn cho các nhóm nhỏ trên GitHub đám mây, coi trọng các hành động có sẵn và dễ cấu hình.

So sánh tính năng

Ví dụ pipeline cho dự án Android

Một pipeline Android hoàn chỉnh bao gồm: lint, kiểm thử đơn vị, build và triển khai lên Firebase App Distribution. Pipeline sử dụng hình ảnh Docker với Android SDK, bộ nhớ đệm Gradle và thực thi song song lint và test trong cùng một stage. Cách tiếp cận này giảm thời gian pipeline tổng thể vì các tác vụ lint và test độc lập với nhau.

Đối với dự án iOS, cấu trúc pipeline khác do yêu cầu runner macOS và ký mã. Một pipeline iOS điển hình bao gồm: cài đặt CocoaPods hoặc SPM, chạy kiểm thử trên trình mô phỏng, lưu trữ dự án Xcode, xuất IPA và tải lên TestFlight. GitLab CI cho iOS sử dụng runner macOS — hoặc runner SaaS GitLab macOS có giới hạn thời gian hoặc runner tự lưu trữ trên Mac Mini hoặc MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

Tối ưu hóa thời gian build trong GitLab CI

Tối ưu hóa pipeline build di động trong GitLab CI đòi hỏi sự chú ý đến chi tiết. Cấu hình phù hợp cache và artifacts có thể giảm thời gian build nhiều lần. Để phân tích hiệu suất, GitLab cung cấp CI/CD Analytics — bảng điều khiển với các chỉ số thời lượng pipeline, tải runner và điểm nghẽn. Phân tích các chỉ số này thường xuyên để tìm cơ hội tối ưu hóa. Cấu hình resource_group chặn chạy pipeline song song — hữu ích để ngăn xung đột triển khai.

Chiến lược nhánh cho CI cũng quan trọng. Khuyến nghị chạy pipeline đầy đủ chỉ cho nhánh main và release, và cho nhánh tính năng — chỉ chạy lint và kiểm thử đơn vị. Điều này tiết kiệm phút runner và tăng tốc phản hồi cho nhà phát triển. GitLab CI hỗ trợ workflow:rules — quy tắc có điều kiện để bao gồm hoặc loại trừ job dựa trên nhánh, tệp đã thay đổi hoặc biến môi trường.

Bộ nhớ đệm phụ thuộc là phương pháp tăng tốc chính. GitLab CI lưu vào bộ nhớ đệm .gradle, Pods và node_modules giữa các lần chạy. Khóa bộ nhớ đệm bao gồm $CI_COMMIT_REF_SLUG hoặc hàm băm tệp khóa. Thời gian build dự án Android giảm từ 10–15 xuống 2–4 phút với bộ nhớ đệm phù hợp. Bộ nhớ đệm có thể được phân phối — GitLab hỗ trợ cache:key với dự phòng về các khóa trước đó.

Hình ảnh Docker với các công cụ được cài đặt sẵn tiết kiệm thời gian cài đặt. Khuyến nghị tạo hình ảnh tùy chỉnh với Android SDK, NDK và cấp API cần thiết. Thực thi song song các job (lint, test, assemble) trong các stage khác nhau giảm thời gian pipeline tổng thể. Chính sách kéo hình ảnh (if-not-present) tăng tốc khởi động job. Proxy phụ thuộc cũng có thể được sử dụng để lưu vào bộ nhớ đệm hình ảnh ở cấp phiên bản GitLab.

Một khía cạnh quan trọng khác của tối ưu hóa là sử dụng artifact giữa các giai đoạn. Các tệp nặng như APK và IPA nên được truyền qua dependency thay vì xây dựng lại trong mỗi job. Đối với các dự án lớn với hàng chục mô-đun, nên bật Gradle Build Cache ở cấp pipeline và cấu hình bộ nhớ đệm từ xa trên bộ lưu trữ dùng chung. Thời gian chờ cho mỗi job nên được đặt dựa trên thời gian build dự kiến — điều này ngăn chặn các quá trình bị treo.

Ví dụ với bộ nhớ đệm và chính sách kéo

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present