CD: kompletan vodič

Postavljanje CI/CD pipelinea: GitHub Actions, GitLab CI

Postavljanje CI/CD pipelinea pretvara svaku izmjenu koda u ponovljiv, testiran i sljedljiv release: programer pošalje commit, pipeline provjeri stil koda, pokrene testove i napravi build, a provjereni artefakt stiže na staging ili u produkciju bez kopiranja fajlova preko FTP-a i kucanja komandi na serveru u ponoć. Kontinuirana integracija otkriva probleme dok ih je još jeftino ispraviti, a kontinuirana isporuka pretvara objavu nove verzije u rutinski, dosadan događaj umjesto rizičnog.

Sadržaj

U CodeWizu dizajniramo i gradimo pipelineove na GitHub Actionsu, GitLab CI-ju i Jenkinsu za Laravel i PHP aplikacije, WordPress i WooCommerce sajtove, Node.js API-je, frontend aplikacije i Python servise. Postavljamo automatske testove i kontrole kvaliteta, sigurno upravljanje tajnama, keširanje buildova, preview okruženja i deployment bez prekida rada, a cijeli tok dokumentujemo kako bi vaš tim tačno znao šta se dešava nakon git push.

Usluga je namijenjena timovima koji deployment rade ručno i plaše se objava petkom, agencijama kojima treba ujednačen proces na desetinama klijentskih projekata, te firmama čiji je postojeći pipeline spor, nepouzdan ili ga razumije samo jedna osoba. Ako vam za objavu nove verzije danas trebaju checklista i dosta sreće, automatizovan pipeline je obično DevOps ulaganje koje se najbrže vrati.

CD: Pogled iz ugla na HTML izvorni kod sa obojenom sintaksom na tamnom ekranu

Kako izgleda dobro osmišljen CI/CD pipeline

Bez obzira na platformu, dobar pipeline ima isti oblik. Brze provjere idu prve, pa povratna informacija stiže za nekoliko minuta; sporije i skuplje faze pokreću se tek kada prođu one jeftine; isti artefakt putuje sa staginga u produkciju, umjesto da se za svako okruženje gradi iznova.

Validacija: linting, formatiranje, provjera tipova i statička analiza (ESLint, TypeScript, PHPStan ili Larastan, PHP_CodeSniffer, Ruff).
Testiranje: unit i integracioni testovi nad pravim servisnim kontejnerima kao što su PostgreSQL, MySQL i Redis.
Build: kompajliranje aseta, instalacija produkcijskih zavisnosti, izrada i označavanje container slike ili release arhive.
Skeniranje: provjera zavisnosti, otkrivanje tajni u kodu i skeniranje slika prije bilo kakve objave.
Deployment: automatski na staging, a zatim zaštićeno, često ručno odobreno, prebacivanje u produkciju.
Provjera: smoke testovi i health checkovi nakon objave, uz automatski rollback ili rollback jednim klikom.

GitHub Actions CI/CD pipelineovi

GitHub Actions je prirodan izbor kada je vaš kod već na GitHubu. Workflowi su YAML fajlovi u .github/workflows, pokreću se na push, pull request, tag, po rasporedu ili ručno, a marketplace nudi gotove akcije za gotovo svaki jezik i cloud provajdera.

Kako gradimo GitHub Actions workflowe

Workflow za pull requestove koji provjere i testove pokreće u paralelnim jobovima, uz matricu za više verzija PHP-a ili Node.js-a kada biblioteka mora podržati sve njih.
Keširanje zavisnosti kroz setup akcije ili actions/cache, te concurrency grupe koje otkazuju zastarjela pokretanja kada stigne novi commit.
Reusable workflowi i composite akcije, tako da dvadeset repozitorija dijeli jedan održavan pipeline umjesto dvadeset malo drugačijih kopija.
Okruženja (environments) sa obaveznim odobravanjem i tajnama vezanim za konkretno okruženje za produkcijski deployment.
OpenID Connect (OIDC) prema AWS-u, Google Cloudu ili Azureu, pa pipeline dobija kratkotrajne kredencijale umjesto trajno sačuvanih cloud ključeva.
Self-hosted runneri na vašim serverima kada buildovi trebaju više procesorske snage, GPU ili pristup privatnoj mreži.

