CI/CD Nedir? Sürekli Entegrasyon ve Sürekli Dağıtım Rehberi

CI/CD nedir? Kısaca: yazdığınız kodun test edilmesini, paketlenmesini ve canlıya çıkmasını otomatikleştiren bir çalışma disiplini ve araç zinciridir. Açılımıyla sürekli entegrasyon (Continuous Integration, CI) ve sürekli teslim / sürekli dağıtım (Continuous Delivery / Continuous Deployment, CD) kavramlarını birleştirir. Amaç tek cümlede toplanabilir: değişikliği küçük, sık ve otomatik biçimde üretime taşımak. Bu rehberde CI/CD'nin ne olduğunu, neden manuel dağıtımın modern yazılımda sürdürülemez olduğunu, tipik bir pipeline'ın aşamalarını, en çok kullanılan araçları ve ilk pipeline'ınızı nasıl kuracağınızı uçtan uca, örneklerle anlatıyoruz.

Bir DevOps veya bulut mühendisi olma yolundaysanız CI/CD, öğrenmeniz gereken ilk temel yapı taşlarından biridir. Docker, Kubernetes ve Terraform gibi teknolojiler bu boru hattının içinden geçerek gerçek değer üretir. Kariyer perspektifi için DevOps mühendisi nasıl olunur yazımıza da göz atabilirsiniz; burada ise işin kalbindeki otomasyon zincirine odaklanıyoruz.

CI/CD Nedir ve Neden Bu Kadar Önemli?

CI/CD, kaynak kodundaki her değişikliğin otomatik olarak doğrulanıp güvenli biçimde çalışan bir sisteme dönüştürülmesini sağlayan yaklaşımdır. Bir geliştirici kodu depoya (repository) gönderdiği anda arka planda bir dizi otomatik adım tetiklenir: kod derlenir, testler koşar, güvenlik taraması yapılır, bir artifact (örneğin Docker imajı) üretilir ve bu artifact bir ortama dağıtılır. İnsan eli, ancak gerekli olduğu noktada (örneğin üretime çıkış onayında) devreye girer.

Bu neden önemli? Çünkü yazılım artık ayda bir değil, günde onlarca kez değişiyor. Netflix, Amazon veya Google gibi şirketler günde binlerce dağıtım yapar. Bunu insan gücüyle, elle yapılan adımlarla sürdürmek imkânsızdır. CI/CD, tekrar eden ve hataya açık işi makineye devreder, insanı ise değer üreten işe (problem çözme, tasarım, gözden geçirme) bırakır.

Manuel Dağıtımın Sorunları

CI/CD'nin değerini anlamak için, onun çözdüğü sorunu görmek gerekir. Elle (manuel) dağıtım şöyle görünür: bir geliştirici kendi bilgisayarında kodu derler, dosyaları FTP ile sunucuya kopyalar, servisi elle yeniden başlatır ve "umarım çalışır" der. Bu yaklaşımın somut sorunları vardır:

• "Bende çalışıyordu" sendromu: Geliştiricinin makinesindeki ortam ile sunucudaki ortam farklıdır; kod bir yerde çalışıp diğerinde patlar.
• İnsan hatası: Yanlış dosya kopyalama, unutulan bir adım, atlanan bir yapılandırma. Gece yarısı yapılan elle dağıtımlar felaketle biter.
• Bilgi tek kişide kilitli: Dağıtımı yalnızca "o kişi" bilir. O kişi izinde ise sistem güncellenemez.
• Yavaş geri bildirim: Hata üretime çıktıktan saatler, hatta günler sonra fark edilir; kök nedeni bulmak zorlaşır.
• Zor geri alma (rollback): Bir şey bozulduğunda önceki sürüme dönmek panik dolu, elle yapılan, belgesiz bir sürece dönüşür.
• Ölçeklenemezlik: 3 sunucuda elle iş yaparsınız; 300 sunucuda bu tamamen çöker.

Sürekli Entegrasyon (Continuous Integration) Nedir?

