CI/CD Pipeline — шта је, етапе аутоматизације и алати

Шта је CI/CD Pipeline

CI/CD Pipeline — је формализовани и аутоматизовани скуп процеса кроз које код пролази од тренутка потврђивања промена у репозиторијуму до постављања у производњу. Термин обједињује две праксе: Continuous Integration (непрекидна интеграција) и Continuous Delivery (непрекидна испорука), које заједно чине вод испоруке софтвера.

Историја појаве CI/CD

Концепт Continuous Integration је описао Грејди Буч 1991. године и популаризовао Мартин Фаулер 2000-их. Continuous Delivery као термин се учврстио након књиге Џеза Хамбла и Дејвида Фарлија „Continuous Delivery“ (2010). Савремени CI/CD Pipeline је постао де факто стандард у развоју мобилних апликација након 2015. године — са појавом облачних CI сервера и аутоматизацијом продавница апликација.

Зашто је CI/CD Pipeline потребан у развоју мобилних апликација

Мобилне апликације имају специфичне захтеве за изградњу и објављивање: потписивање сертификатима, више конфигурација (debug, release, staging), обфускација ProGuard/R8, више типова билдова (APK, AAB, IPA) и интеграција са продавницама апликација. Речно извршавање ових корака траје сатима и подложно је грешкама — CI/CD Pipeline аутоматизује рутину.

Етапе CI/CD Pipeline за мобилне апликације

Стандардни CI/CD Pipeline за Android или iOS апликацију састоји се од седам кључних етапа. Неке етапе се извршавају паралелно, друге — секвенцијално. Конкретни састав етапа зависи од технолошког стека и зрелости тима, али језгро остаје непромијењиво.

1. Checkout и инсталација зависности

Вод почиње клонирањем репозиторијума и инсталацијом зависности: Gradle/Maven за Android, CocoaPods или SPM за iOS. Кеширање зависности између покретања скраћује време инсталације са 3–5 минута на неколико секунди — ову оптимизацију подржавају сви савремени CI сервиси.

2. Статичка анализа и линтинг

Пре изградње, код се проверава линтерима (ktlint, detekt за Android, SwiftLint за iOS) и статичким анализаторима (Android Lint, SonarQube). Линтинг открива потенцијалне грешке, кршења стила кодирања и застареле API-је пре покретања тестова — принцип fail-fast штеди време тима.

3. Изградња пројекта

У фази изградње, цео пројекат се компилира и генеришу се артефакти: APK и AAB за Android, IPA за iOS. За Android се користе Gradle задаци (assembleDebug, bundleRelease), за iOS — xcodebuild или xcrun. Изградња се одвија у изолованом окружењу CI сервера, што гарантује поновљивост.

# Пример CI/CD Pipeline для Android на GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Аутоматско тестирање

Након изградње покрећу се јединични тестови, интеграциони тестови и UI тестови. JUnit и MockK за модулне тестове, Espresso и Compose Test за UI на Android-у, XCTest и XCUITest на iOS-у. Резултати се објављују у извештају и блокирају вод у случају пада критичних тестова.

5. Потписивање и обфускација

За релизне билдове врши се потписивање дигиталним сертификатом (APK Signer за Android, codesign за iOS) и обфускација кода. ProGuard или R8 за Android смањује величину APK-а за 15–30%. Кључеви за потпис чувају се у тајнама CI сервера — никада се не комитују у репозиторијум.

6. Испорука и постављање

Финална етапа вода — објављивање артефаката: преношење APK-а у интерно тестирање Google Play Console, слање IPA-а у TestFlight или објављивање у Firebase Distribution. Continuous Delivery подразумева да овај корак захтева ручну потврду, а Continuous Deployment се извршава аутоматски.

7. Обавештења и извештаји

Након завршетка вода, тим добија обавештење са резултатима: успех/неуспех, време извршавања, линк ка артефактима. Slack, Telegram или емајл — канали обавештавања бирају се према потребама тима. У случају пада етапе, у обавештење се укључује линк ка одређени лог грешке.

По чему се CI разликује од CD

Термини CI и CD се често користе као јединивени појам CI/CD, али постоји суштинска разлика између њих. CI (Continuous Integration) је одговоран за проверу квалитета при свакој интеграцији кода, а CD (Continuous Delivery) осигурава спремност овог кода за издање. Разумевање разлике је критично важно при дизајнирању вода.

Continuous Integration — контрола квалитета

CI се извршава при сваком push-у или pull request-у и укључује изградњу, статичку анализу и тестирање. Циљ CI — открити проблеме што раније, када је цена њиховог поправке минимална. Ако CI не прође — код не улази у главну грану. Просечно време извршавања CI за мобилни пројекат је 5–15 минута.

Continuous Delivery — спремност за издање