name: ci
on:
  pull_request:
  push:
    branches: [main]
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php: ["8.3", "8.4"]
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with: { php-version: "${{ matrix.php }}", coverage: none }
      - run: composer install --no-progress --prefer-dist
      - run: vendor/bin/phpstan analyse
      - run: vendor/bin/pest --parallel

Obratite pažnju na permissions: contents: read na vrhu: workflow tokenu podrazumijevano dajemo samo ono što mu treba, a dodatna prava dobija isključivo job koji radi deployment. GitHubov vodič za sigurnosno ojačavanje Actionsa vrijedi pročitati svima koji održavaju workflowe.

Konfiguracija GitLab CI/CD-a

GitLab CI je ugrađen u GitLab, bilo da koristite gitlab.com ili vlastitu instalaciju. Jedan fajl .gitlab-ci.yml definiše faze i jobove, a GitLab Runneri ih izvršavaju u Docker kontejnerima, na virtuelnim mašinama ili u Kubernetesu. Timovi koji sami hostuju GitLab često ga biraju upravo zato što kod, pipelineovi, container registry i praćenje zadataka ostaju na njihovoj infrastrukturi.

Šta postavljamo u GitLabu

rules koja tačno određuju kada se job pokreće (merge requestovi, glavna grana, tagovi), umjesto starije only/except sintakse.
needs kojim faze postaju graf zavisnosti, pa deploy job kreće čim se završi njegov build.
Zajednički šabloni preko include i extends, čuvani u jednom centralnom repozitoriju za sve projekte.
Zaštićene i maskirane CI/CD varijable, zaštićene grane i okruženja sa odobravanjem deploymenta.
Review aplikacije koje svaki merge request postavljaju na vlastiti privremeni URL, pa klijenti i testeri mogu isprobati izmjenu prije spajanja.
Vlastiti runneri na Hetzner ili DigitalOcean serverima kada minute dijeljenih runnera postanu usko grlo ili trošak.

stages: [test, deploy]

test:
  stage: test
  image: node:22-alpine
  cache:
    key: { files: [package-lock.json] }
    paths: [.npm/]
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run lint
    - npm test -- --coverage
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy_production:
  stage: deploy
  environment: production
  script: ./scripts/deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Kompletan pregled ključnih riječi nalazi se u zvaničnoj GitLab CI/CD YAML dokumentaciji.

Postavljanje i modernizacija Jenkinsa

Jenkins je veteran među ovim alatima: open-source, self-hosted i proširiv kroz ogroman ekosistem pluginova. I dalje je dobar izbor kada vam treba potpuna kontrola, kada build mora ostati unutar vlastite mreže iza firewalla ili kada već godinama imate jobove koji rade. Ipak, sklon je tome da postane krhak server koji niko ne smije dirati, pa se većina našeg rada na Jenkinsu svodi na to da ga ponovo učinimo ponovljivim.

Kako ispravno postavljamo Jenkins

Pipeline kao kod: deklarativni Jenkinsfile u svakom repozitoriju i multibranch pipelineovi umjesto jobova podešenih klikanjem kroz interfejs.
Configuration as Code (JCasC): postavke kontrolera, reference na kredencijale i pluginovi žive u YAML-u u Gitu, pa se cijeli server može ponovo podići za nekoliko minuta.
Privremeni agenti: buildovi se izvršavaju u Docker ili Kubernetes agentima koji nastaju za svaki build i nakon toga nestaju; sam kontroler ne pokreće buildove.
Shared libraries: zajednički koraci (build, skeniranje, deployment, obavještenja) pišu se jednom u Groovyju i koriste u svim pipelineovima.
Red u pluginovima i sigurnost: minimalan skup pluginova sa fiksiranim verzijama, redovna ažuriranja, pristup po ulogama i kredencijali u Jenkins credentials storeu ili eksternom vaultu.

