GitLab CI: 파이프라인과 지속적 통합

GitLab CI란?

GitLab CI는 통합형 DevSecOps GitLab 애플리케이션의 일부로, 지속적 통합, 전송 및 배포를 포함합니다. 이 시스템은 2012년 별도 프로젝트로 시작되었지만 이후 GitLab에 직접 통합되었습니다. 핵심 원칙은 리포지토리 루트의 .gitlab-ci.yml 파일을 통한 코드형 구성(Configuration as Code)입니다. GitLab CI는 클라우드 SaaS 버전과 자체 관리 설치 모두에서 사용할 수 있습니다.

모바일 개발을 위해 GitLab CI는 APK 및 IPA 빌드 자동화, 계측 테스트 실행, 정적 코드 분석, 앱 서명, 스토어 게시를 제공합니다. 플랫폼은 사용자 정의 환경을 위한 Docker 이미지를 지원하여 Android SDK, NDK, Xcode 및 기타 도구를 사전 설치할 수 있습니다. 내장된 Container Registry는 팀 내에서 이미지 저장 및 배포를 간소화합니다.

GitLab CI 아키텍처: Runners, Pipelines 및 Stages

GitLab CI 아키텍처는 세 가지 핵심 구성 요소로 이루어져 있습니다. GitLab Runner는 작업을 실행하는 에이전트입니다. 러너는 공유형(GitLab 제공), 그룹형(프로젝트 그룹용), 특정형(단일 프로젝트용)이 있습니다. 각 러너는 Executor(Shell, Docker, Kubernetes 또는 VirtualBox)로 등록됩니다. GitLab Runner는 피크 부하 처리를 위한 자동 확장을 지원합니다.

파이프라인은 순차적으로 실행되는 스테이지의 집합입니다. 하나의 스테이지 내에서 작업은 병렬로 실행됩니다. 모바일 프로젝트의 일반적인 구조는 build → test → deploy입니다. test 스테이지의 작업이 실패하면 deploy가 트리거되지 않습니다. 배포를 위해 수동 트리거(when: manual)를 구성할 수 있습니다. 리포지토리 간 복잡한 CI/CD 시나리오를 위한 다중 프로젝트 파이프라인 트리거도 지원됩니다.

GitLab Runner Executor

Docker Executor는 모바일 앱 CI/CD에 가장 널리 사용됩니다. 각 작업은 깨끗한 Docker 컨테이너에서 실행되어 격리성과 재현성을 보장합니다. Android 빌드에는 SDK가 사전 설치된 android-sdk 이미지를 사용하고, iOS에는 Shell Executor와 함께 macOS 러너를 사용합니다.

모바일 프로젝트를 위한 .gitlab-ci.yml 구성

.gitlab-ci.yml 파일은 YAML 형식으로 파이프라인을 정의합니다. 주요 섹션으로는 image(Docker 이미지), stages(스테이지 목록), variables(환경 변수), before_script(각 작업 전 명령) 및 script, artifacts, cache 섹션이 포함된 작업이 있습니다. GitLab CI는 include를 지원하여 프로젝트 간 공통 구성을 재사용하기 위한 외부 YAML 파일 포함이 가능합니다.

GitLab CI의 변수는 여러 수준에서 설정할 수 있습니다: UI에서 전역적으로, 구성 파일에서, 그룹 및 프로젝트 설정에서. 변수 우선순위는 계층 구조를 따릅니다: 트리거 변수가 가장 높은 우선순위, 다음으로 UI의 CI/CD 변수, 그다음 .gitlab-ci.yml의 변수입니다. 변수는 보호되어 보호된 브랜치와 태그에서만 액세스할 수 있습니다.

기본 변수 및 이미지

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/

아티팩트가 있는 빌드 작업

generate-apk 작업은 Gradle 프로젝트를 빌드하고 APK를 아티팩트로 저장합니다. 아티팩트는 스테이지 간에 전달되며 deploy 작업은 build 스테이지의 APK를 사용할 수 있습니다. 아티팩트 보존 기간은 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: 주요 차이점

모바일 프로젝트를 위해 GitLab CI와 GitHub Actions 중에서 선택할 때 팀 인프라가 핵심 요소입니다. GitLab CI는 Android SDK가 포함된 Docker 이미지 저장을 위한 내장 Container Registry를 제공합니다. GitHub Actions는 GitHub Packages 또는 외부 레지스트리에 의존합니다. GitLab에는 코드 취약점 분석을 위한 내장 SAST(Static Application Security Testing)도 있습니다.

