Production у CI/CD — шта је то, фазе и окружење у развоју

Шта је Production у CI/CD

Production у контексту CI/CD — је финална фаза животног циклуса апликације, где код након проласка кроз све фазе изградње и тестирања постаје доступан крајњим корисницима. За разлику од развојних и staging окружења, production окружење ради са стварним подацима и оптерећењима, што намеће посебне захтеве за поузданост и перформансе.

Улога production окружења

Production окружење није само сервер, већ цела инфраструктура, која укључује балансере оптерећења, базе података, кеш слојеве, CDN и системе за мониторинг. Свака компонента мора бити отпорна на грешке и скалабилна. У мобилном развоју, production такође укључује backend сервисе, API капије и push инфраструктуру, које обезбеђују рад клијентске апликације.

Захтеви за production окружење

Production окружење мора да испуњава строге критеријуме: доступност 99.9% и више, време одговора API не више од 200 ms, подршка за опоравак од отказа (RTO и RPO у оквиру SLA). За мобилне апликације додатно су потребни мониторинг крашева (извештавање о грешкама), аналитика коришћења и A/B платформе за експерименте. CI/CD pipeline обезбеђује усклађеност са овим захтевима кроз аутоматизоване провере пре сваког деплоја.

Фазе деплоја у production

Деплој у production — је вишефазни процес, аутоматизован кроз CI/CD pipeline. Свака фаза укључује провере које спречавају улазак дефектног кода у продукцију. Размотримо кључне фазе на примеру типичног pipeline-а за мобилну апликацију.

CI/CD pipeline за production

Pipeline почиње комитом у главну грану репозиторијума. Након push-а, покрећу се аутоматска изградња и јединични тестови, затим интеграциони тестови и провера квалитета кода. Након успешног проласка свих фаза, артефакт се објављује у регистру изградњи и деплојује на staging за коначну проверу. Тек након потврде на staging-у, pipeline прелази на деплој у production.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

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

Аутоматизовани деплој у production користи стратегије zero-downtime deployment: rolling update, blue-green deployment или canary release. Код rolling update-а, нове инстанце апликације постепено замењују старе без заустављања сервиса. Blue-green deployment одржава два идентична окружења и тренутно пребацује саобраћај, што омогућава брзи повратак у случају проблема. Избор стратегије зависи од критичности сервиса и дозвољеног времена застоја. За мобилне апликације, деплој у production укључује објављивање у продавницама апликација (App Store Connect, Google Play Console) са постепеним покретањем, што захтева додатну интеграцију CI/CD са API-јима продавница за аутоматизацију процеса објављивања, укључујући отпремање бинарних датотека, попуњавање метаподатака и слање на преглед.

Провере након деплоја

Након успешног деплоја у production, CI/CD pipeline покреће сет smoke тестова који проверавају основну функционалност сервиса: доступност ендпоинта, исправност API одговора, време одговора у нормалним границама. За мобилне апликације додатно се проверава могућност аутентификације, синхронизација података и исправно функционисање интеграција плаћања. Ако smoke тестови не прођу, pipeline аутоматски покреће rollback на претходну стабилну верзију и шаље обавештење тиму. Мониторинг након деплоја наставља се 30–60 минута са повишеним нивоом аларма — ово је прозор за откривање проблема који нису покривени аутоматским тестовима.

Разлике између production и тестних окружења

Кључна разлика између production и мање строгих окружења — рад са стварним корисничким подацима и оптерећењима. Staging окружење је намењено за коначну проверу пре издавања, али користи синтетичке или анонимизоване податке. Production пак обрађује живе трансакције, личне податке и критично важне операције, што захтева суштински другачији приступ управљању.

Конфигурација и инфраструктура

Конфигурација production окружења мора бити строго изолована од других окружења. Ово се односи на променљиве окружења, стрингове за повезивање са базама података, API кључеве и сертификате. Production инфраструктура се обично дуплира у више зона доступности (availability zones) ради обезбеђивања отпорности на грешке. За мобилне апликације, production такође укључује конфигурације Apple App Store и Google Play, које не постоје у тестним изградњама.

Управљање подацима

У production-у је строго забрањено коришћење стварних података за тестирање — за то постоје staging и development окружења. Све промене структуре базе података морају проћи кроз миграције које се аутоматски примењују од стране CI/CD pipeline-а. Резервно копирање production података обавља се по распореду са аутоматском провером интегритета резервних копија. Retention policy одређује период чувања резервних копија у складу са захтевима GDPR и других регулатора.

Мониторинг production инфраструктуре

Мониторинг production — је континуирани процес прикупљања и анализе метрика, логова и трагова. Без потпуног мониторинга немогуће је гарантовати SLA и благовремено откривати инциденте. Савремени приступ мониторингу заснива се на три стуба: метрике (нумерички показатељи), логови (структурирани записи догађаја) и трагови (трасирање захтева).

Кључне метрике

Основне метрике production окружења укључују: uptime (доступност сервиса), latency (кашњење одговора), error rate (проценат грешака), throughput (пропусна моћ) и saturation (ниво оптерећења ресурса). За мобилне апликације критичне су метрике времена покретања, учесталост крашева (crash-free rate) и време синхронизације података. Аларми се подешавају на основу SLO (Service Level Objectives), како би тим добијао обавештења пре кршења SLA.

Алати за мониторинг

За мониторинг production инфраструктуре користе се специјализоване платформе: Datadog, New Relic, Grafana + Prometheus за прикупљање метрика, Sentry и Crashlytics за праћење грешака у мобилним апликацијама. Логови се централизују путем ELK стека (Elasticsearch, Logstash, Kibana) или Splunk. Трасирање захтева се реализује помоћу Jaeger или Zipkin. Сви алати су интегрисани са CI/CD pipeline-ом за аутоматско креирање контролних табли при деплоју новог сервиса. Incident response систем (PagerDuty, Opsgenie) прима аларме од свих алата за мониторинг и аутоматски одређује одговорног дежурног на основу ротације и правила ескалације. Runbook за сваки тип инцидента чува се у репозиторијуму и верзионише се заједно са кодом, што гарантује актуелност упутстава за опоравак.

Безбедност production окружења

Безбедност production окружења — је вишеслојни систем заштите који покрива инфраструктуру, податке, приступ и процес деплоја. Сваки слој мора бити подешен тако да компромитација једног не води ка компромитацији целог система. CI/CD pipeline игра кључну улогу у обезбеђивању сигурности кроз аутоматизоване провере, скенирање рањивости и контролу усклађености на свакој фази pipeline-а.

Приступ и улоге

Приступ production окружењу је строго ограничен по принципу најмањих привилегија. Програмери немају директан приступ production серверима — све промене пролазе кроз CI/CD pipeline са механизмом одобравања. За хитни приступ користе се привремени акредитиви са аутоматском ротацијом и потпуним евидентирањем активности. Принцип четири ока (свака операција захтева одобрење две особе) је стандард за production операције.

Ревизија промена

Свака промена у production-у се бележи у систему ревизије: ко је покренуо деплој, који commit је деплојован, које провере су прошле, колико је трајао деплој. Интеграција CI/CD са системима за управљање инцидентима (PagerDuty, Opsgenie) омогућава аутоматско креирање тикета при паду деплоја или кршењу SLO. Сви production логови се чувају у непроменљивом складишту са периодом чувања од најмање 90 дана у складу са захтевима SOC2 и ISO 27001.