Sürekli entegrasyon (CI), geliştiricilerin kod değişikliklerini sık sık (ideal olarak günde birden çok kez) ortak bir ana dala (genellikle main veya develop) birleştirmesi ve her birleştirmenin otomatik derleme ve testlerle doğrulanması pratiğidir. Temel fikir: entegrasyonu haftalarca erteleyip sonunda dev bir "merge cehennemi" yaşamak yerine, küçük parçaları sürekli birleştirip sorunları erkenden yakalamak.

CI'nın omurgası otomatik testlerdir. Bir commit geldiğinde CI sunucusu depoyu çeker, bağımlılıkları kurar, projeyi derler ve test paketini koşar. Testler geçerse değişiklik güvenle ana dala girer; geçmezse geliştirici anında uyarılır. Bu "hızlı geri bildirim döngüsü", hatanın maliyeti henüz düşükken — yani kod hâlâ geliştiricinin aklında tazeyken — düzeltilmesini sağlar.

İyi Bir CI Pratiğinin İlkeleri

• Tek bir ortak depo ve trunk-based (ana dal odaklı) çalışma; uzun ömürlü dallardan kaçının.
• Her commit build'i tetiklesin; build hızlı olsun (ideal olarak 10 dakikanın altında).
• Testler otomatik ve güvenilir olsun; kırılgan (flaky) testler CI'ya olan güveni yok eder.
• Build bozulduğunda düzeltmek en yüksek öncelik olsun — kırık ana dal tüm ekibi bloke eder.
• Herkes değişikliğin sonucunu görebilsin (şeffaf durum: yeşil/kırmızı).

Continuous Delivery ve Continuous Deployment Ayrımı

"CD" kısaltması iki farklı ama yakın kavramı ifade eder ve bu ikisi sıkça karıştırılır. Farkı anlamak, CI/CD konuşmalarında sizi bir adım öne taşır.

Continuous Delivery (Sürekli Teslim): Her değişiklik otomatik olarak dağıtıma hazır hale getirilir — test edilir, paketlenir, staging ortamına çıkar. Ancak üretime çıkış için bir insan onayı (bir buton tıklaması) gerekir. Yani "her an yayınlayabilecek" durumdasınızdır ama yayın kararı manueldir.

Continuous Deployment (Sürekli Dağıtım): Bir adım ileri gider. Tüm otomatik kontrolleri geçen her değişiklik, hiçbir insan müdahalesi olmadan doğrudan üretime dağıtılır. Bu, olgun test kültürü ve güçlü otomasyon gerektiren en ileri seviyedir.

Tipik Bir CI/CD Pipeline'ının Aşamaları

Bir pipeline (boru hattı), kodun commit'ten üretime kadar geçtiği otomatik adımlar dizisidir. Her adım (stage) bir kapıdır: geçemezse hat durur ve ekip uyarılır. Endüstride yaygın kabul gören tipik akış şöyledir:

1. 1**Kaynak (Source):** Geliştirici kodu depoya push eder ya da bir pull request açar; bu olay pipeline'ı tetikler (webhook / event).
2. 2**Derleme (Build):** Kaynak kod derlenir, bağımlılıklar kurulur. Derlenmeyen kod ilerleyemez.
3. 3**Test:** Birim testleri (unit), entegrasyon testleri ve gerekirse uçtan uca (E2E) testler koşar. Bu, kalitenin ilk büyük kapısıdır.
4. 4**Güvenlik Taraması (Security Scan):** Bağımlılık zafiyetleri (SCA), statik kod analizi (SAST) ve gizli anahtar (secret) sızıntısı taraması yapılır.
5. 5**Paketleme (Package):** Uygulama dağıtılabilir bir artifact'e dönüştürülür — çoğunlukla bir Docker imajı — ve imza/etiketle bir kayıt defterine (registry) gönderilir.
6. 6**Dağıtım (Deploy):** Artifact hedef ortama (staging, ardından üretim) dağıtılır; genellikle Kubernetes veya bir bulut servisi üzerinde.
7. 7**İzleme & Doğrulama:** Dağıtım sonrası sağlık kontrolleri, metrikler ve smoke testleri; sorun varsa otomatik geri alma tetiklenir.