Ako je vaš Jenkins star i niko ne želi da ga dira, možemo ga modernizovati na ovaj način ili prebaciti jobove na GitHub Actions ili GitLab CI – šta god je dugoročno jeftinije za rad i održavanje.

GitHub Actions, GitLab CI ili Jenkins: šta vama odgovara?

Kriterij	GitHub Actions	GitLab CI	Jenkins
Hosting	Cloud runneri, opcionalno self-hosted runneri	gitlab.com ili vlastita instalacija, dijeljeni ili vlastiti runneri	Uvijek self-hosted
Konfiguracija	YAML workflowi po repozitoriju	Jedan `.gitlab-ci.yml` uz include fajlove	Groovy `Jenkinsfile` uz JCasC
Napor za postavljanje	Nizak	Nizak na gitlab.com, srednji za vlastitu instalaciju	Srednji do visok
Održavanje	Minimalno (upravljana usluga)	Minimalno do srednje	Stalno: ažuriranja, pluginovi, agenti
Ekosistem	Veliki marketplace akcija	Integrisan registry, sigurnosno skeniranje, okruženja	Ogroman broj pluginova promjenljivog kvaliteta
Najbolji za	Kod na GitHubu, open-source, mali i srednji timovi	Sve-u-jednom DevOps platformu i potrebu za self-hostingom	On-premise, složene starije buildove, potpunu kontrolu

Naše pravilo: koristite CI sistem koji je ugrađen u vaš Git hosting, osim ako postoji konkretan razlog protiv.

Automatsko testiranje u pipelineu

Pipeline je pouzdan onoliko koliko su pouzdani testovi koje pokreće. Automatskom testiranju posvećujemo najviše vremena, jer zelen build mora zaista značiti „sigurno za objavu”. Pratimo piramidu testiranja: mnogo brzih unit testova, manje integracionih testova i mali, fokusiran skup end-to-end testova za tokove od kojih zarađujete.

Slojevi testova koje automatizujemo

Unit testovi: PHPUnit ili Pest za PHP i Laravel, Vitest ili Jest za JavaScript i TypeScript, pytest za Python.
Integracioni testovi: prave instance PostgreSQL-a, MySQL-a, Redisa ili Typesensea pokrenute kao servisni kontejneri, uz migracije koje se izvršavaju od nule.
End-to-end testovi: Playwright ili Cypress za checkout, prijavu, registraciju i druge ključne korisničke tokove, uz snimke ekrana i trace fajlove sačuvane kao artefakti kada test padne.
Statička analiza: PHPStan ili Larastan, ESLint i tsc --noEmit hvataju čitave grupe grešaka prije nego što se pokrene ijedan test.
Sigurnosne provjere: composer audit, npm audit, gitleaks za tajne koje su greškom commitovane i Trivy za container slike.
Budžeti performansi: Lighthouse CI odbija pull request koji primjetno uspori ključne stranice – istu disciplinu opisujemo u članku o tome kako postižemo 100/100 rezultat performansi.

Kako testovi ostaju brzi i pouzdani

Testove paralelizujemo, keširamo zavisnosti i preskačemo teške jobove kada se mijenja samo dokumentacija. Nestabilne (flaky) testove izdvajamo i popravljamo, umjesto da ih ponavljamo dok ne prođu, jer je pipeline koji ljudi nauče ignorisati gori od nikakvog. Ako projekat nema testove, krećemo od smoke testova za najvrjednije tokove i širimo pokrivenost uz nove funkcionalnosti.

Gusti redovi šarenog JavaScript koda koji ispunjavaju ekran monitora

Strategije deploymenta bez prekida rada

„CD” polovina CI/CD-a određuje kako nova verzija stiže do korisnika. Prava strategija zavisi od vaše infrastrukture i od toga koliko vas košta loša objava.

