Modern Bir CI/CD Pipeline Nasil Insa Edilir

Bir CI/CD pipeline i, kod ile kullanici arasindaki en kritik koprudur. Pipeline ne kadar iyi calisirsa, ekibiniz o kadar hizli ve guvenilir bir sekilde ozellik gonderebilir. Ancak bir pipeline i dogru sekilde insa etmek, sadece bir GitHub Actions veya GitLab CI dosyasi yazmaktan ibaret degildir.

Bu rehber, bir pipeline in her katmanini ele aliyor. Kod gonderme anindan uretime kadar her adimi, her adimda hangi sorunu cozdugunuzu bilerek insa edeceksiniz. Amac, tool secimi degil, dogru prensipleri anlamaktir.

Pipeline katmanlari

Modern bir pipeline, cesitli katmanlardan olusur. Her katman bir onceki katmanin ciktisina guvenir ve bir sonraki katmana gecmeden once belirli kosullari karsilamalidir. Bu katmanlari sirasiyla ele alalim.

1. Dogrulama katmani

Bu katman, kod gonderme aninda calisir. En kisa surede geri bildirim saglamak uzere tasarlanmistir. Genellikle su adimlari icerir: lint kontrolu, tip kontrolu, birim testleri ve statik analiz.

Dogrulama katmani, pipeline in en hizli katmani olmalidir. Gelistirici kodunu gonderdikten sonraki 2-3 dakika icinde geri bildirim almalidir. Bu katman basarisiz oldugunda, pipeline durur ve gelistirici hatayi duzeltir.

2. Derleme ve paketleme katmani

Bu katman, uygulamayi derler, testleri calistirir ve konteyner imajini veya derlenmis ciktiyi olusturur. Katmanli bir yapi kullanarak onbellegi verimli bir sekilde kullanmak onemlidir. Docker da bagimliliklari once, kodu sonra kopyalamak, derleme suresini onemli olcude azaltir.

Paketleme adiminda, imaj etiketlemesi kritik bir konudur. latest etiketi yerine commit SHA si veya semantik surum kullanmak, her imajin benzersiz ve izlenebilir olmasini saglar. Ayrica, imajin bir dijital imza ile imzalanmasi, uretimde calisan imajin gercekten dogru kaynaktan geldigini dogrular.

# Example: GitLab CI with layer caching
build:
  stage: build
  image: docker:24
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build
        --cache-from $CI_REGISTRY_IMAGE:cache
        --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
        .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  cache:
    paths:
      - .npm/
      - node_modules/

3. Test katmani

Test katmani, birim testlerinin otesine gecer. Entegrasyon testleri, uctan uca testler ve performans testlerini icerir. Her test turunun pipeline icinde farkli bir yeri ve amaci vardir.

• Birim testleri: Her commit te calisir. En hizli testlerdir ve kodun mantigini dogrular.
• Entegrasyon testleri: Birim testlerinden sonra calisir. Veritabani, API veya harici servislerle etkilesimi test eder.
• Uctan uca testler: Tum sistemi test eder. Genellikle bir staging ortaminda calisir ve daha yavas oldugu icin her commit te degil, gunde birkac kez calistirilabilir.
• Performans testleri: Kritik yol uzerindeki islemlerin belirli bir sure sinirinin altinda kaldigini dogrular. Basarisiz oldugunda, pipeline in durmasi gerekmez ancak bir uyari olusturulmalidir.

4. Dagittim katmani

Dagittim katmani, uygulamayi hedef ortama gonderir. Bu katman, ortam yonetimi ve kademeli dagittim stratejilerini icerir. En yaygin kademeli dagittim stratejileri: mavi-yesil (blue-green) dagittim, kanarya (canary) dagittim ve kademeli (rolling) guncellemedir.

Kanarya dagittim, yeni bir surumu once kucuk bir kullanici grubuna acmayi icerir. Bu sayede, sorunlu bir surum tum kullanicilari etkilemeden once tespit edilip geri alinabilir. Kanarya dagittim icin, yeni surumun metriklerini (hata orani, gecikme, kaynak kullanimi) bir onceki surumle karsilastiran bir izleme sistemi gereklidir.

Ortam yonetimi

Ortam yonetimi, pipeline in en cok ihmal edilen yonlerinden biridir. Gelistirme, staging ve uretim ortamlari arasindaki farkliliklar, en cok hatanin ortaya ciktigi yerdir. Modern bir pipeline, ortamlar arasinda tutarliligi saglamalıdır.