Bu aşamaların erken olanları (build, unit test) hızlı ve ucuzdur ve önce koşar; pahalı olanlar (E2E test, dağıtım) sona bırakılır. Böylece bariz bir hata varsa, hattın ilk saniyelerinde yakalanır — buna "fail fast" (erken başarısızlık) denir.

Pipeline as Code: Boru Hattını Kodla Tanımlamak

Modern CI/CD'nin devrimci fikirlerinden biri pipeline as code — yani boru hattının bir arayüzden tıklayarak değil, depoda yaşayan bir YAML dosyasıyla tanımlanmasıdır. Bu yaklaşım altyapıyı kod gibi ele alan felsefeyle aynı köktendir; Terraform ve Infrastructure as Code mantığının CI/CD'ye yansımasıdır.

• Versiyonlanır: Pipeline tanımı git geçmişinde durur; kim neyi ne zaman değiştirdi görürsünüz.
• Kod ile birlikte yaşar: Uygulama kodu ve onu dağıtan hat aynı depoda; birlikte gözden geçirilir (code review).
• Tekrar üretilebilir: Yeni bir servis mi açıyorsunuz? YAML'ı kopyalayıp uyarlarsınız; sıfırdan tıklamazsınız.
• Denetlenebilir: Değişiklik pull request'ten geçer; "birinin panelden gizlice ayar değiştirmesi" riski ortadan kalkar.

Aşağıda, gerçek bir GitHub Actions iş akışı (workflow) örneği var. main dalına gelen her push'ta testleri koşan, bir Docker imajı üreten ve Google Cloud Run'a dağıtan basitleştirilmiş bir pipeline:

# .github/workflows/deploy.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    name: Test & Lint
    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 test

  build-and-deploy:
    name: Build image & deploy
    needs: test                 # test job'ı geçmeden dağıtım yapma
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write            # keyless (WIF) kimlik doğrulama
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t $IMAGE:${{ github.sha }} .
        env:
          IMAGE: europe-west1-docker.pkg.dev/proj/app/web
      - name: Push & deploy
        run: |
          docker push $IMAGE:${{ github.sha }}
          gcloud run deploy web \
            --image $IMAGE:${{ github.sha }} \
            --region europe-west1 \
            --platform managed
        env:
          IMAGE: europe-west1-docker.pkg.dev/proj/app/web

Bir pipeline canlı çalıştığında loglar tipik olarak şöyle akar — her adımın başarısını gösteren satırları takip edebilirsiniz:

$ git push origin main
→ Workflow "CI/CD Pipeline" tetiklendi (run #142)
 
[test] Set up job
[test] npm ci ....................... ✓ 384 paket kuruldu (11s)
[test] npm run lint ................. ✓ hata yok
[test] npm test .................... ✓ 128 test geçti (6.2s)
[test] Job succeeded ✓
 
[build-and-deploy] docker build ..... ✓ imaj: web:9f3c1a (42s)
[build-and-deploy] docker push ...... ✓ registry'ye gönderildi
[build-and-deploy] gcloud run deploy  ✓ revizyon web-00042 %100 trafik
[build-and-deploy] Job succeeded ✓
 
✓ Pipeline tamamlandı — 1m 48s. Üretim güncel: https://web-xyz.run.app

Popüler CI/CD Araçları

Piyasada onlarca CI/CD aracı var; hepsi aynı temel işi yapar ancak farklı ekosistemlere ve iş akışlarına yaslanır. En yaygın dördünü karşılaştıralım:

GitHub Actions, kodunuz zaten GitHub'daysa en düşük sürtünmeli başlangıçtır — ayrı bir sunucu kurmanız gerekmez. GitLab CI/CD, GitLab kullananlar için aynı avantajı sağlar ve yerleşik güvenlik taramalarıyla öne çıkar. Jenkins, en eski ve en esnek seçenektir; kendi altyapınızda tam kontrol istediğinizde veya çok özel iş akışları kurduğunuzda hâlâ kurumsal dünyada yaygındır — bedeli, kurulum ve bakım yükünü kendinizin üstlenmesidir. CircleCI ise hız ve paralelleştirmeye odaklanır.

Docker ve Kubernetes ile Dağıtım

Modern CI/CD'nin "paketleme" adımı neredeyse her zaman konteynerlere dayanır. Bir Docker imajı, uygulamanızı ve tüm bağımlılıklarını tek bir taşınabilir birim halinde paketler — böylece "bende çalışıyordu" sorunu kökten çözülür, çünkü aynı imaj CI'da, staging'de ve üretimde bit bit aynı çalışır. Konteynerlerin temelini bilmiyorsanız Docker nedir ve temelleri yazısı iyi bir başlangıçtır.

Pipeline'da tipik akış şudur: kod test edilir, docker build ile bir imaj üretilir, imaj commit hash'i ile etiketlenip bir container registry'ye (Artifact Registry, Docker Hub, ECR) push edilir. Bu imaj artık değişmez (immutable) bir artifact'tir; tam olarak bu sürümü istediğiniz ortama dağıtabilirsiniz.

Dağıtımın hedefi çoğu zaman Kubernetes'tir. Kubernetes, konteynerlerinizi ölçekler, sağlıksız olanları yeniden başlatır ve rolling update ile kesintisiz güncelleme yapar. CI/CD pipeline'ı, yeni imaj etiketini Kubernetes'e bildirir (kubectl set image veya bir GitOps aracı) ve Kubernetes trafiği eski sürümden yeniye kademeli olarak kaydırır. Docker ile Kubernetes'in rollerini net ayırmak için Kubernetes vs Docker karşılaştırmamıza, sıfırdan öğrenmek içinse Kubernetes'e sıfırdan başlangıç rehberimize bakın.

Altyapıyı Kod ile Yönetmek (IaC) ve CI/CD

CI/CD yalnızca uygulama kodunu değil, altyapının kendisini de yönetebilir. Infrastructure as Code (IaC) yaklaşımıyla sunucular, ağlar, veritabanları ve Kubernetes kümeleri kodla (örneğin Terraform ile) tanımlanır. Bu tanımlar da tıpkı uygulama kodu gibi bir pipeline'dan geçer: terraform plan ile değişiklik önizlenir, gözden geçirilir, terraform apply ile uygulanır.

Böylece altyapı değişiklikleri de kayıt altına alınır, gözden geçirilir ve otomatikleşir — panelden elle yapılan, izi kalmayan değişikliklerin sonu gelir. Terraform'a giriş için Terraform nedir? Başlangıç rehberi yazımıza, ekip halinde çalışırken kritik olan durum yönetimi için Terraform state nedir yazımıza bakabilirsiniz. Tüm bu teknolojiler bulut üzerinde çalışır; bulutun kendisiyle ilgili temel için bulut bilişim nedir iyi bir başlangıç noktasıdır.

CI/CD'de En İyi Pratikler

Bir pipeline kurmak kolaydır; iyi bir pipeline kurmak deneyim ister. Yıllar içinde sektörde kristalleşmiş temel pratikler şunlardır:

• Hızlı geri bildirim: Pipeline'ı olabildiğince hızlı tutun. Testleri paralelleştirin, bağımlılıkları önbelleğe alın, hızlı testleri öne koyun. 30 dakikalık bir pipeline'ı kimse beklemek istemez.
• Değişmez artifact'ler: Bir kez üretilen imajı tüm ortamlarda (staging → üretim) yeniden kullanın; her ortam için yeniden derlemeyin. Test ettiğiniz şeyin tam olarak üretime gitmesini garanti eder.
• Kolay ve otomatik rollback: Bir dağıtım sorun çıkarırsa önceki iyi sürüme tek komutla ya da otomatik dönebilmelisiniz. Rollback'i tasarımın parçası yapın, sonradan düşünülen bir çare değil.
• Secret yönetimi: API anahtarları, parolalar ve token'ları asla depoya veya YAML'a düz metin yazmayın. Secret manager (GitHub Secrets, Vault, cloud secret manager) kullanın ve mümkünse keyless kimlik doğrulama (OIDC/WIF) tercih edin.
• Fail fast: Ucuz ve hızlı kontrolleri (lint, unit test) öne alın; pahalı adımlar (E2E, dağıtım) ancak bunlar geçtiğinde koşsun.
• Gözlemlenebilirlik: Pipeline'ın durumunu ve dağıtım sonrası metrikleri izleyin; bir dağıtımın hata oranını artırdığını dakikalar içinde görebilmelisiniz.
• Ortam eşitliği: Staging ile üretimi mümkün olduğunca aynı tutun ki staging'de geçen bir şey üretimde patlamasın.

İlk Pipeline'ınızı Kurma: Adım Adım

Teoriyi pratiğe dökmenin en iyi yolu küçük ama gerçek bir pipeline kurmaktır. Yüksek seviyede izlenecek yol şöyledir:

1. 1GitHub'da bir depo oluşturun ve içine küçük bir uygulama koyun (örneğin bir Node.js API veya statik site).
2. 2Depoda `.github/workflows/ci.yml` dosyasını oluşturun; `on: push` tetikleyicisiyle başlayın.
3. 3Bir `test` job'ı ekleyin: checkout → runtime kurulumu → bağımlılık → lint → test.
4. 4Push edin ve GitHub'ın "Actions" sekmesinde ilk çalışmanızı izleyin; yeşil onay işaretini görün.
5. 5Bir `build` job'ı ekleyip Docker imajı üretin ve bir registry'ye push edin (`needs: test` ile teste bağlayın).
6. 6Son olarak bir `deploy` job'ı ekleyin: imajı Cloud Run / Kubernetes gibi bir hedefe dağıtın; yalnızca `main` dalında koşsun.
7. 7Secret'ları (registry kimliği, cloud kimliği) repo ayarlarındaki "Secrets" bölümüne ekleyin; asla YAML'a gömmeyin.

Bu adımların her birini gerçek komutlar, ekran görüntüleri ve çalışan bir örnekle uçtan uca anlattığımız uygulamalı rehber için GitHub Actions ile ilk pipeline'ını kur yazısını takip edin. Orada push'tan üretime kadar tüm zinciri kendi elinizle kurarsınız.

CI/CD ve DevOps: Büyük Resimdeki Yeri

CI/CD, DevOps kültürünün en somut ve en görünür ürünüdür. DevOps; geliştirme (Dev) ve operasyon (Ops) ekipleri arasındaki duvarı yıkmayı, hızlı ve güvenilir teslimatı, otomasyonu ve paylaşılan sorumluluğu hedefleyen bir felsefedir. CI/CD ise bu felsefeyi çalışan bir makineye dönüştürür.

Bir DevOps mühendisinin günlük işinin büyük kısmı pipeline'ları tasarlamak, iyileştirmek ve güvenli hale getirmek etrafında döner. Docker, Kubernetes, Terraform, bulut platformları ve gözlemlenebilirlik araçları — hepsi CI/CD boru hattının içinde bir araya gelir. Bu kariyere yönelmek istiyorsanız hangi becerileri hangi sırayla öğrenmeniz gerektiğini DevOps mühendisi nasıl olunur yazımızda ayrıntılı bir yol haritasıyla anlatıyoruz.

Sıkça Sorulan Sorular

CI/CD öğrenmek için önce ne bilmeliyim?

Git ve versiyon kontrolünü rahat kullanabilmeniz (branch, commit, pull request), komut satırında temel yetkinlik ve bir programlama dilinde küçük bir uygulama yazıp test edebilmeniz yeterli bir başlangıçtır. Docker'ın temellerini bilmek büyük artı sağlar, çünkü modern pipeline'lar konteyner odaklıdır. Bunları edindikten sonra doğrudan GitHub Actions ile pratik yaparak öğrenmek en hızlı yoldur.

Continuous Delivery ile Continuous Deployment arasındaki fark tam olarak nedir?

İkisi de değişikliği otomatik olarak dağıtıma hazır hale getirir. Fark son adımdadır: Continuous Delivery'de üretime çıkış için bir insanın onay vermesi (butona basması) gerekir; Continuous Deployment'ta tüm otomatik kontrolleri geçen her değişiklik hiçbir insan müdahalesi olmadan doğrudan üretime gider. Deployment daha ileri, daha olgun test kültürü gerektiren bir aşamadır.

Küçük bir proje veya tek kişilik takım için CI/CD gereksiz mi?

Hayır. Tek kişilik bir projede bile CI/CD, her değişiklikte testlerinizin geçtiğinden otomatik emin olmanızı sağlar ve dağıtımı elle yapmanın zaman kaybı ile hata riskini ortadan kaldırır. GitHub Actions'ın ücretsiz kotası küçük projeler için fazlasıyla yeterlidir. Minimal bir "test + dağıt" pipeline'ı kurmak birkaç saatinizi alır ama size sürekli zaman ve güven kazandırır.

Hangi CI/CD aracıyla başlamalıyım?

Kodunuz GitHub'daysa GitHub Actions ile başlayın: kurulum gerektirmez, ücretsiz kotası öğrenmeye yeter ve iş ilanlarında en çok aranan becerilerden biridir. GitLab kullanıyorsanız GitLab CI/CD doğal seçimdir. Jenkins güçlü ve esnektir ama kurulum/bakım yükü yeni başlayanlar için fazladır; onu genellikle kurumsal ortamlarda ilerleyen aşamada öğrenirsiniz.

Pipeline'da secret (gizli anahtar) yönetimini nasıl yaparım?

Gizli değerleri asla depoya veya YAML dosyasına düz metin olarak yazmayın. CI aracının yerleşik secret deposunu (GitHub Secrets gibi) kullanın; bunlar loglarda maskelenir. Mümkünse uzun ömürlü anahtarlar yerine keyless / OIDC tabanlı kimlik doğrulama (örneğin GCP için Workload Identity Federation) kullanın; böylece hiç anahtar saklamanız gerekmez ve sızıntı riski kökten azalır.

Bir dağıtım bozulursa ne yapmalıyım?

İyi tasarlanmış bir pipeline'da geri alma (rollback) hızlı ve öngörülebilirdir. Her sürümü benzersiz bir imaj etiketiyle sakladığınız için, önceki iyi sürümün etiketini yeniden dağıtarak saniyeler içinde geri dönebilirsiniz. Daha olgun kurulumlarda dağıtım sonrası sağlık kontrolleri ve hata oranı metrikleri otomatik izlenir; bir eşik aşılırsa sistem rollback'i kendiliğinden tetikler. Rollback'i baştan tasarımın parçası yapmak, kriz anında panik yaşamamanın anahtarıdır.

CI/CD, modern yazılım geliştirmenin bel kemiğidir: küçük değişiklikleri sık, otomatik ve güvenli biçimde üretime taşıyarak hem hızı hem güveni aynı anda artırır. Sürekli entegrasyonla hataları erken yakalar, sürekli teslim/dağıtımla yayını sıradanlaştırır, pipeline as code ile tüm süreci versiyonlanabilir ve denetlenebilir kılarsınız. En önemlisi: CI/CD bir kere kurulup bitirilen bir proje değil, ekibinizle birlikte sürekli olgunlaştırdığınız bir uygulamadır. En iyi öğrenme yolu ise okumak değil, kurmaktır — bugün küçük bir depo açıp ilk pipeline'ınızı yazarak başlayın; GitHub Actions ile ilk pipeline'ını kur rehberi tam da bunun için elinizden tutuyor. Cloudpuz'un uygulamalı laboratuvarlarıyla bu becerileri gerçek ortamlarda pekiştirebilirsiniz.