GitLab CI는 더 유연한 러너 모델을 제공합니다 — Kubernetes Executor, 자동 확장 및 사용자 정의 이미지를 지원합니다. GitHub Actions는 GitHub 생태계 통합 및 액션 마켓플레이스에서 우수합니다. GitLab CI는 GitHub Actions가 기성 액션으로 해결하는 많은 작업에 수동 구성이 필요합니다.

모바일 CI/CD 관점에서: GitLab CI는 이미 GitLab Self-Managed를 사용하고 Docker/Kubernetes로 자체 호스팅 러너가 필요한 기업에 더 적합합니다. GitHub Actions는 기성 액션과 설정 용이성을 중요시하는 클라우드 GitHub의 소규모 팀에 더 편리합니다.

기능 비교

Android 프로젝트 파이프라인 예시

완전한 Android 파이프라인에는 lint, 단위 테스트, 빌드 및 Firebase App Distribution 배포가 포함됩니다. 파이프라인은 Android SDK가 포함된 Docker 이미지, Gradle 캐싱, 동일한 스테이지에서 lint와 test의 병렬 실행을 사용합니다. 이 접근 방식은 lint와 test 작업이 서로 독립적이므로 전체 파이프라인 시간을 단축합니다.

iOS 프로젝트의 경우 파이프라인 구조는 macOS 러너와 코드 서명의 필요성으로 인해 다릅니다. 일반적인 iOS 파이프라인에는 CocoaPods 또는 SPM 설치, 시뮬레이터에서 테스트 실행, Xcode 프로젝트 보관, IPA 내보내기 및 TestFlight 업로드가 포함됩니다. GitLab CI for iOS는 macOS 러너를 사용합니다 — 시간 제한이 있는 GitLab SaaS macOS 러너 또는 Mac Mini나 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

GitLab CI에서 빌드 시간 최적화

GitLab CI에서 모바일 빌드 파이프라인을 최적화하려면 세부 사항에 주의해야 합니다. cache와 artifacts의 적절한 구성은 빌드 시간을 몇 배로 줄일 수 있습니다. 성능 분석을 위해 GitLab은 CI/CD Analytics를 제공합니다 — 파이프라인 기간 메트릭, 러너 부하 및 병목 현상을 보여주는 대시보드입니다. 최적화 기회를 찾기 위해 이러한 메트릭을 정기적으로 분석하세요. resource_group을 구성하면 파이프라인 병렬 실행이 차단되어 배포 충돌을 방지하는 데 유용합니다.

CI를 위한 브랜치 전략도 중요합니다. 권장되는 방법은 전체 파이프라인은 main 및 release 브랜치에서만 실행하고, 기능 브랜치에서는 lint와 단위 테스트만 실행하는 것입니다. 이렇게 하면 러너 시간을 절약하고 개발자 피드백을 가속화합니다. GitLab CI는 workflow:rules를 지원하여 브랜치, 변경된 파일 또는 환경 변수에 따라 작업을 포함하거나 제외하는 조건부 규칙을 사용할 수 있습니다.

종속성 캐싱이 주요 가속화 방법입니다. GitLab CI는 실행 간에 .gradle, Pods 및 node_modules를 캐시합니다. 캐시 키에는 $CI_COMMIT_REF_SLUG 또는 잠금 파일 해시가 포함됩니다. 적절한 캐싱을 통해 Android 프로젝트의 빌드 시간이 10~15분에서 2~4분으로 단축됩니다. 캐시는 분산될 수 있으며 GitLab은 이전 키로 폴백하는 cache:key를 지원합니다.

도구가 사전 설치된 Docker 이미지는 설치 시간을 절약합니다. 권장되는 방법은 Android SDK, NDK 및 필요한 API 수준이 포함된 사용자 정의 이미지를 만드는 것입니다. 다른 스테이지에서 작업(lint, test, assemble)을 병렬 실행하면 전체 파이프라인 시간이 단축됩니다. 이미지 풀 정책(if-not-present)은 작업 시작을 가속화합니다. GitLab 인스턴스 수준에서 이미지를 캐시하기 위해 종속성 프록시를 사용할 수도 있습니다.

최적화의 또 다른 중요한 측면은 스테이지 간 아티팩트 사용입니다. APK 및 IPA와 같은 대용량 파일은 각 작업에서 다시 빌드하는 대신 dependency를 통해 전달해야 합니다. 수십 개의 모듈이 있는 대규모 프로젝트의 경우 파이프라인 수준에서 Gradle Build Cache를 활성화하고 공유 스토리지에 원격 캐시를 구성하는 것이 좋습니다. 각 작업의 제한 시간은 예상 빌드 시간에 따라 설정해야 합니다 — 이렇게 하면 프로세스 중단을 방지할 수 있습니다.

캐싱 및 풀 정책 예시

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

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