CD додаје CI-ју етапе припреме издања: потписивање, обфускацију, креирање релиз белешки, проверу лиценци, објављивање у складишту за тестере. CD гарантује да сваки комит у главној грани може да се постави у производњу једним кликом, али само издање захтева ручну потврду.

Алати за изградњу CI/CD Pipeline

Екосистем CI/CD алата за развој мобилних апликација укључује облачне сервисе, self-hosted решења и специјализоване платформе. Избор алата зависи од величине тима, буџета и безбедносносних захтева. Испод су представљене најпопуларније опције.

GitHub Actions

Уграђени CI/CD у GitHub-у са бесплатним лимитом од 2000 минута месечно за јавне репозиторијуме. GitHub Actions је популаран захваљујући огромном екосистему готових action-а (marketplace), једноставноћоћ подешавања кроз YAML и бешавној интеграције са GitHub репозиторијумом. Ограничење — нема подршке за Windows ранере за iOS билдове на бесплатном плану.

GitLab CI/CD

Self-hosted и облачно решење са снажним YAML конфигуратором. GitLab CI подржава паралелне џобове, кеширање, артефакте и окружења (environments). Популаран у enterprise сегменту захваљујући могућност постављања на сопственој инфраструктури и пуну контролу над подацима.

Jenkins

Класични CI сервер отвореног кода. Jenkins се конфигурише кроз плагине (преко 1800), подржава Declarative Pipeline у Groovy формату и ради у сваком окружењу: Windows, macOS, Linux. Захтева посвећену администрацију, али пружа максималну флексибилност конфигурације.

CircleCI

Облачни CI сервис са нагласком на брзину и једноставност. CircleCI аутоматски кешира зависности, подржава Docker слике за изоловане билдове и интеграцију са macOS-ом за iOS билдове. Ценовање се заснива на броју кредита — погодан за тимове који цене перформансе.

Примјер подешавања CI/CD Pipeline

Размотримо пуни CI/CD Pipeline за iOS апликацију коришћећем GitHub Actions и Fastlane. Fastlane је алат за аутоматизацију мобилних пројеката који апстрахује сложене операције изградње, потписивања и објављивања у једноставне команде.

# Fastfile — конфигурация Fastlane для iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Запуск тестов и линтинг"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Сборка релиза и загрузка в TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match управља сертификатима и provisioning profiles, build_app гради IPA, pilot преноси билд у TestFlight. Команда fastlane release извршава све етапе секвенцијално: добија сертификате, гради, потписује, преноси у App Store Connect за бета тестере.

CI/CD Pipeline за iOS са GitHub Actions

Интеграција Fastlane-а са GitHub Actions омогућава аутоматско покретање пуног вода при pull request-у у главну грану. Self-hosted runner на macOS-у је неопходан за компилацију iOS кода — GitHub не пружа macOS ранере на бесплатном плану.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

Најбоље праксе CI/CD Pipeline

Изградња ефикасног CI/CD Pipelineа захтева не само избор алата, већ и праћење проверених пракси. Без правилне организације, вод може да постане уско грло које успорава развој уместо да га убрзава. Испод су кључне препоруке засноване на искуству зрелих мобилних тимова.

Fail fast

Најбрже провере (линтинг, јединични тестови) се извршавају прве. Ако падну — вод се завршава без покретања дугих UI тестова или изградње релиза. Fail fast штеди минуте CI времена и убрзава повратну информацију програмеру. Просечно време до првог пада не би требало да прелази 2–3 минута.

Кеширање зависности

Gradle кеш, CocoaPods кеш и SPM кеш треба да се враћају између покретања. GitHub Actions подржава кеширање кроз actions/cache, GitLab CI — кроз cache кључну реч. Без кеширања, свако изградња преузима све зависности изнова — ово додаје 3–10 минута времену вода.

Паралелно извршавање

Независне етапе (линтер за Android и iOS, јединични тестови различитих модула) покрећу се као паралелни џобови. Паралелизација скраћује укупно време вода са 20–30 минута на 5–10 минута. Већина CI сервиса броји паралелне џобове одвојено — узмите ово у обзир при одабиру тарифног плана.

Изолација окружења

Свако покретање вода се извршава у чистом окружењу: Docker контејнеру, виртуелној машини или ефемерном ранеру. Изолација спречава утицај претходних билдова на текући. Избегавајте коришћења заједничких ранера између пројеката — међупројектно загађење окружења води до недетерминистичких падова.

Безбедност тајни

API кључеви, сертификати за потпис и токени за приступ продавницама апликација чувају се у шифрованом складишту CI сервера. Никада не укључујте тајне у логове, артефакте или промењиве окружења без префикса SECRET_. Користите алате као што је Fastlane match за управљање iOS сертификатима.