Build Pipeline у мобилном развоју — суштина, фазе и подешавање

Шта је Build Pipeline

Build Pipeline (пајплајн изградње) — је формализовани низ корака који се аутоматски извршавају при свакој промени кода. Сваки корак проверава одређени аспект квалитета: компајлирање, исправност тестова, одсуство рањивости, усклађеност са код-стилом. Ако било који корак заврши грешком, пајплајн се зауставља.

Концепт пајплајна потиче из производне линије — као у фабрици, где свака станица додаје вредност производу. У развоју софтвера, свака фаза додаје сигурност да је код спреман за издање. Модерни пајплајни се дефинишу као код (Pipeline as Code) и чувају се у Git репозиторијуму заједно са пројектом.

Према Continuous Delivery Foundation, 2025, зрео build pipeline смањује време од комита до издања са недеља на минуте. Ово се постиже потпуном аутоматизацијом и паралелним извршавањем независних фаза.

Pipeline as Code

Уместо подешавања преко веб интерфејса, модерни пајплајн се описује у YAML или Groovy датотекама. Jenkinsfile, `.gitlab-ci.yml`, `.github/workflows/build.yml` — примери Pipeline as Code. Предности: верзионисање, code review, репродуцибилност.

Декларативни vs скриптни пајплајн

У Jenkins-у постоје две синтаксе. Декларативни — једноставнији, са јасном структуром stages/steps. Скриптни — флексибилнији, заснован на Groovy-ју. За већину пројеката се препоручује декларативни приступ као читљивији и предвидљивији.

Фазе типичног пајплајна

Типичан build pipeline за мобилну апликацију укључује неколико кључних фаза. Свака фаза обавља своју функцију и филтрира потенцијалне проблеме у раној фази.

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

Пајплајн почиње клонирањем репозиторијума. Затим се инсталирају зависности: Gradle/Maven пакети, CocoaPods, SPM (Swift Package Manager), npm пакети. Коришћење кеша у овој фази убрзава касније изградње за 50-70%.

Линтинг и статичка анализа

Пре компајлирања покрећу се алати за контролу квалитета кода: Detekt или ktlint за Kotlin, SwiftLint за Swift, ESLint за JavaScript. Они проверавају усклађеност са код-стилом и проналазе потенцијалне грешке на нивоу анализе кода.

Компајлирање и јединични тестови

Код се компајлира у бинарни облик, а истовремено се покрећу јединични тестови. За Android је то `./gradlew testDebugUnitTest`, за iOS — `xcodebuild test -scheme App -destination 'platform=iOS Simulator'`. Неуспех тестова одмах зауставља пајплајн.

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

Интеграциони и UI тестови

Након успешног компајлирања, извршавају се тестови који захтевају покретање апликације: Espresso за Android, XCTest/XCUITest за iOS, Detox за React Native. У овој фази артефакт се поставља на симулатор или стварни уређај преко farm услуга (Firebase Test Lab, BrowserStack, Sauce Labs).

Конфигурација пајплајна

Правилна конфигурација пајплајна одређује ефикасност целог CI/CD процеса. Конфигурација укључује избор окидача, дефинисање паралелних и секвенцијалних фаза, параметризацију и интеграцију са спољним услугама.

Окидачи пајплајна

Главни окидачи: push у репозиторијум, pull request (посебно за code review са аутоматским проверама), креирање Git ознаке (за издање), распоред (nightly build). Pull request окидач — најпрактичнији за тимски рад, јер открива проблеме пре спајања кода.

Паралелне и секвенцијалне фазе

Независне фазе (линтинг, тестирање на различитим верзијама ОС) треба извршавати паралелно ради убрзања. Зависне — секвенцијално. Модерни CI системи аутоматски управљају паралелним задацима, распоређујући их међу доступним агентима.

• Fail-fast — подесите тренутни неуспех при грешци у било којој паралелној грани
• Matrix build — покретање једне изградње на више конфигурација (API ниво, Xcode верзија)
• Conditional stages — неке фазе се извршавају само за одређене гране (нпр. примена само из main)

Оптимизација Build Pipeline-а

Дуг пајплајн успорава развојни циклус и смањује мотивацију тима. Оптимизација времена изградње — један од главних задатака DevOps инжењера при раду са build pipeline-ом.

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

Gradle Build Cache чува резултате претходних компајлирања. Ако се изворни код модула није променио, он се не прекомпајлира. Слично ради инкрементално компајлирање у Swift и Kotlin. Величина кеша може достићи гигабајте, али уштеда времена је од 30% до 70%.

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

Јединични тестови се могу покретати на више агената истовремено, распоређујући тест класе. Sharding — техника поделе тестова у групе (shard-ове). GitHub Actions подржава `strategy.matrix`, Jenkins — Parallel Test Executor, Gradle — `--parallel --max-workers`.

Минимизација слојева пајплајна

Свака додатна фаза додаје време. Анализирајте пајплајн редовно: које фазе се могу спојити? На пример, линтинг се може покренути паралелно са компајлирањем, а не пре њега. Интеграциони тестови — само за pull request, не за сваки комит.

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Безбедност Build Pipeline-а

Build pipeline — критични елемент ланца снабдевања софтвером и његова безбедност се не сме занемарити. Компромитација пајплајна може довести до уношења злонамерног кода у издање, што ће утицати на све кориснике апликације.

Напади на ланац снабдевања на пајплајнове

Познати напади: SolarWinds (2020), Codecov (2021), 3CX (2023) — сви су искоришћавали рањивости у CI/CD пајплајновима. Заједнички вектор — нападач добија приступ акредитивима сервера за изградњу и мења код у фази изградње. Резултат — злонамерно издање потписано легитимним сертификатом.

Заштита акредитива

Никада не чувајте кључеве за потписивање, API токене и лозинке у репозиторијуму или променљивим окружења CI система у отвореном облику. Користите тајне CI система (GitHub Secrets, GitLab CI Variables), HashiCorp Vault, AWS Secrets Manager. Минимизирајте приступ тајнама — сваки пајплајн треба да добије само кључеве потребне за његове конкретне кораке.

Верификација артефаката пајплајна

Сваки артефакт који излази из пајплајна треба да буде криптографски потписан и да садржи атестацију — доказ о пореклу (provenance). Алати: SLSA framework, in-toto attestation, cosign за потписивање контејнера. Провера потписа треба да се изврши пре примене у било које окружење.

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

Праћење и отклањање грешака пајплајна

Build pipeline — сложен систем који захтева стално праћење. Без метрика немогуће је утврдити да ли се пајплајн успорио и која фаза је постала уско грло.

Метрике пајплајна

Пратите: време проласка (total pipeline duration), време сваке фазе, учесталост падова (build failure rate), време чекања у реду (queue time). За велики тим (>20 програмера) препоручује се подешавање dashboard-а у Grafana или Datadog са агрегираном статистиком за недељу/месец.

Алертинг при падовима

Сваки пад пајплајна захтева реакцију. Подесите обавештења у месенџере (Slack, Telegram, Discord) са линком на лог грешке и назнаком аутора комита. За критичне падове — PagerDuty или Opsgenie са ескалацијом.

Локално отклањање грешака пајплајна

Алати попут Act (за GitHub Actions) или Jenkins Pipeline Unit Test омогућавају покретање пајплајна локално без комита. Ово убрзава развој и отклањање грешака пајплајнова, посебно при додавању нових фаза или промени конфигурације.