İçeriğe atla
Bilgi Merkezi/Makale
Makale

CI/CD Nedir? Sürekli Entegrasyon, Teslimat ve Jenkins

Sürekli entegrasyon, teslimat ve dağıtım farkını, pipeline aşamalarını, Jenkins ve öteki araçları, dağıtım stratejilerini ve pipeline güvenliğini anlattık.

Oğuzhan Gerçek··8 dk okuma
CI/CD Nedir? Sürekli Entegrasyon, Teslimat ve Jenkins

Kısa cevap: CI/CD, yazılım değişikliklerini otomatik olarak derleyen, test eden ve production'a taşıyan uygulamaların adıdır. CI (continuous integration, sürekli entegrasyon), herkesin kodunu en az günde bir kez ortak ana branch'e merge etmesi ve her merge işleminin otomatik build ve testle doğrulanmasıdır. CD, sürekli teslimat (continuous delivery) ya da sürekli dağıtım (continuous deployment) demektir: ilkinde production'a son adım bir onayla atılır, ikincisinde testleri geçen her değişiklik kendiliğinden çıkar. Adımları Jenkins, GitHub Actions ya da GitLab CI/CD gibi araçlardaki bir pipeline yürütür; pipeline sırlara eriştiği için kendisi de korunmalıdır.

CI/CD nedir?

GitLab'ın tanımıyla CI/CD, adım adım gelen kod değişikliklerinin sürekli build edildiği, test edildiği, deploy edildiği ve izlendiği bir geliştirme yöntemi. Kısaltmadaki CD kaynağa göre değişir: GitHub onu sürekli teslimat, NIST'in SP 800-204D belgesi sürekli dağıtım diye açıyor. CI/CD'nin DevOps içindeki yerini ve DORA metrikleriyle ölçülmesini DevOps yazımızda anlattık.

Sürekli entegrasyon (CI) ve otomatik testin rolü

Martin Fowler'ın Continuous Integration makalesine (son güncelleme 18 Ocak 2024) göre CI'da ekipteki herkes değişikliklerini en az günde bir kez ortak kod tabanına merge eder; her entegrasyon, hataları hızla yakalamak için otomatik build ve testle doğrulanır. Fowler'a göre pratiği 1990'larda Kent Beck, Extreme Programming (XP) kapsamında geliştirdi. Saydığı kurallar arasında her push'un bir build tetiklemesi, bozulan build'in hemen düzeltilmesi ve build'in hızlı kalması var; çoğu proje için XP'nin on dakikalık build ölçüsünü makul buluyor. DORA da uzun ömürlü feature branch'ler yerine trunk'a en az günde bir merge yapılmasını öneriyor (Git yazımız).

CI'ın değeri testlere bağlı. DORA, otomatik testlerden on dakikadan kısa sürede geri bildirim alınmasını ve dengesiz (flaky) testlere göz yumulmamasını istiyor; elle yapılan regresyon testini ise darboğaz sayıyor.

Sürekli teslimat ile sürekli dağıtım farkı

Fowler'ın Continuous Delivery yazısına (30 Mayıs 2013) göre sürekli teslimat, yazılımı her an production'a çıkarılabilecek biçimde geliştirmektir; sık deploy edebilirsiniz ama yapıp yapmamayı siz seçersiniz. Sürekli dağıtımda ise her değişiklik pipeline'dan geçip production'a otomatik çıkar. AWS'ye göre ikisini ayıran şey, production'dan önce elle verilen onaydır.

GitHub Actions'ta bir environment için tanımlanan required reviewers kuralı, o environment'ı kullanan işleri belirli bir kişi ya da ekibin onayına bağlar; onay gelene kadar iş environment'ın sırlarını göremez. GitLab'da when: manual ile tanımlanan iş, bir kullanıcı başlatana kadar çalışmaz; belgeler bunu production'a deploy için örnekliyor.