Altyapiyi kod olarak (Infrastructure as Code) yonetmek, bu sorunu cozmenin en iyi yoludur. Terraform, Pulumi veya AWS CDK gibi araclar, tum ortamlari ayni kod tabanindan olusturmanizi saglar. Boylece staging de calisan bir yapi, uretimde de ayni sekilde calisir.

Ortamlar arasindaki farkliliklari yonetmek icin, ortama ozgu yapilandirma bilgilerini (environment variables, secret lar) merkezi bir sekilde yonetmek gerekir. Vault, AWS Secrets Manager veya Doppler gibi araclar, secret lari guvenli bir sekilde saklamak ve pipeline a enjekte etmek icin kullanilabilir.

Pipeline da guvenlik

Pipeline guvenligi, hem pipeline in kendisini korumayi hem de uretime giden kodun guvenligini saglamayi icerir. Guvenlik onlemleri, pipeline in her katmanina entegre edilmelidir. Ayri bir guvenlik adimi sonradan eklenen bir eklenti degil, tum surecin bir parcasi olmalidir.

• Bagimlilik taramasi: npm audit, pip audit, Snyk veya Dependabot ile bagimliliklardaki bilinen guvenlik aciklarini tarayin.
• Statik analiz: SonarQube, ESLint guvenlik kurallari veya Semgrep ile koddaki guvenlik aciklarini tarayin.
• Imaj taramasi: Docker imajlarini Trivy veya Clair ile tarayarak, temel imajdaki guvenlik aciklarini tespit edin.
• Imaj imzalama: Docker Content Trust veya Cosign ile imajlari imzalayarak, uretimde yalnizca dogrulanmis imajlarin calismasini saglayin.
• Erisim kontrolu: Pipeline in kullandigi secret lara ve ortam degiskenlerine erisimi kisitlayin. Her pipeline adimi, yalnizca ihtiyaci olan izinlere sahip olmalidir.

Pipeline guvenligi, ozellikle supply chain saldirilarinin arttigi gunumuzde kritik bir konudur. Bir pipeline in ele gecirilmesi, saldirgana dogrudan uretime erisim saglayabilir. Bu nedenle pipeline in kendisinin de guvenligi, uygulama guvenligi kadar onemlidir.

Pipeline performansi ve geri bildirim

Bir pipeline ne kadar hizliysa, gelistiriciler o kadar hizli geri bildirim alir. Pipeline hizini artirmak icin cesitli stratejiler vardir. Paralel calisan adimlar, pipeline in toplam suresini azaltir. Ornegin, lint, tip kontrolu ve birim testleri paralel olarak calisabilir.

Onbellekleme, pipeline performansinin bir diger onemli bilesenidir. Bagimliliklarin, Docker katmanlarinin ve derleme ciktilarinin onbelleklenmesi, pipeline i onemli olcude hizlandirabilir. Ancak onbellek yonetimi dikkatli yapilmalidir; asiri buyuyen bir onbellek, pipeline i yavaslatabilir.

Pipeline in basarisiz oldugu durumlarda, hizli ve net geri bildirim saglamak onemlidir. Basarisiz olan adimin ciktisini, hangi testin basarisiz oldugunu ve nedenini acikca belirtmek, gelistiricinin sorunu hizla cozmesine yardimci olur.

CI/CD de yaygin hatalar

• Pipeline i cok uzun yapmak: 15 dakikadan uzun surem pipeline lar, gelistiricilerin dikkatini dagitir. Pipeline i daha kisa parcaciklara bolun.
• Uretim ortamina dogrudan gondermek: Her zaman bir staging veya test ortamindan gecmek, sorunlari erken tespit etmenizi saglar.
• Secret lari pipeline yapilandirmasinda saklamak: Secret lar, ortam degiskenleri olarak veya bir secret yoneticisi uzerinden saglanmalidir.
• Pipeline i yalnizca basarili oldugunda kontrol etmek: Basarisiz pipeline lari duzenli olarak gozden gecirin ve tekrar eden sorunlari cozun.
• Testleri yeterli kapsamda calistirmamak: Her commit te birim testleri ve entegrasyon testleri calismalidir. Uctan uca testler, gunde en az bir kez calistirilmalidir.

CI/CD pipeline lari, ekiplerin yazilim teslim hizini belirleyen en kritik faktorlerden biridir. Dogru insa edilmis bir pipeline, ekibinize hem hiz hem de guven saglar.