CI/CD ve DevOps Rehberi: Pipeline Nasıl Kurulur?

Bir geliştirici kodunu ana dala birleştirdiğinde dakikalar içinde otomatik testler çalışır, derleme kontrol edilir, sorun yoksa değişiklik üretime gider. Beş yıl önce bu süreç elle yapılan testler ve gece yarısı riskli dağıtımlarla haftalar sürüyordu. Bu dönüşümün adı CI/CD ve DevOps. Bu yazıda ikisinin ne olduğunu, bir pipeline'ın gerçekte nasıl işlediğini ve küçük bir ekibin nereden başlayabileceğini somut örneklerle ele alıyorum.

CI/CD tam olarak ne anlama gelir?

CI/CD, "Continuous Integration / Continuous Delivery" yani Sürekli Entegrasyon / Sürekli Teslimat kısaltmasıdır. Sürekli Entegrasyon (CI), geliştiricilerin kod değişikliklerini günde birkaç kez merkezi bir depoda birleştirmesi ve her birleştirmenin otomatik olarak derlenip test edilmesidir. Amaç, entegrasyon sorunlarını küçükken yakalamaktır; sorun büyüyüp karmaşıklaşmadan önce fark edilir.

Sürekli Teslimat (CD), testlerden geçen kodun her zaman dağıtıma hazır durumda tutulmasıdır. Bazı ekipler bunu bir adım öteye taşıyıp sürekli dağıtım (continuous deployment) uygular; bu durumda testi geçen her değişiklik, manuel onay beklemeden otomatik olarak üretime çıkar. Aradaki fark nettir: sürekli teslimatta yayın kararını hâlâ bir kişi verir, sürekli dağıtımda bu karar da otomatikleşir.

Bu ayrımı netleştirmek ekip içi beklenti yönetimi açısından önemlidir. Bir ekip "CI/CD kullanıyoruz" dediğinde bu, testlerin otomatik çalıştığı ama dağıtımın hâlâ manuel onayla yapıldığı anlamına gelebilir. Başka bir ekip için ise aynı cümle, her commit'in dakikalar içinde üretime çıktığı anlamına gelir. İkisi de geçerli CI/CD uygulamasıdır, sadece olgunluk seviyeleri farklıdır.

Basit bir CI/CD pipeline'ı nasıl görünür?

GitHub Actions üzerinde bir Node.js projesi için tipik bir pipeline şöyle tanımlanır:

name: CI Pipeline
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install
      - run: npm test
      - run: npm run build

Bu dosya ana dala her push işleminde tetiklenir, bağımlılıkları kurar, testleri çalıştırır ve derleme yapar. Herhangi bir adım başarısız olursa pipeline durur, geliştiriciye bildirim gider; kod, testleri geçmeden ana dala giremez.

Bu tanım dosyasının en değerli yanı sürüm kontrollü olmasıdır. Pipeline'ı değiştirdiğinizde bu değişiklik de bir commit olarak geçmişe kaydedilir, "geçen ay pipeline neden farklı çalışıyordu" sorusuna git blame ile cevap bulabilirsiniz. Eskiden bir CI sunucusunun arayüzünden elle yapılan bu tür ayarlar, artık kodun kendisi kadar izlenebilir hâle geliyor.

Tipik bir pipeline dört aşamadan oluşur: kod entegrasyonu (push tetikleyicisi), derleme (build), test (birim ve entegrasyon testleri) ve dağıtım hazırlığı. Her aşama bir öncekinin başarısına bağlıdır. Testler geçmezse derleme adımına geçilmez, derleme başarısız olursa dağıtım hiç gündeme gelmez. Bu sıralı doğrulama, üretime bozuk kod gitme riskini büyük ölçüde azaltır.

DevOps, CI/CD'den farklı bir şey mi?

