Објавити, отпремити, применити — суштина термина и разлике

Шта значи „објавити”, „отпремити”, „применити”

„Објавити” — најопштији термин који значи објављивање нове верзије софтверског производа, функције или промене. „Објавили смо ажурирање”, „објавили смо фикс”, „објавили смо издање” — у свим случајевима ради се о томе да је промена постала доступна корисницима. Термин претпоставља прилично велику акцију: обично се објављује цела верзија, а не једна датотека.

„Отпремити” — конкретнији термин који значи отпремање датотека, података или артефаката на сервер или у складиште. „Отпреми билд на сервер”, „отпреми скрипте у БП”, „отпреми асете у CDN”. За разлику од „објавити”, термин не подразумева да је отпремљено постало доступно корисницима — датотеке могу бити на серверу, али још увек нису повезане са апликацијом. Нијанса: „отпремити” се такође користи за слање кода у репозиторијум („отпремио сам на GitHub”).

„Применити” — термин који значи примену промене преко постојеће верзије. „Примени миграцију”, „примени пач”, „примени конфиг”. Кључна разлика — промена се наноси одозго без потпуне замене. Ако је „објавити” покретање нове верзије уместо старе, онда је „применити” додавање промене ономе што већ ради. Термин је распрострањен у контексту база података (миграције) и пач издања.

Додатни термини из истог семантичког поља: «распространити» (применити промену на све сервере у кластеру), «вратити» (вратити претходну верзију), «случајно деплојирати» (грешком деплојирати погрешну верзију). Сви ови глаголи описују радње са кодом као физичким објектом који се може «котрљати», «лити» и «враћати назад».

Порекло сленг термина

Термин „објавити” потиче из аутомобилске метафоре: «извући аутомобил из гараже». Када је код спреман за издање, он се «објављује» — пушта напоље, чини доступним корисницима. Метафора се проширила раних 2000-их са појавом continuous delivery пракси, када су издања постала редовна, а не годишња. „Данас имамо објаву” — значи дан издања.

Термин „отпремити” има корене у раном вебу, када су сајтови отпремани на сервере путем FTP-а. „Отпремити датотеке на сервер” — буквално пренети датотеке протоколом који се доживљавао као «изливање» података. Реч се задржала, иако савремени деплој користи CI/CD цевоводе, а не FTP клијенте. Занимљивост: у енглеском језику аналог је «push» (push to server), а не «pour». Руски језик је изабрао другу метафору.

Термин „применити” потиче из производног окружења: «навући точак», «навући навртку». У контексту софтвера — применити промену на постојећи систем, као што се навлачи навој на завртањ. У базама података термин је посебно природан: миграције се управо «примењују» (apply) и «враћају» (rollback). Rollback — један од ретких енглеских термина који има тачан српски аналог «враћање».

Разлика између термина у различитим контекстима

У контексту база података: миграције се «примењују», подаци се «отпремају», верзија шеме се «објављује». Ако треба додати нову колону — примењује се миграција. Ако треба уметнути тест податке — отпрема се дамп. Ако се структура базе података мења у целини — објављује се нова шема. Разлика одражава различите операције: apply, insert/load, deploy.

У контексту DevOps: «објавити» — покренути цевовод, «отпремити» — отпремити Docker имиџ у регистар, «применити» — применити конфигурацију на сервер путем Ansible-а. Пример: «прво отпремимо имиџ у регистар, затим применимо конфиг на сервер, и тек онда објавимо издање». Сваки термин одговара посебној фази CI/CD цевовода.

У контексту мобилног развоја: «отпремити» — послати билд у App Store Connect или Google Play Console, «објавити» — објавити у продавници апликација, «применити» — доставити ажурирање путем механизма in-app updates. За iOS «објавити» значи проћи Review, за Android — rollout кроз Play Console. Временска скала: «отпремање» траје минуте, «објављивање» — сате или дане (због прегледа).