Strategija	Kako radi	Kada odgovara
Atomski release preko symlinka	Nova verzija se pripremi u zasebnom direktoriju, a zatim symlink trenutno prebaci na nju	PHP, Laravel i WordPress na VPS-u ili dedicated serverima
Rolling update	Instance se mijenjaju nekoliko po nekoliko iza load balancera	Docker Swarm, Kubernetes, više aplikacionih servera
Blue-green	Dva identična okruženja; saobraćaj se prebacuje kada je novo provjereno	Kritični sistemi kojima treba trenutni rollback
Canary	Mali dio saobraćaja prvi dobija novu verziju, a udio se zatim postepeno povećava	Aplikacije sa velikim saobraćajem i dobrim monitoringom

Izmjene baze podataka traže posebnu pažnju. Koristimo expand-and-contract migracije – prvo dodamo nove kolone, zatim objavimo kod koji ih koristi, a stare kolone uklonimo u nekoj kasnijoj verziji – tako da prethodna verzija radi i tokom prelaska, a rollback nikada ne naleti na nekompatibilnu šemu. Kada radimo deployment kod različitih provajdera, pipeline se prilagođava cilju; više o tome pisali smo u članku o strategijama deploymenta na DigitalOceanu, AWS-u, Hetzneru i bare metal serverima.

Sigurnost CI/CD-a i upravljanje tajnama

Pipeline ima pravo pisanja u produkciju, što ga čini privlačnom metom. Zato ga tretiramo kao dio vaše površine za napad:

Tajne se čuvaju u šifrovanom skladištu CI platforme ili u vaultu, nikada u repozitoriju, i dostupne su samo okruženju kojem trebaju.
OIDC federacija zamjenjuje trajne cloud ključeve svuda gdje provajder to podržava.
Akcije i slike trećih strana vežemo za verzije ili commit SHA, a Dependabot ili Renovate predlažu ažuriranja kroz pull requestove koji prolaze pregled.
Pipelineovi pokrenuti iz forkova nikada ne dobijaju tajne, a produkcijski deployment ide isključivo sa zaštićenih grana ili tagova.
Korisnici za deployment na serverima imaju samo prava koja su deploymentu potrebna, uz SSH ključeve namijenjene isključivo CI-ju.

Napadi na lanac snabdijevanja preko registara paketa su stvaran rizik i u CI-ju; naš vodič o zaštiti okruženja od zlonamjernih npm paketa detaljnije objašnjava ovu prijetnju.

Najčešće CI/CD greške koje ispravljamo

Aplikacija se posebno gradi za staging i za produkciju, pa ono što je testirano nije ono što ide u produkciju.
Spori pipelineovi u kojima se ništa ne kešira i svaki job instalira zavisnosti od nule.
Produkcijski kredencijali dostupni svakoj grani i svakom pull requestu.
Testovi kojima je „privremeno” dozvoljeno da padaju, i tako ostaje mjesecima.
Deploy skripte koje pokreću git pull na produkcijskom serveru i ostave ga napola ažuriranog ako nešto pođe po zlu.
Nema plana za rollback, pa pokvarena verzija znači žurni hotfix pod pritiskom.

Od čega zavisi cijena postavljanja CI/CD pipelinea

Procjenu dajemo nakon pregleda vaših repozitorija i trenutnog procesa objave. Glavni faktori su:

Broj repozitorija i da li mogu dijeliti šablone ili reusable workflowe.
Trenutno stanje testova – pisanje testova od nule često je veći posao od samog pipelinea.
Ciljevi deploymenta: jedan VPS, više servera, kontejneri, Kubernetes ili serverless platforme.
Zahtjevi za self-hosted runnerima, preview okruženjima, odobravanjem i revizijskim tragom.
Migracija sa postojećeg sistema, na primjer stare Jenkins instalacije.

Laptop sa terminalom punim izlaza komandi pored editora koda

Kako radimo