CI/CD bir dizi teknik uygulamayken, DevOps çok daha geniş bir kültürdür. Geleneksel olarak geliştirme ekibi kodu yazar, operasyon ekibi onu çalıştırırdı; bu ayrım genellikle "kod bende çalışıyordu" tartışmalarına ve yavaş, sürtüşmeli dağıtımlara yol açıyordu. DevOps bu iki ekibi aynı hedef etrafında birleştirir: yazılımı hem geliştirmek hem de güvenilir biçimde çalışır tutmak ortak sorumluluk hâline gelir.

DevOps kültürünün somut yansımaları vardır. Altyapının kod olarak yönetilmesi (Infrastructure as Code), sunucu ayarlarını elle tıklamak yerine Terraform veya Ansible gibi araçlarla, sürüm kontrollü dosyalar hâlinde tanımlamak anlamına gelir. Bir Terraform dosyası şöyle görünebilir:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  tags = {
    Name = "web-sunucu"
  }
}

Bu yaklaşımın avantajı açıktır: sunucu yapılandırması artık bir kişinin kafasında değil, Git geçmişinde durur. Bir sorun çıktığında hangi değişikliğin ne zaman yapıldığını git log ile görebilirsiniz.

İzleme ve gözlemlenebilirlik, DevOps kültürünün bir diğer temel bileşenidir. Bir uygulamanın ne kadar sürede yanıt verdiğini, hata oranının ne olduğunu ve kaynak kullanımının nasıl seyrettiğini sürekli izlemek, sorunları kullanıcı şikayet etmeden önce fark etmenizi sağlar. Prometheus, Grafana gibi açık kaynak araçlar, bu izlemeyi görselleştirilebilir panolara dönüştürür.

CI/CD ve DevOps somut olarak ne kazandırıyor?

Daha hızlı teslimat en görünür faydadır. Otomatik pipeline'lar sayesinde aylar süren sürüm döngüleri günlere, hatta saatlere iner. Asıl fark ise sürüm başına düşen risktir: büyük ve nadir yayınlar yerine küçük ve sık yayınlar yapıldığında, bir sorun çıktığında hangi değişikliğin sebep olduğunu bulmak çok daha kolaydır.

Bu tablo, DORA (DevOps Research and Assessment) metriklerinin basitleştirilmiş bir özetidir. Dağıtım sıklığı, değişiklik başına hata oranı ve ortalama kurtarma süresi gibi ölçümler, bir ekibin CI/CD olgunluğunu somut sayılarla gösterir. Bu metrikleri takip etmek, "daha iyiye gidiyor muyuz" sorusuna öznel değil sayısal bir cevap verir.

Bu metrikleri ilk ölçtüğünüzde rakamların kötü çıkması normaldir; önemli olan başlangıç noktasını bilmek ve zamanla iyileştirmektir. Bir ekip ortalama kurtarma süresini birkaç saatten birkaç dakikaya indirdiğinde bunun sebebi genellikle daha akıllı mühendisler değil, daha iyi izleme ve daha küçük, daha sık dağıtımlardır. Küçük değişiklikler, büyük değişikliklere göre hem test etmesi hem de geri almak açısından çok daha az risk taşır.

Küçük bir ekip nereden başlamalı?

Sıfırdan mükemmel bir pipeline kurmaya çalışmak, çoğu ekibin başlamadan vazgeçtiği noktadır. Basit bir başlangıç şöyle olabilir:

• Kod deposunu Git'e taşıyın (henüz taşımadıysanız)
• Her push'ta otomatik test çalıştıran basit bir pipeline kurun (GitHub Actions, GitLab CI gibi ücretsiz seçenekler vardır)
• Testler geçmeden ana dala birleştirmeyi engelleyen bir kural (branch protection) ekleyin
• Derleme adımını pipeline'a dahil edin
• Dağıtımı kademeli olarak otomatikleştirin: önce staging ortamına, sonra üretime

