CI/CD labākās prakses Node.js komandām

Manuāla izvietošana ir riska faktors — cilvēku kļūdas, reproducējamības trūkums un stresa pilnas "piektdienas vakarā" izvietošanas. CI/CD automatizācija nodrošina, ka katrs koda gabals tiek pārbaudīts, testēts un droši nogādāts līdz produkcijai.

Cauruļvadu iestatīšana

Git atzarošanās stratēģijas

• Trunk-based development — ieteicamais mazām un vidējām komandām. Visi izstrādātāji strādā ar īsu mūžu feature branches, kas tiek sapludināti main ik dienu. Main vienmēr ir izvietojams
• GitHub Flow — vienkāršāka GitFlow alternatīva. Feature branch → PR → code review → merge → auto-deploy. Ideāls SaaS produktiem
• GitFlow — sarežģītāks ar develop, release un hotfix branches. Piemērots lielām komandām ar plānotiem releasēm
• Galvenais princips — main branch VIENMĒR ir production-ready. Katrs commit main ir potenciāls release

Automatizētas būvēšanas ar GitHub Actions

```yaml name: CI Pipeline on: push: branches: [main] pull_request: branches: [main]

jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 cache: 'npm' - run: npm ci - run: npm run lint - run: npm run type-check # tsc --noEmit - run: npm test -- --coverage - run: npm run build ```

Multi-stage pipeline

1. Lint + Type Check — ESLint + TypeScript kompilācija. Ātrākais solis, uztver vienkāršākās kļūdas
2. Unit Tests — Jest vienību testi ar coverage ziņojumu. Mērķis: >80% coverage
3. Integration Tests — Playwright vai Cypress — pārbauda reālu lietotāja plūsmu
4. Security Scan — npm audit, Snyk vai Trivy dependency skenēšana
5. Build — produkcijas build, kas pierāda, ka aplikācija kompilējas
6. Preview Deploy — Vercel Preview vai staging vide katrai PR
7. Production Deploy — tikai pēc visu iepriekšējo soļu veiksmīgas izpildes

Automatizēta testēšana padziļināti

Vienību testi ar Jest

• Testējiet biznesa loģiku — utilītu funkcijas, API handlers, datu transformācijas
• Mock ārējās dependencies — datubāze, API, failu sistēma. Testi jābūt ātri un neatkarīgi
• Snapshot testi — React komponentu renderēšanas pārbaude. Bet uzmanīgi — pārāk daudz snapshot = brittle testi
• Coverage thresholds — konfigurējiet minimālo coverage (80% statements, 70% branches) — CI fail, ja zem sliekšņa

Integrācijas testi ar Playwright

```typescript test('user can submit contact form', async ({ page }) => { await page.goto('/contact') await page.fill('[name="email"]', 'test@example.com') await page.fill('[name="message"]', 'Test message') await page.click('button[type="submit"]') await expect(page.locator('.success-message')).toBeVisible() }) ```

• Testējiet kritiskos ceļus — galvenās lietotāju plūsmas (reģistrācija, pirkums, kontakta forma)
• Paralēla izpilde — Playwright atbalsta paralēlus testus vairākos pārlūkos
• Visual regression — Percy vai Chromatic uztver vizuālas izmaiņas automātiski

Drošības skenēšana CI pipeline

• npm audit — iebūvēts Node.js, pārbauda dependency ievainojamības. `npm audit --audit-level=critical`
• Snyk — dziļāka analīze ar fiksēšanas ieteikumiem. Bezmaksas open source projektiem
• Trivy — konteineru un dependency skenēšana. Ātrs un visaptverošs
• SAST (Static Application Security Testing) — CodeQL (GitHub), SonarQube analizē jūsu kodu pēc drošības modeļiem
• Secret scanning — GitHub Advanced Security vai GitGuardian uztver nejaušas API atslēgas un credentials

Izvietošanas stratēģijas

Rolling deployment

• Pakāpeniska jauno instanču aizstāšana ar jaunām. Nekad visi serveri vienlaicīgi
• Vercel un Render veic šo automātiski — jaunie pieprasījumi uz jauno versiju, esošie pabeig vecajā

Blue-green deployment

• Divas identiskas vides — blue (aktīvā) un green (gaidīšanā)
• Jaunu versiju izvietojat green vidē, pārbaudāt, tad DNS/load balancer pārslēdz trafiku
• Momentāna atrite — ja problēma, pārslēdziet atpakaļ uz blue <1 sekundē
• Trūkums — dubultā infrastruktūra = dubultās izmaksas

Canary deployment

• Jauno versiju rāda 1–5% lietotāju. Monitorējat metrikas (kļūdu skaits, latency, konversijas)
• Ja viss labi — pakāpeniski palieliniet % (5 → 10 → 25 → 50 → 100)
• Ja problēma — atritiet, tikai maza daļa lietotāju bija ietekmēta
• Feature flags — LaunchDarkly, Flagsmith ļauj kontrolēt, kuri lietotāji redz jaunās funkcijas neatkarīgi no deployment

Atrites automatizācija

```yaml # Auto-rollback based on error rate

• name: Check error rate

run: | ERROR_RATE=$(curl -s "https://api.monitoring.com/error-rate") if [ $(echo "$ERROR_RATE > 5" | bc) -eq 1 ]; then echo "Error rate >5%, triggering rollback" vercel rollback --token $VERCEL_TOKEN exit 1 fi ```

Monitorings un observability

Aplikācijas monitorings

• Structured logging — JSON formāta žurnāli ar kontekstu (request ID, user ID, timestamp). Pino vai Winston Node.js
• Error tracking — Sentry uztver un grupē kļūdas ar stack traces, breadcrumbs un lietotāja kontekstu
• APM (Application Performance Monitoring) — Datadog, New Relic mēra katras funkcijas izpildes laiku, datubāzes vaicājumu ātrumu, ārējo API latency

Uptime un alerting

• Health check endpoints — `/api/health` atgriež 200, ja serviss ir veselīgs. Iekļaujiet datubāzes ping
• Uptime monitoring — Better Uptime, Pingdom vai UptimeRobot pārbauda ik 30–60 sekundes
• Alerting — Slack/PagerDuty integrācija — tūlītējs paziņojums, ja serviss nedarbojas vai error rate pieaug

Deployment metrikas

Sekojiet šīm metrikam, lai uzlabotu CI/CD procesu:

• Deployment frequency — cik bieži izvietojat. Mērķis: 1+ reizi dienā
• Lead time for changes — laiks no commit līdz produkcijai. Mērķis: <1 stunda
• MTTR (Mean Time to Recovery) — cik ātri atjaunojaties pēc incidenta. Mērķis: <1 stunda
• Change failure rate — cik % deployment izraisa problēmas. Mērķis: <5%

CI/CD nav tikai automatizācija — tā ir kultūras maiņa, kur koda kvalitāte, testēšana un drošība ir integrēti katras izstrādes iterācijas centrā.