Pregled: mapiramo vaše repozitorije, model grananja, okruženja, trenutne korake deploymenta i mjesta na kojima objave pucaju.
Dizajn: biramo CI platformu, faze pipelinea, strategiju testiranja, strategiju deploymenta i način upravljanja tajnama, pa usaglašavamo obim posla.
Izrada: pišemo workflowe, zajedničke šablone i deploy skripte, a gdje nedostaju, dodajemo ili proširujemo automatske testove.
Probni rad: pokrećemo pipeline nad stagingom, uvježbavamo rollback i mjerimo trajanje buildova dok povratna informacija ne postane brza.
Puštanje u rad: produkcijski deployment prebacujemo na pipeline i zajedno sa vašim timom pažljivo pratimo prve objave.
Primopredaja i podrška: dobijate dokumentaciju i kratku obuku, a po želji i dalje održavamo pipeline, runnere i zavisnosti.

Zašto CodeWiz

Programeri koji pišu kod: Laravel, Node.js, WordPress i AI aplikacije razvijamo i sami, pa znamo koji testovi i provjere zaista hvataju prave greške.
Bez vezanosti za alat: GitHub Actions, GitLab CI ili Jenkins – preporučujemo ono što odgovara vašem Git hostingu i timu, a ne ono što mi volimo.
Open-source na prvom mjestu: Playwright, PHPStan, Trivy, gitleaks i self-hosted runneri drže troškove licenci niskim i štite vas od zavisnosti od jednog dobavljača.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, od tima iz Banje Luke koji radi na daljinu sa klijentima iz regiona i svijeta.
Cijela slika: pipelineovi, serveri, performanse i sigurnost su posao kojim se bavimo svaki dan – saznajte više o CodeWizu.

Često postavljana pitanja

Koliko traje postavljanje CI/CD pipelinea?

Za jednu aplikaciju koja već ima testove, funkcionalan pipeline sa automatskim deploymentom na staging i u produkciju obično je gotov za nekoliko dana. Više repozitorija, preview okruženja, migracija sa Jenkinsa ili pisanje testova od nule produžavaju to na nekoliko sedmica.

Šta je bolje: GitHub Actions ili GitLab CI?

Oba alata su zrela i sposobna. Presudno je obično gdje vam je kod: GitHub Actions za GitHub repozitorije, GitLab CI za GitLab, naročito ako ga hostujete sami. Selidba Git hostinga samo zbog promjene CI sistema rijetko se isplati.

Da li nam trebaju automatski testovi prije postavljanja CI/CD-a?

Ne trebaju, ali sa njima pipeline vrijedi mnogo više. I bez testova automatizujemo linting, statičku analizu, build i deployment, a zatim korak po korak dodajemo smoke testove i testove za ključne tokove.

Možete li postaviti CI/CD za WordPress?

Možemo. Vlastite teme i pluginovi žive u Gitu, zavisnostima se upravlja preko Composera, aseti se grade u pipelineu, a nove verzije se objavljuju atomski, dok uploadovani fajlovi i baza ostaju van repozitorija.

Koliko košta rad CI/CD-a?

Troškovi rada zavise od minuta buildova i runnera. Mnogi mali i srednji projekti stanu u minute koje su uključene u njihov Git hosting plan, dok su zahtjevniji buildovi često jeftiniji na self-hosted runneru na povoljnom cloud serveru. To procjenjujemo tokom pregleda.

Šta se dešava ako deployment ne uspije?

Pipeline se zaustavlja prije prebacivanja saobraćaja, pa prethodna verzija nastavlja da radi. Ako se problem pojavi nakon objave, health checkovi ili jedna komanda vraćaju posljednju ispravnu verziju.

Spremni da automatizujete objave?

Recite nam kako danas radite deployment i gdje vas najviše žulja, a mi ćemo predložiti CI/CD pipeline koji odgovara vašem stacku i timu. Kontaktirajte nas da razgovaramo o projektu ili pogledajte naše usluge postavljanja CI/CD pipelinea.

Postavljanje CI/CD pipelinea: GitHub Actions, GitLab CI