Фазе процеса издања: од комита до продукције

Фаза 1: Изградња (Build). Код се компилира, ствара се артефакт (бинарац, Docker имиџ, APK/IPA). CI сервер покреће изградњу након сваког комита у главну грану. Резултат изградње — артефакт спреман за деплој са јединственом ознаком верзије (semantic versioning или commit hash). Ако изградња падне — цео цевовод се зауставља, програмер добија обавештење.

Фаза 2: Тестирање (Test). Покрећу се unit тестови, интеграциони тестови, линтери, провера безбедности (SAST). Ова фаза не би требало да траје дуже од 10–15 минута — ако је дуже, програмери губе контекст и прелазе на друге задатке. Брза повратна информација — кључни принцип CI/CD. Према Puppet State of DevOps 2023, тимови са брзим тестирањем (<10 мин) праве 3 пута више издања.

Фаза 3: Деплој на стејџинг (Staging Deploy). Артефакт се поставља на стејџинг окружење, идентично продукцији. На стејџингу се извршавају E2E тестови, smoke тестови и, по потреби, ручно тестирање QA. Ако се на стејџингу открије регресија — издање се блокира, промене се шаљу на дораду.

Фаза 4: Објављивање на продукцију (Production Deploy). Артефакт се поставља на продукцијске сервере. У зависности од стратегије деплоја (rolling, blue-green, canary) објављивање може трајати од неколико секунди до неколико сати. Након објављивања покрећу се post-deploy тестови и мониторинг — ако су метрике у норми, издање се сматра успешним. Аутоматско враћање при прекорачењу прага грешака — стандардна пракса.

Стратегије деплоја: rolling, blue-green, canary

Rolling deploy — ажурирање сервера један по један. Док се један сервер ажурира, остали настављају да опслужују кориснике. Након успешног ажурирања првог сервера, ажурира се други, и тако даље. Минус: током деплоја на серверима раде различите верзије, што може изазвати некомпатибилност. Плус: zero-downtime и без потребе за двоструким бројем сервера.

Blue-green deploy — два идентична окружења: Blue (тренутна верзија) и Green (нова верзија). Након што је Green потпуно спреман и тестиран, балансер преусмерава саобраћај са Blue на Green. Ако се на Green открије проблем — враћамо се на Blue. Плус: тренутни rollback. Минус: потребно је двоструко више ресурса (сервера) за подршку два окружења. Пребацивање траје секунде.

Canary deploy — нова верзија се прво поставља на мали проценат сервера (5–10%). Део корисника долази на нову верзију, остали — на стару. Ако су метрике у canary групи у норми (стопа грешака није порасла, latency се није повећао), нова верзија се постепено шири на све сервере. Google, Netflix, Spotify користе canary deploy за минимизацију ризика. Минус: сложеност мониторинга и анализе метрика.

Алати за аутоматизацију деплоја

CI/CD сервери — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (за мобилне). Бире се у зависности од стека: Jenkins — универзалан, GitLab CI — ако је репозиторијум на GitLab-у, Bitrise — за iOS/Android. Основни задатак CI/CD сервера — аутоматско извршавање цевовода изградње, тестирања и деплоја без учешћа човека.

Контејнеризација — Docker, Kubernetes. Docker ствара изоловане контејнере са апликацијом и свим зависностима. Kubernetes управља постављањем контејнера на кластер сервера: аутоматско rolling ажурирање, скалирање, балансирање. Према CNCF Survey 2023, 96% организација користи контејнере у продукцији, од тога 67% — Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform описује инфраструктуру (сервере, мреже, балансере) у облику кода и управља њеним стањем. Ansible — конфигурација сервера: инсталација софтвера, подешавање параметара. Комбинација Terraform + Ansible даје потпуно аутоматизовану инфраструктуру: Terraform подиже сервере, Ansible их конфигурише. Immutable infrastructure — сервери се не ажурирају, већ се замењују новима са ажурираним имиџом.