Git, CI/CD & Observability
Ortak konu · İlan 1 İlan 2 İlan 3
Git akışı, CI/CD ve gözlemlenebilirlik
Üç ilan da farklı araç isimleri (Jenkins / Bitbucket / Azure DevOps) sayıyor ama hepsi aynı üç soruya cevap arıyor: kodu nasıl birleştiriyorsun, nasıl otomatik doğruluyorsun, production'da bir şey patlarsa nasıl haberin oluyor?
Gitflow vs Trunk-Based Development
| Gitflow | Trunk-Based | |
|---|---|---|
| Branch yapısı | develop, feature/*, release/*, hotfix/* | Tek ana dal (main), herkes oraya sık sık küçük PR'larla merge eder |
| Feature ömrü | Günler/haftalar süren uzun ömürlü branch'ler | Saatler/1 gün — bitmemiş iş feature flag ile gizlenir |
| Ne zaman iyi | Net release takvimi olan, versiyonlanan ürünler | Sürekli deploy eden, hızlı geri bildirim isteyen ekipler |
💡
Mülakatta hazır cevap"Merge conflict'leri büyük ve uzun süren feature branch'lerin doğal sonucudur; trunk-based + feature flag bunu küçük, sık merge'lerle önler ama ekip disiplini ve iyi test coverage gerektirir."
Jenkins pipeline — mantığını anlat, satır satır ezberleme
Bir Jenkinsfile, kodun main'e her merge'inde otomatik çalışacak aşamaları (stage) tanımlar. Mülakatta "nasıl bir pipeline kurardın" diye sorulursa bu 4 aşamayı sırayla anlat:
Jenkinsfile
pipeline {
agent any
stages {
stage('Install') { steps { sh 'npm ci' } }
stage('Lint & Test') { steps { sh 'npm run lint && npm test -- --ci' } }
stage('Build') { steps { sh 'npm run build' } }
stage('Docker Build') {
steps { sh 'docker build -t registry.turkcell.com/web-app:$BUILD_NUMBER .' }
}
stage('Deploy') {
when { branch 'main' } // sadece main'e merge olunca deploy et
steps { sh 'kubectl set image deployment/web-app web-app=registry.turkcell.com/web-app:$BUILD_NUMBER' }
}
}
}Docker & containerized environment
Multi-stage build'in mantığı: bağımlılık kurma, derleme ve çalıştırma farklı katmanlarda olur ki final imaj sadece production'da gerekeni içersin — daha küçük, daha güvenli imaj.
Dockerfile
# --- deps: sadece bağımlılıkları kur, cache'lenebilsin diye ayrı stage ---
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci
# --- builder: uygulamayı derle ---
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
# --- runner: sadece prod'da gereken dosyalar, imaj küçük kalsın ---
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/package.json ./package.json
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["npm", "start"]Sentry, Datadog, Dynatrace — hangisi ne işe yarar
| Araç | Ana odak | Tipik soru cevapladığı |
|---|---|---|
| Sentry | Frontend/backend hata (exception) takibi | "Hangi kullanıcıda, hangi satırda, hangi adımlardan sonra patladı?" |
| Datadog | Infra metrikleri + APM + log toplama, dashboard'lar | "Sunucu CPU'su neden yükseldi, hangi endpoint yavaş?" |
| Dynatrace | AI destekli full-stack observability, otomatik kök neden analizi | "Bu incident'in gerçek kök nedeni hangi servis?" (otomatik bulur) |
// sentry.client.config.ts
import * as Sentry from "@sentry/nextjs";
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
tracesSampleRate: 0.2, // isteklerin %20'sini performans izlemeye al
});
// bir hatayı manuel işaretlemek istediğinde
try {
odemeYap();
} catch (err) {
Sentry.captureException(err); // stack trace + kullanıcı adımları (breadcrumb) ile Sentry'ye gider
throw err;
}Egzersizler
1) Bir feature'ı trunk-based akışta geliştiriyorsun ama işin yarısı bitti, main'e merge etmen gerekiyor. Ne yaparsın?
Feature flag arkasına alırsın — kodu merge edersin ama flag kapalı olduğu için kullanıcı göremez. Böylece küçük, sık merge'ler devam eder, main her zaman deploy edilebilir kalır, ve iş bitince flag'i açman yeterli olur (yeni bir deploy gerekmeden).
2) Production'da bir hata patladı. Sentry mi Datadog mu önce bakarsın, neden?
Hatanın kendisi (hangi component, hangi stack trace, hangi kullanıcı) için önce Sentry'ye bakarım — spesifik exception'ı gösterir. Eğer soru "neden yavaşladı/kaynak tükendi" ise Datadog'a bakarım — CPU/memory/network gibi sistem metriklerini gösterir. İkisi birbirini tamamlar, biri diğerinin yerine geçmez.