Build Server умобилном развоју — шта је, задаци и принцип рада

Шта је Build Server

Build Server (сервер за компилацију) — је специјализовани рачунарски систем намењен за аутоматско извршавање задатака везаних за компилацију кода и припрему издања. За разлику од локалне компилације на машини програмера, сервер ради са копијом репозиторијума, користи чисто окружење и фиксне верзије зависности.

Билд сервер је кључна компонента праксе Continuous Integration. Он гарантује да сваки комит пролази исти процес потврде без обзира на то ко га је направио. Ово елиминише проблем „ради на мојој машини“ и осигурава јединствени стандард квалитета.

Према подацима Google DORA, 2025, тимови који користе намјенски билд сервер скраћују време потврде промена са сати на минуте. Ово директно утиче на брзину испоруке функција и исправки корисницима.

Зашто је потребан билд сервер у мобилном развоју

Компилација мобилних апликација захтева значајне ресурсе: компилација Kotlin или Swift може трајати од 5 до 40 минута. Ако се компилација покреће на локалној машини програмера, он не може продуктивно да ради до њеног завршетка. Билд сервер решава овај проблем, ослабађајући програмера за друге задатке.

Разлика између билд сервера и CI сервера

У пракси термини се често користе као синоними, али постоји разлика: CI сервер (Jenkins, CircleCI) — је систем који управља пајплајновима, а билд сервер — је физички или виртуелни хост на којем се ови пајплајнови извршавају. Један CI сервер може да управља многим билд агентима (build slaves).

Архитектура билд сервера

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

Главни компоненти

Језгро (executor) — покреће задатке компилације. Може да ради као Docker контејнери, виртуелне машине или директно на хосту. Ред задатака управља приоритетима паралелних компилација. Складиште артефаката чува резултате (APK, IPA, AAB) за касније објављивање.

Мрежа билд агената (build farm)

За убрзање рада, билд сервер може да управља пулом агената. Сваки агент — је посебна машина или контејнер који може да обавља компилацију. Када оптерећење порасте, аутоматско маштабирање (auto-scaling) додаје нове агенте у облаку. На примјер, Jenkins са Kubernetes плагином може динамички да креира pod-ове за сваку компилацију.

pipeline {
    agent {
        kubernetes {
            yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: android-sdk
    image: openjdk:17-jdk
    command: ['sleep','infinity']
"""
        }
    }
    stages {
        stage('Build') {
            steps {
                sh './gradlew assembleDebug'
            }
        }
    }
}

Врсте билд сервера

Билд сервери се деле на неколико категорија према начину смештаја и циљном технолошком стеку. Избор одређеног решења зависи од величине тима, буџета и захтева за сигурношћу.

Self-hosted билд сервери

Jenkins, TeamCity, Bamboo, GitLab Runner (self-hosted) — инсталирају се на сопствене сервере или VPS. Предности: пуна контрола над конфигурацијом, могућност кориштења било којег софтвера, подаци не напуштају инфраструктуру компаније. Мане: трошкови администрирања, ажурирања и маштабирања.

Облачна решења којима се управља

GitHub Actions, CircleCI, Bitrise, Codemagic, GitLab SaaS — не захтевају управљање серверима. Наплата се врши по минутима билда или путем претплате. За мале тимове ово је оптималан почетак. За велике пројекте са великим обимом билдова, трошкови могу премашити цену self-hosted решења.

Билд сервери за iOS развој

Карактеристика iOS је да је компилација могућа само на macOS. Опције: Mac mini у реку, MacStadium (изнајмљивање Mac-а), GitHub Actions са macOS runner, Bitrise са сопственим Mac агентима. Self-hosted Mac билд сервер захтева куповину скупе опреме и њено одржавање.

Как подесити билд сервер

Размотрићемо постапно подешавање билд сервера за мобилни пројекат са Android и iOS билдовима. Као основу користимо GitHub Actions са self-hosted runner-ом за iOS и облачним runner-ом за Android.

Корак 1: Инсталација и конфигурација CI сервера

Изаберите платформу за управљање (Jenkins, GitLab, GitHub Actions). Инсталирајте мастер чвор, подесите приступ репозиторијуму преко SSH или personal access token-а. Подесите webhook за аутоматско покретање билда при push обавештењима у репозиторијум.

Корак 2: Додавање билд агената

Региструјте једну или више машина као агенте (slaves/runners). За Android билдове, агент може да ради на Linux или Windows са инсталираним JDK, Android SDK, Gradle. За iOS — на macOS са Xcode Command Line Tools и CocoaPods.

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

Дефинишите фазе: checkout, инсталација зависности, компилација, тестирање, објављивање артефакта. За убрзање користите кеширање зависности (Gradle cache, CocoaPods cache, Docker image layers).

name: Android Build
on:
  push:
    branches: [main, develop]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Cache Gradle
        uses: actions/cache@v4
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
      - name: Build Release APK
        run: ./gradlew assembleRelease
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-release.apk
          path: app/build/outputs/apk/release/app-release.apk

Поређење цена билд сервера

Избор између self-hosted и облачног билд сервера није само техничка одлука, већ и финансијска. Цена се значајно разликује у зависности од обима билдова, потребног времена извршавања и потребе за macOS за iOS.

CAPEX напрама OPEX

Self-hosted сервер захтева капиталне трошкове (CAPEX): куповина опреме (Mac mini од $699, серверски рекови, мрежна опрема), подешавање и одржавање. Облачна решења — оперативни трошкови (OPEX): плаћање по минутима билда. За мале тимове OPEX је исплатливији, за велике пројекте са стотинама билдова дневно, CAPEX се исплаћује за 6–12 месеци.

Скривени трошкови

При израчунавању буџета узмите у обзир скривене трошкове: време за ажурирање софтвера, отклањање кварова, резервно копирање конфигурација, мрежно складиште артефаката. За self-hosted решења додајте 20–30% на базну цену одржавања. За облачна — поверите да лимит минута покрива врхна оптерећења, посебно пре издања.

Оптимизација трошкова

Смањити трошкове за билд сервер можете на неколико начина: кориштењем spot инстанци у облаку (до 70% јефтиније), кеширањем зависности између билдова, ограничавањем времена извршавања неуспешних пајплајнова и подешавањем аутоматског искључивања неактивних self-hosted агената ван радног времена.

Најбоље праксе за билд сервере

Ефикасан рад билд сервера захтева поштовање низа принципа. Оптимизација брзине компилације и стабилност инфраструктуре директно утичу на продуктивност тима за развој.

Кеширање и инкременталне компилације

Gradle Build Cache, CCache за C/C++, incremental compiler за Kotlin и Swift — укључите све доступне механизме кеширања. Подесите удаљени кеш компилације (путем HTTP или S3) да би различити програмери и агенти делили резултате компилације.

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

Свака компилација треба да се покреће у чистом окружењу. Користите Docker контејнере или привремене виртуелне машине да бисте искључили утицај претходних компилација на тренуту. Ово елиминише проблем „прљавог стања” (state pollution).

• Користите Docker за контејнеризацију окружења за компилацију — ово гарантује поновљивост компилација
• Подесите мониторинг билд сервера — CPU, меморија, диск, време компилације, учесталост грешака
• Аутоматизујте чишћење старих артефаката да не би затрпавали диск простор

Сигурност билд сервера

Билд сервер има приступ изворним кодовима, кључевима за потпис и тајнама. Минимизирајте површину напада: користите изоловане агенте за различите пројекте, ограничите приступ мастер чвору, користите signed commits и провјеравајте зависности на рањивости.