Her adım bir öncekinin üzerine kurulur. İlk hafta sadece testleri otomatikleştirmek bile "kod ana dala girdi ama bozuktu" senaryosunu büyük ölçüde ortadan kaldırır. Mükemmel bir kurulum beklemek yerine basit bir pipeline'la başlayıp zamanla geliştirmek, gerçekte işe yarayan yaklaşımdır.

Tek kişilik bir projede de bu adımların değeri vardır. Kişisel bir proje deposuna push yaptığınızda testlerin otomatik çalışması, "bunu elle test etmeyi atladım" hatasını ortadan kaldırır. Küçük ölçekte kurulan bu alışkanlık, ileride bir ekibe katıldığınızda veya ekibiniz büyüdüğünde doğrudan işe yarayan bir refleks hâline gelir. Kendi deponuzda otomatik test ve dağıtım hattı kurmak için GitHub Actions'ın resmi belgeleri pratik bir başlangıç sunar.

Kültürel değişim neden teknik kısımdan daha zor?

Araçları kurmak nispeten kolay kısımdır; asıl zorluk ekiplerin çalışma biçimini değiştirmektir. Bir hata üretime çıktığında DevOps kültürü suçlu aramak yerine "bu neden pipeline'da yakalanmadı" sorusunu sorar ve süreci buna göre iyileştirir. Bu zihniyet değişimi, özellikle uzun süre ayrı çalışmış geliştirme ve operasyon ekiplerinde zaman alır.

Bazı ekipler DevOps araçlarını (CI/CD pipeline'ı, konteynerler, izleme panoları) eksiksiz kurar ama kültürel tarafı atlar; sonuç hızlı ama hâlâ sürtüşmeli bir süreç olur. Araçlar olmadan kültür de tek başına yetmez. İyi niyetli bir işbirliği kültürü, elle yapılan tekrarlayan işleri ortadan kaldırmaz. İkisi birlikte ilerlediğinde asıl dönüşüm gerçekleşir.

Liderlik desteği burada belirleyici bir rol oynar. Ekipler arasındaki sorumluluk sınırlarını kaldırmak, ortak metrikler tanımlamak (yalnızca "kaç özellik çıktı" değil, "kaç hata üretime kaçtı" da) ve başarısızlıkları öğrenme fırsatı olarak ele almak, yönetimin açıkça desteklemesi gereken kararlardır. Bu destek olmadan, en iyi CI/CD altyapısı bile eski alışkanlıkları değiştirmeye yetmez.

Postmortem (olay sonrası inceleme) toplantıları bu kültürün somut bir uygulamasıdır. Bir kesinti veya hata sonrasında yapılan bu toplantılarda amaç "kim hata yaptı" değil "sistem neden bu hatayı önleyemedi" sorusuna cevap bulmaktır. Suçlamasız (blameless) postmortem kültürü, ekip üyelerinin sorunları saklamak yerine açıkça raporlamasını teşvik eder; bu da benzer hataların tekrarlanma olasılığını azaltır.

Dağıtım stratejisi seçimi de pratik bir karar noktasıdır. Mavi-yeşil dağıtım (blue-green deployment), yeni sürümü ayrı bir ortamda çalıştırıp trafiği bir anda yeni ortama geçirir. Kademeli dağıtım (canary release) ise yeni sürümü önce kullanıcıların küçük bir yüzdesine gösterir, sorun yoksa yaygınlaştırır. Küçük ekipler için kademeli dağıtım genellikle daha güvenli bir başlangıç noktasıdır; hatayı tüm kullanıcılara yaymadan önce fark etme şansı verir.

CI/CD ve DevOps'a geçişte en pratik tavsiye şudur: mükemmel bir pipeline'ı beklemeden bugün elinizdeki en basit otomasyonu kurun ve her hafta bir adım iyileştirin. Programlar kategorisindeki diğer rehberler bu geçiş sürecinde işinize yarayacak ek araç ve pratik öneriler barındırıyor. GitHub Actions'ın resmi dokümantasyonu da, pipeline yazarken karşılaşacağınız çoğu senaryo için hazır örnekler sunar.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.