CI/CD pipeline aşamaları

  1. Tetikleme: Ana branch'e gelen push ya da merge pipeline'ı başlatır.
  2. Build: Kod derlenir ve paketlenir; container kullanılıyorsa image üretilir (Docker yazımız).
  3. Test: Birim testlerinin ardından AWS'nin saydığı arayüz, yük, entegrasyon ve API güvenilirliği testleri gelir.
  4. Güvenlik taraması: GitLab'a göre SAST, kaynak koddaki açıkları production'a ulaşmadan bulur.
  5. Artifact: GitLab'ın tanımıyla bir işin ürettiği dosya ve dizin arşivi; deploy edilecek paket budur.
  6. Deploy: Paket önce test sistemine, sonra onayla ya da otomatik olarak production'a çıkar.

Aşağıdaki .gitlab-ci.yml örneğinde deploy elle başlatılıyor; stages tanımsız olduğu için GitLab varsayılan aşamaları (.pre, build, test, deploy, .post) kullanır:

build:
  stage: build
  script: [make build]
test:
  stage: test
  script: [make test]
deploy:
  stage: deploy
  script: [./deploy.sh production]
  when: manual

Jenkins nedir?

Belgelerine göre Jenkins; build, test ve deploy işlerini otomatikleştiren, kendi başına çalışan açık kaynak bir otomasyon sunucusu. İşletim sistemi paketleriyle ya da Docker ile kurulabilir, Java Runtime Environment (JRE) kurulu herhangi bir makinede tek başına da çalışabilir. Yetenekleri eklentilerle genişler; proje sitesine göre 2.300'den fazla topluluk eklentisi var.

Ana özelliği Pipeline: pipeline, depoya commit edilen Jenkinsfile adlı metin dosyasında kodla tanımlanır. İki sözdizimi var: yazılması ve okunması kolay olsun diye tasarlanan Declarative ve node bloklarına dayanan Scripted.

Projenin eski adı Hudson'dı. Jenkins blogunun 11 Ocak 2011 tarihli yazısına göre Oracle'ın Hudson adı için marka başvurusu yapması üzerine proje ekibi yeni ad olarak Jenkins'i önerdi; 29 Ocak 2011'de açıklanan oylamada yeniden adlandırma 214'e karşı 14 oyla kabul edildi. Haftalık sürümlerin yanında, her 12 haftada bir taban sürüm seçilen bir LTS hattı var.

Jenkins belgeleri build'lerin controller'daki yerleşik node'da değil agent'larda çalışmasını öneriyor, çünkü yerleşik node'daki build controller'ın dosya sistemine Jenkins süreciyle aynı erişime sahip.

GitHub Actions, GitLab CI/CD ve Azure Pipelines

  • GitHub Actions: GitHub'ın CI/CD platformu. Workflow'lar .github/workflows dizinindeki YAML dosyalarında tanımlanır ve GitHub'ın sağladığı ya da sizin kurduğunuz runner'larda çalışır.
  • GitLab CI/CD: Pipeline, projenin kökündeki .gitlab-ci.yml dosyasında stage ve job'lardan kurulur; işleri GitLab.com'un hazır runner'ları ya da sizin kaydettiğiniz runner'lar yürütür.
  • Azure Pipelines: Microsoft'a göre Azure DevOps'un sürekli entegrasyon, sürekli test ve sürekli teslimatı birleştiren parçası.

Dağıtım stratejileri: blue-green, canary ve rolling

  • Blue-green: Fowler'ın tarifiyle olabildiğince aynı iki production sistemi tutulur; router yeni sürümün çalıştığı sisteme çevrilir, sorun çıkarsa eskisine geri alınır (load balancer yazımız). Veritabanları bu teknikte çoğu zaman zorluk çıkarır.
  • Canary: Danilo Sato'nun 2014 tarihli yazısına göre yeni sürüm önce küçük bir kullanıcı grubuna açılır; geri dönüş, kullanıcıları eski sürüme yönlendirmekten ibaret.
  • Rolling: AWS'ye göre eski sürüm adım adım yenisiyle değiştirilir; daha çabuk biter, ama iki sürüm arasında yalıtım yoktur ve geri dönüş zorlaşır (Kubernetes yazımız).

GitOps'ta deploy'u pipeline itmez: OpenGitOps ilkelerine (v1.0.0) göre istenen durum IaC gibi bildirimsel ve sürümlü biçimde saklanır, ajanlar onu kaynaktan çeker ve sistemi sürekli ona yaklaştırır (Git yazımız).

Pipeline güvenliği: OWASP, SLSA ve NIST

OWASP'ın Top 10 CI/CD Security Risks listesi savunmacıların odaklanacağı on alanı sayıyor; aralarında zehirlenmiş pipeline çalıştırma (Poisoned Pipeline Execution), yetersiz kimlik bilgisi hijyeni ve artifact bütünlüğünün doğrulanmaması var. OWASP, gözden geçirilmemiş kodu çalıştıran pipeline'ların sırlara erişmeyen yalıtılmış node'larda çalışmasını öneriyor.

GitHub'ın güvenlik kaydına göre Mart 2025'te bir tedarik zinciri saldırısı tj-actions/changed-files action'ını ele geçirip 23.000'den fazla depoyu etkiledi: saldırganlar sürüm etiketlerini (tag) zararlı bir commit'e yönlendirdi, sırlar workflow loglarına düştü ve kayıt bu sırların hemen yenilenmesini istiyor. GitHub'ın güvenli kullanım belgesi bağımlılıkları lockfile ile kilitlemeyi, bu mümkün değilse action'ları commit SHA'sına sabitlemeyi öneriyor; tag ise depoya erişen biri tarafından taşınabilir.

OpenSSF bünyesindeki SLSA (Supply-chain Levels for Software Artifacts), kurcalamayı önlemeye yönelik bir kontrol listesi. Onaylı 1.2 sürümünde build düzeyleri provenance kaydıyla (L1) başlıyor, bu kaydı imzalayan barındırılan platforma (L2) ve güçlendirilmiş build'lere (L3) uzanıyor. NIST'in Şubat 2024 tarihli SP 800-204D belgesi de pipeline'ı aktif savunmayı ve kaynak ile artifact bütünlüğünü korumayı iki ana hedef sayıyor.

Sırların (secrets) yönetimi

  • Koda yazmamak: GitHub'a göre hassas veri workflow dosyalarında asla düz metin durmamalı; GitLab da token ve parolaları .gitlab-ci.yml yerine arayüz ayarlarında tutmayı istiyor (Git yazımız).
  • Kapsamı daraltmak: GitLab'ın protected değişkenleri yalnız korumalı branch ve tag'lerdeki pipeline'lara açılır; GitHub, GITHUB_TOKEN yetkilerini gereken en düşük düzeyde tutmayı öneriyor (IAM yazımız).
  • Kısa ömürlü kimlik: OWASP statik yerine geçici kimlik bilgisini, GitHub OpenID Connect ile üretilen kısa ömürlü token'ı öneriyor.
  • Loglara güvenmemek: GitLab'a göre maskelemek, değerin kötü niyetli kullanıcılarca okunmasını kesin olarak engellemez (log yazımız).

Pipeline kurulumunu ve sır yönetimini DevOps & CI/CD Enablement, standart şablonları DevOps ve platform mühendisliği, günlük işletimi DevOps çözümleri hizmetimizde ele alıyoruz.

Sık sorulan sorular

Jenkins nedir, ne işe yarar? Build, test ve deploy işlerini otomatikleştiren açık kaynak bir otomasyon sunucusu. Pipeline'lar depoya commit edilen bir Jenkinsfile ile tanımlanabilir.

CI/CD ne demek? Continuous integration ve continuous delivery (ya da deployment) kısaltması. Kod değişikliklerinin otomatik build, test ve deploy ile production'a taşınmasını anlatır.

Continuous integration (sürekli entegrasyon) nedir? Herkesin değişikliklerini en az günde bir kez ortak ana branch'e merge etmesi ve her merge işleminin otomatik build ve testle doğrulanması.

Sürekli teslimat ile sürekli dağıtım arasındaki fark nedir? Sürekli teslimatta production'a son adım bir onayla atılır. Sürekli dağıtımda testleri geçen her değişiklik kendiliğinden çıkar.

Kaynaklar