CI'da Kırılan, Kendi Makinenizde Çalışan Kod: Sebepler ve Çözümler Rehberi

CI’da Kırılan, Kendi Makinenizde Çalışan Kod: Sebepler ve Çözümler Rehberi

Her geliştiricinin en az bir kez karşılaştığı o sinir bozucu anı düşünün: Kodunuz kendi makinenizde sorunsuz çalışıyor, tüm testler geçiyor, her şey yolunda görünüyor. Ancak kodu Sürekli Entegrasyon (CI) ortamına gönderdiğinizde, beklenmedik bir hata fırlatıyor ve tüm derleme (build) süreci başarısız oluyor. Bu durum, sadece can sıkıcı olmakla kalmaz, aynı zamanda değerli zamanınızı ve ekibinizin verimliliğini de olumsuz etkiler. Peki, bu “benim makinemde çalışıyordu” sendromunun arkasında yatan gerçek sebepler nelerdir ve bu sorunları nasıl kalıcı olarak çözebiliriz? Bu makalede, kodunuzla doğrudan ilgili olmayan ancak CI başarısızlıklarına yol açan yaygın nedenleri derinlemesine inceleyecek, pratik çözümler sunacak ve geliştirme süreçlerinizi daha güvenilir hale getirmenize yardımcı olacak stratejileri tartışacağız.

Neden Benim Makinemde Çalışıyor da CI’da Kırılıyor? Temel Farklılıklar Nelerdir?

Geliştiriciler olarak, kodumuzun yerel ortamımızda beklediğimiz gibi çalışması, bize bir güven hissi verir. Ancak bu güven, CI ortamında bir anda yıkılabilir. Bu durumun temelinde yatan neden, yerel geliştirme ortamınız ile CI ortamınız arasındaki görünmez ama kritik farklılıklardır. Bu farklılıklar, işletim sistemi seviyesinden başlayıp, kullanılan yazılım sürümlerine ve hatta sistem kaynaklarına kadar geniş bir yelpazeyi kapsar. Bu bölümde, bu temel farklılıkları ve bunların CI başarısızlıklarına nasıl yol açtığını detaylı bir şekilde ele alacağız.

Temel Kavramlar: CI ve Yerel Geliştirme Ortamı Nedir?

Öncelikle, konuya yabancı okuyucularımız için bu iki temel kavramı netleştirelim. Yerel Geliştirme Ortamı, bir geliştiricinin kendi bilgisayarında kurduğu ve kod yazıp test ettiği ortamdır. Bu ortam, genellikle geliştiricinin kişisel tercihlerine göre yapılandırılmıştır; belirli bir işletim sistemi (Windows, macOS, Linux), programlama dili sürümleri, veritabanları ve diğer araçlarla donatılmıştır. Her geliştiricinin kendi makinesi, kendine özgü bir “ekosistem” gibidir. Öte yandan, Sürekli Entegrasyon (CI), yazılım geliştirme sürecinde kod değişikliklerinin düzenli olarak merkezi bir depoya entegre edildiği ve otomatik testlerden geçirildiği bir uygulamadır. CI sistemleri (örneğin Jenkins, GitLab CI, GitHub Actions, CircleCI), genellikle bulut tabanlı sanal makinelerde veya özel sunucularda çalışır. Bu ortamların temel amacı, geliştirme sürecindeki hataları erken aşamada tespit etmek ve kod tabanının her zaman çalışır durumda olmasını sağlamaktır. CI ortamları, genellikle daha standartlaştırılmış ve kontrollü bir yapıya sahiptir, ancak bu standardizasyon bazen yerel ortamlarla uyumsuzluklara yol açabilir.

Ortam Farklılıkları: İşletim Sistemi, Yazılım Sürümleri ve Çevre Değişkenleri Nasıl Etkiler?

CI ve yerel ortamlar arasındaki en yaygın farklılıklar genellikle üç ana başlık altında toplanır: işletim sistemi, yazılım sürümleri ve çevre değişkenleri. Her birinin, kodunuzun davranışını nasıl etkileyebileceğini anlamak, sorun giderme sürecinde kritik öneme sahiptir.

İlk olarak, işletim sistemi farklılıkları büyük bir rol oynayabilir. Yerel makinenizde Windows kullanırken, CI ortamınızın Linux tabanlı bir sunucuda çalışması oldukça yaygındır. Dosya yolu ayırıcıları (\ yerine /), büyük/küçük harf duyarlılığı (Windows’ta genellikle duyarsız, Linux’ta duyarlı), veya belirli sistem çağrılarının farklı işletim sistemlerinde farklı davranışlar sergilemesi gibi durumlar, yerelde sorunsuz çalışan kodun CI’da hata vermesine neden olabilir. Örneğin, bir dosya yolunu elle oluştururken büyük/küçük harf hatası yapmanız, Windows’ta göz ardı edilebilirken Linux CI’da “dosya bulunamadı” hatasına yol açabilir. Bu nedenle, platformdan bağımsız kod yazmak ve dosya yolu manipülasyonları için standart kütüphaneleri kullanmak önemlidir.

İkinci olarak, yazılım sürümleri arasındaki uyumsuzluklar belki de en sık karşılaşılan problem kaynağıdır. Yerel makinenizde Node.js 16, Python 3.9, Java 17 veya belirli bir veritabanı (PostgreSQL 14) kurulu olabilir. Ancak CI ortamınızda bu yazılımların farklı, muhtemelen daha eski veya daha yeni bir sürümü (Node.js 14, Python 3.8, Java 11, PostgreSQL 12) yüklü olabilir. Bu sürüm farklılıkları, dilin veya kütüphanelerin belirli özelliklerinin eksik olmasına, API değişikliklerine veya uyumluluk sorunlarına yol açabilir. Örneğin, Node.js’in daha yeni bir sürümünde tanıtılan bir JavaScript sözdizimi özelliğini kullanmanız, eski bir Node.js sürümüne sahip CI ortamında bir sözdizimi hatası (syntax error) olarak dönecektir. Benzer şekilde, veritabanı sürümleri arasındaki farklar, SQL sorgularının veya veritabanı sürücülerinin farklı davranmasına neden olabilir. Bu tür sorunları önlemek için, projenizin kullandığı tüm temel yazılımların ve dillerin sürümlerini açıkça belirtmek ve hem yerel hem de CI ortamında bu sürümleri kullanmayı zorunlu kılmak esastır. Örneğin, Node.js projeleri için .nvmrc dosyası veya Docker konteynerleri kullanarak ortamı sabitleyebilirsiniz.

Son olarak, çevre değişkenleri de önemli bir faktördür. Geliştirme sürecinde kullanılan API anahtarları, veritabanı bağlantı dizeleri, ortam modları (NODE_ENV=development) veya diğer yapılandırma ayarları, yerel makinenizde genellikle .env dosyaları aracılığıyla veya doğrudan sisteminizde tanımlanmış olabilir. Ancak CI ortamında bu değişkenlerin farklı değerlere sahip olması veya hiç tanımlanmamış olması mümkündür. Örneğin, yerelde bir geliştirme veritabanına bağlanırken, CI ortamında bir test veritabanına veya farklı bir API uç noktasına bağlanılması gerekebilir. Bu değişkenlerin yanlış yapılandırılması, uygulamanın beklenen kaynaklara erişememesine veya yanlış davranış sergilemesine neden olabilir. Bu nedenle, çevre değişkenlerinin yönetimi ve CI ortamında güvenli bir şekilde sağlanması büyük önem taşır.

Tüm bu farklılıkları göz önünde bulundurarak, geliştiricilerin yerel ortamlarını CI ortamlarına mümkün olduğunca benzetmeye çalışmaları kritik bir adımdır. Docker gibi konteyner teknolojileri, bu tutarlılığı sağlamak için mükemmel bir çözüm sunar, çünkü hem yerelde hem de CI’da aynı “kapsüllenmiş” ortamın kullanılmasını garantiler.

Bağımlılık Yönetimi: Paket Sürümleri ve Çözümlenmemiş Bağımlılıklar CI Başarısızlıklarının Gizli Kahramanları mı?

Modern yazılım geliştirme, sayısız harici kütüphane ve paketin kullanımına dayanır. Bu bağımlılıklar, geliştirme sürecini hızlandırsa da, doğru yönetilmediklerinde CI başarısızlıklarının en yaygın nedenlerinden biri haline gelebilir. Yerel makinenizde kurulu olan bağımlılıkların CI ortamında farklı olması veya eksik kalması, kodunuzun beklenmedik şekillerde davranmasına yol açabilir. Bu bölümde, bağımlılık yönetiminin inceliklerini, paket kilit dosyalarının önemini ve bu alandaki yaygın sorunları nasıl aşabileceğimizi ele alacağız.

Paket Kilit Dosyalarının Önemi: Bağımlılık Cehenneminden Kurtulmak Mümkün mü?

Birçok programlama ekosistemi, projenin ihtiyaç duyduğu bağımlılıkları ve bunların sürümlerini tanımlamak için özel dosyalar kullanır: Node.js için package.json ve package-lock.json (veya yarn.lock), Python için requirements.txt veya Pipfile/Pipfile.lock, Ruby için Gemfile ve Gemfile.lock gibi. Bu dosyalar arasında önemli bir fark vardır:

Bildirim Dosyaları (Manifest Files): package.json (Node.js), Pipfile (Python), Gemfile (Ruby) gibi dosyalar, projenizin doğrudan bağımlı olduğu paketleri ve genellikle esnek sürüm aralıklarını (örneğin, ^1.0.0 veya ~2.1.0) belirtir. Bu esneklik, bağımlılıkların yeni yamalarla güncellenmesine olanak tanır, ancak aynı zamanda farklı zamanlarda kurulum yapıldığında farklı bağımlılık sürümlerinin yüklenmesine de neden olabilir.
Kilit Dosyaları (Lock Files): package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock gibi dosyalar ise, projenizin tam olarak hangi bağımlılık sürümleriyle (ana bağımlılıklar ve onların alt bağımlılıkları dahil) çalıştığını kesin olarak kaydeder. Bu dosyalar, bağımlılık grafiğinin tamamının anlık görüntüsünü içerir ve her bir paketin tam sürümünü, indirme kaynağını ve bütünlük sağlama (integrity) değerini belirtir.

Kilit dosyalarının önemi, tam da bu noktada ortaya çıkar. Yerel makinenizde npm install veya pip install komutunu çalıştırdığınızda, paket yöneticisi kilit dosyasını kontrol eder. Eğer bir kilit dosyası varsa, paket yöneticisi bağımlılıkları kilit dosyasında belirtilen kesin sürümlerle yüklemeye çalışır. Eğer kilit dosyası yoksa veya yok sayılırsa, paket yöneticisi bildirim dosyasındaki sürüm aralıklarına göre en güncel uygun sürümleri indirir. Bu durum, yerelde belirli bir sürümle çalıştığınız bir bağımlılığın, CI ortamında daha yeni (ve belki de uyumsuz) bir sürümünün yüklenmesine neden olabilir. Bu “bağımlılık cehennemi”, özellikle yarı-geçişli (transitive) bağımlılıklarda kendini gösterir; yani, sizin doğrudan kullanmadığınız ancak bağımlı olduğunuz bir paketin bağımlı olduğu başka bir paketin değişmesi. Bu tür durumlar, yerelde her şey yolunda giderken CI’da beklenmedik hatalara yol açabilir.

Bu nedenle, kilit dosyalarının Git gibi sürüm kontrol sistemlerine dahil edilmesi (commit edilmesi) kritik öneme sahiptir. Bu sayede, tüm ekip üyeleri ve CI ortamları, projenin her zaman aynı ve doğrulanmış bağımlılık kümesini kullanmasını garanti eder. Bu, “benim makinemde çalışıyor” sorununu büyük ölçüde ortadan kaldırır ve ortamlar arası tutarlılığı sağlar.


# Python için Pipfile.lock örneği
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]
requests = {version = "==2.28.1"}
django = {version = "==4.1.7"}

[dev-packages]
pytest = {version = "==7.2.1"}

# npm için package-lock.json'ın bir kısmı
{
  "name": "my-app",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "my-app",
      "version": "1.0.0",
      "dependencies": {
        "lodash": "^4.17.21"
      }
    },
    "node_modules/lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1K3/JXyBTdM2rdXfsPMglfsr-s6dlUyR6IdG6Wlq/klpPN1AALBwJg=="
    }
  }
}

Yukarıdaki örnekler, kilit dosyalarının bağımlılıkların tam sürümlerini ve kaynaklarını nasıl sabitlediğini göstermektedir. CI ortamında, npm ci (Node.js) veya pipenv install --deploy (Python) gibi komutlar kullanarak bağımlılıkların yalnızca kilit dosyalarından yüklenmesini sağlamak, bu tür sorunları önlemenin en etkili yollarından biridir.

Ayrıca, CI ortamında paket kurulumu sırasında ağ sorunları veya özel paket depolarına erişim eksikliği de bağımlılık sorunlarına yol açabilir. Örneğin, şirket içi bir paket yöneticisi kullanıyorsanız, CI ortamının bu depoya doğru kimlik bilgileriyle erişebildiğinden emin olmanız gerekir. Aksi takdirde, CI süreci gerekli paketleri bulamayıp başarısız olacaktır. Bu tür durumlar için, CI yapılandırmasında gerekli kimlik doğrulama adımlarını eklemek veya bağımlılıkları önbelleğe almak gibi stratejiler izlenebilir.

Kaynak Kısıtlamaları ve Zamanlama Sorunları: CI Ortamının Performans Sınırları ve Testlerin Güvenilmezliği

Kendi makinenizde çalışan bir uygulamanın CI ortamında başarısız olmasının bir başka önemli nedeni de, CI ortamının sahip olduğu kaynakların yetersiz olması veya testlerin zamanlama hassasiyetinden kaynaklanan güvenilmezliklerdir. Yerel geliştirme makineleri genellikle bol miktarda RAM, hızlı işlemciler ve geniş depolama alanına sahipken, CI ortamları daha kısıtlı kaynaklarla çalışabilir. Bu durum, özellikle büyük projelerde veya yoğun test senaryolarında kendini gösterir. Bu bölümde, kaynak kısıtlamalarının ve zamanlama sorunlarının CI başarısızlıklarına nasıl yol açtığını ve bu tür sorunları nasıl ele alabileceğimizi inceleyeceğiz.

Bellek, CPU ve Disk Alanı Kısıtlamaları: CI Runner’ları Neden Daha Yavaş Olabilir?

CI sunucuları veya “runner”ları, genellikle paylaşımlı kaynaklara sahip sanal makinelerdir. Yani, bir CI runner’ı aynı anda birden fazla projenin derlemesini veya testini çalıştırıyor olabilir. Bu durum, her bir derleme sürecine ayrılan CPU (işlemci) gücünün, RAM (bellek) miktarının ve hatta disk G/Ç (giriş/çıkış) hızının yerel makinenizdeki kadar yüksek olmamasına neden olabilir. Bu kısıtlamalar, çeşitli sorunlara yol açabilir:

Performans Düşüşü ve Zaman Aşımı (Timeout) Hataları: Büyük kod tabanlarının derlenmesi, karmaşık bağımlılıkların yüklenmesi veya yoğun entegrasyon testlerinin çalıştırılması, önemli miktarda CPU ve bellek gerektirebilir. CI ortamındaki yetersiz kaynaklar nedeniyle bu işlemler yereldekinden çok daha uzun sürebilir ve CI sisteminin belirlediği zaman aşımı limitlerini aşarak başarısız olmasına neden olabilir. Örneğin, bir derleme adımı için 10 dakika süre tanınmışken, CI ortamındaki yavaşlık nedeniyle bu süre 15 dakikaya uzayabilir ve derleme zaman aşımına uğrayabilir.
Bellek Dışı (Out of Memory – OOM) Hataları: Özellikle Java, Node.js veya Python gibi bellek yoğun uygulamalarda, testler sırasında veya derleme aşamasında çok fazla bellek kullanılması, CI runner’ının bellek sınırlarını aşmasına neden olabilir. Bu durum, uygulamanın veya testlerin “Out of Memory” hatası vererek çökmesine yol açar. Yerel makinenizde 16 GB RAM varken, CI runner’ınızın sadece 4 GB RAM’e sahip olması, bu tür sorunların ortaya çıkışını tetikleyebilir.
Disk G/Ç Hızı ve Alan Kısıtlamaları: Büyük projelerde bağımlılıkların indirilmesi, derleme çıktılarının yazılması veya test verilerinin okunup yazılması, yoğun disk G/Ç işlemleri gerektirebilir. CI ortamında yavaş diskler veya yetersiz disk alanı, bu işlemlerin yavaşlamasına veya disk doluluğu nedeniyle başarısız olmasına neden olabilir. Özellikle önbellekleme (caching) stratejileri doğru uygulanmadığında, her CI çalıştırmasında bağımlılıkların yeniden indirilmesi ve derlenmesi disk kaynaklarını zorlayabilir.

Bu tür sorunları gidermek için, CI sağlayıcınızın sunduğu daha güçlü runner seçeneklerini değerlendirebilir, CI adımlarınızı daha küçük ve paralel çalışacak parçalara bölebilir veya kaynak yoğun testlerinizi optimize edebilirsiniz. CI loglarını dikkatlice incelemek, hangi aşamaların en çok zaman ve kaynak tükettiğini anlamanıza yardımcı olacaktır.

Zamanlama Hassasiyeti ve Yarış Koşulları (Race Conditions): Testlerin Kırılganlığı Nasıl Giderilir?

Zamanlama sorunları ve yarış koşulları (race conditions), özellikle asenkron işlemlerin veya eşzamanlı (concurrent) kodun test edildiği durumlarda ortaya çıkar. Yerel makinenizde belirli bir hızda ve sırada gerçekleşen olaylar, CI ortamında farklı bir zamanlamayla meydana gelebilir ve bu da testlerin bazen geçip bazen başarısız olmasına neden olan “kırılgan testler” (flaky tests) sorununa yol açar.

Asenkron İşlemler ve Gecikmeler: Bir test, bir veritabanı işleminin, bir API çağrısının veya bir UI animasyonunun tamamlanmasını beklerken, yerelde hızlı bir şekilde tamamlanan bu işlemler CI ortamında daha uzun sürebilir. Eğer test, bu işlemin tamamlanmasını yeterince beklemeden sonuca ulaşmaya çalışırsa, hatalı bir sonuçla karşılaşabilir. Örneğin, bir testin, bir kullanıcının kaydını tamamlamasını beklediği bir senaryoda, CI ortamındaki ağ gecikmesi nedeniyle kayıt işlemi beklenden uzun sürer ve test kullanıcının kaydedilmediğini varsayarak başarısız olur.
Yarış Koşulları: Birden fazla iş parçacığının veya işlemin paylaşılan bir kaynağa (veritabanı, dosya sistemi, bellek alanı) aynı anda erişmeye çalıştığı durumlarda ortaya çıkar. Yerelde belirli bir işlem sırası genellikle korunurken, CI ortamında farklı bir işlem sırası oluşabilir ve bu da veri tutarsızlıklarına veya beklenmedik hatalara yol açabilir. Örneğin, iki testin aynı anda aynı veritabanı kaydını güncellemeye çalışması, birinin diğerinin yaptığı değişikliği ezmesine neden olabilir.
Test Sırası Bağımlılığı: Bazı testler, kendilerinden önce çalışan diğer testlerin bıraktığı duruma bağımlı olabilir. Eğer testlerin çalışma sırası yerelde ve CI’da farklıysa, bu bağımlılıklar nedeniyle testler başarısız olabilir. İyi yazılmış testler, birbirinden bağımsız ve izole olmalıdır.

Kırılgan testleri gidermek için aşağıdaki stratejiler uygulanabilir:

Daha Sağlam Beklemeler Kullanma: Asenkron işlemler için sabit zaman gecikmeleri (Thread.sleep() gibi) yerine, belirli bir koşulun gerçekleşmesini bekleyen dinamik beklemeler (örneğin, bir elementin görünür olmasını beklemek) kullanın.
Test İzolasyonu ve Veri Temizliği: Her testin kendi bağımsız verisiyle çalışmasını sağlayın ve testler arasında veri paylaşımını önleyin. Her testten önce ve sonra veritabanını veya diğer paylaşılan kaynakları temizleyin.
Deterministik Testler Yazma: Testlerinizin her zaman aynı sonucu vermesini sağlayacak şekilde tasarlayın. Harici bağımlılıkları taklit etme (mocking/stubbing) tekniklerini kullanarak dış sistemlerin değişkenliğini ortadan kaldırın.
Tekrar Deneme Mekanizmaları (Retries): Bazı CI sistemleri, başarısız olan testleri otomatik olarak yeniden deneme (retry) seçeneği sunar. Bu, geçici ağ sorunları gibi kısa süreli sorunlardan kaynaklanan kırılganlıkları maskelemek için kullanılabilir, ancak kalıcı bir çözüm değildir.

Kırılgan testler, geliştirici güvenini azaltır ve CI sürecini yavaşlatır. Bu nedenle, bu testleri tespit etmek, analiz etmek ve düzeltmek için zaman ayırmak, uzun vadede büyük faydalar sağlayacaktır.

Yapılandırma ve Çevre Değişkenleri: CI Ortamına Özel Ayarların Yönetimi Nasıl Yapılır?

Uygulamalarımızın farklı ortamlarda (geliştirme, test, üretim) sorunsuz çalışabilmesi için yapılandırma (configuration) yönetimi kritik bir rol oynar. Veritabanı bağlantı dizeleri, API anahtarları, üçüncü taraf hizmet kimlik bilgileri ve diğer ortama özel ayarlar, yerel makinenizde farklı, CI ortamınızda ise bambaşka değerlere sahip olabilir. Bu farklılıklar, kodunuzun kendisi hatasız olsa bile CI derlemelerinin başarısız olmasına yol açabilir. Bu bölümde, hassas bilgilerin güvenli yönetimini ve farklı ortamlar için yapılandırma stratejilerini ele alacağız.

Hassas Bilgilerin Güvenli Yönetimi (Secrets Management): API Anahtarları ve Veritabanı Şifreleri Nasıl Saklanmalı?

Hassas bilgiler (secrets) olarak adlandırdığımız API anahtarları, veritabanı şifreleri, kimlik doğrulama tokenları gibi verilerin doğrudan kod tabanında veya sürüm kontrol sisteminde (Git) saklanması, ciddi güvenlik riskleri taşır. Bu nedenle, bu tür bilgileri güvenli bir şekilde yönetmek esastır. Yerel geliştirme ortamında, geliştiriciler genellikle .env dosyaları veya benzeri yerel yapılandırma dosyaları kullanarak bu bilgilere erişirler. Ancak bu dosyalar, genellikle .gitignore aracılığıyla sürüm kontrolünden hariç tutulur ve CI ortamına gönderilmez.

CI ortamında ise hassas bilgiler, genellikle CI sağlayıcısının (GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, AWS CodeBuild vb.) sunduğu “secrets management” (gizli bilgiler yönetimi) özelliklerini kullanarak yönetilmelidir. Bu özellikler, hassas verileri şifreli bir şekilde saklamanıza ve CI işleri çalıştırılırken bu verilere güvenli bir şekilde erişmenize olanak tanır. Örneğin:

GitHub Actions: Depo ayarlarında “Secrets” bölümü bulunur. Burada tanımlanan sırlar, CI iş akışlarınızda çevre değişkenleri olarak kullanılabilir.
GitLab CI/CD: Proje ayarlarında “CI/CD > Variables” altında gizli değişkenler tanımlanabilir.
Jenkins: “Credentials” eklentisi aracılığıyla API anahtarları, kullanıcı adları/şifreler gibi bilgiler güvenli bir şekilde saklanabilir ve Jenkins pipeline’larında kullanılabilir.

Bu mekanizmalar sayesinde, hassas veriler kod tabanından ayrı tutulur, sürüm kontrol sistemine sızma riski ortadan kalkar ve farklı CI ortamları için farklı gizli bilgiler tanımlanabilir. Örneğin, geliştirme ortamı için bir test veritabanı şifresi, üretim ortamı için ise gerçek bir üretim veritabanı şifresi CI’da ayrı ayrı yönetilebilir. Bu durum, yanlışlıkla üretim kimlik bilgilerinin test ortamında kullanılması gibi hataları önler.


# GitHub Actions'ta secret kullanımı örneği
name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy application
        run: |
          echo "Deploying to production..."
          # MY_API_KEY, GitHub repo secrets'ta tanımlanmış bir değişkendir
          # Bu değişken, CI ortamında güvenli bir şekilde erişilebilir.
          ./deploy_script.sh --api-key ${{ secrets.MY_API_KEY }} --env production

Yukarıdaki örnekte, secrets.MY_API_KEY ifadesi, GitHub Actions’ın gizli bilgiler yönetim sisteminden alınan bir değeri temsil eder. Bu yaklaşım, hassas verilerin kod içinde açıkça görünmesini engeller ve güvenlik risklerini minimize eder.

Farklı Ortamlar İçin Konfigürasyon Stratejileri: Geliştirme, Test ve Üretim Ortamları Arasındaki Geçişler

Uygulamalarımızın genellikle farklı ortamlarda (geliştirme, test, hazırlık, üretim) çalışması gerektiği için, her ortamın kendine özgü yapılandırma ihtiyaçları vardır. Örneğin, bir geliştirme ortamında yerel bir veritabanı veya sahte (mock) API’ler kullanılabilirken, test ortamında entegrasyon testleri için özel bir test veritabanı, üretim ortamında ise yüksek performanslı ve güvenli bir veritabanı sunucusu gerekebilir. Bu farklılıkları yönetmek için çeşitli stratejiler mevcuttur:

Ortam Değişkenlerine Dayalı Konfigürasyon: En yaygın ve esnek yaklaşımlardan biridir. Uygulama, başlangıçta çevre değişkenlerini okuyarak hangi ortamda çalıştığını anlar ve buna göre yapılandırma ayarlarını yükler. Örneğin, NODE_ENV=production veya ASPNETCORE_ENVIRONMENT=Development gibi değişkenler, uygulamanın farklı yapılandırma dosyalarını veya mantık dallarını tetiklemesini sağlar. Bu, CI ortamında ortam değişkenlerini ayarlayarak uygulamanın test veya üretim modunda çalışmasını sağlamak için idealdir.
Ortama Özel Konfigürasyon Dosyaları: Bazı çerçeveler (frameworks) veya uygulamalar, ortama özel yapılandırma dosyaları kullanır. Örneğin, .NET Core uygulamalarında appsettings.json dosyasının yanı sıra appsettings.Development.json, appsettings.Production.json gibi dosyalar bulunabilir. Uygulama, ASPNETCORE_ENVIRONMENT değişkenine göre uygun dosyayı yükler. Benzer şekilde, Spring Boot uygulamalarında application.properties‘a ek olarak application-dev.properties, application-test.properties gibi dosyalar kullanılabilir.
Konfigürasyon Yönetim Araçları: Kubernetes gibi konteyner orkestrasyon sistemleri, ConfigMaps ve Secrets gibi yerleşik konfigürasyon yönetim mekanizmaları sunar. Bu araçlar, uygulama kodundan bağımsız olarak yapılandırmanın dağıtılmasını ve güncellenmesini kolaylaştırır.

CI ortamında, doğru yapılandırma ayarlarının uygulandığından emin olmak için, CI pipeline’ınızın (iş akışınızın) ilgili çevre değişkenlerini veya yapılandırma dosyalarını doğru bir şekilde ayarladığından emin olmanız gerekir. Bu, genellikle CI yapılandırma dosyasında (.gitlab-ci.yml, .github/workflows/*.yml) belirtilen adımlarla yapılır. Doğru yapılandırma stratejileriyle, uygulamanızın farklı ortamlarda tutarlı ve güvenilir bir şekilde çalışmasını sağlayabilir, böylece “benim makinemde çalışıyor” sorunlarının büyük bir kısmını ortadan kaldırabilirsiniz.

Test Stratejileri ve CI Entegrasyonu: Güvenilir Testler Yazmanın ve CI’ı Optimize Etmenin Yolları Nelerdir?

CI başarısızlıklarının önemli bir kısmı, kodun kendisinden değil, testlerin yazılma şeklinden veya CI pipeline’ının (iş akışının) optimizasyon eksikliğinden kaynaklanabilir. Kırılgan (flaky) testler, CI süreçlerini yavaşlatır, geliştiricilerin güvenini sarsar ve hataların gözden kaçmasına neden olabilir. Bu bölümde, güvenilir testler yazma stratejilerini ve CI entegrasyonunu optimize etmenin yollarını ele alacağız.

Kırılgan (Flaky) Testleri Tespit Etme ve Düzeltme: Test Süitlerimizi Nasıl Güçlendiririz?

Kırılgan testler, bazen geçen, bazen de rastgele bir şekilde başarısız olan testlerdir; üstelik kodda herhangi bir değişiklik yapılmadığı halde. Bu durum, geliştiriciler için büyük bir hayal kırıklığı kaynağıdır çünkü testin başarısız olup olmadığını anlamak zordur ve genellikle “tekrar dene” yaklaşımına yol açar. Kırılgan testlerin temel nedenleri genellikle zamanlama sorunları, dış bağımlılıklar, paylaşılan durum (shared state) veya ortam tutarsızlıklarıdır.

Tespit Etme: Kırılgan testleri tespit etmek için CI sistemlerinin test raporlama özelliklerini kullanın. Tekrar eden başarısızlıkları izleyin ve belirli bir testin başarısızlık oranını analiz edin. Bazı CI araçları, test geçmişini analiz ederek kırılgan testleri otomatik olarak işaretleyebilir. Testleri birden fazla kez çalıştırmak da kırılganlıkları ortaya çıkarabilir.
Analiz Etme: Bir testin neden kırılgan olduğunu anlamak için, başarısız olduğu CI çalıştırmalarının loglarını dikkatlice inceleyin. Hata mesajlarını, yığın izlerini (stack traces) ve testin başarısız olduğu anki ortamın durumunu analiz edin. Testin bir dış hizmete (veritabanı, API) bağımlı olup olmadığını, asenkron işlemler içerip içermediğini veya paylaşılan bir kaynağı kullanıp kullanmadığını belirleyin.
Düzeltme Stratejileri:
- Test İzolasyonu: Her testin birbirinden tamamen bağımsız olduğundan emin olun. Testler arasında veri veya durum paylaşımını engelleyin. Her testten önce veritabanını temizleyin veya yeni bir test verisi kümesi oluşturun.
- Harici Bağımlılıkları Taklit Etme (Mocking/Stubbing): Testlerinizin dış hizmetlere (veritabanı, ağ API’leri, dosya sistemi) bağımlılığını azaltın. Bu hizmetleri taklit eden (mock) veya sahte (stub) nesneler kullanarak testlerinizi daha hızlı ve deterministik hale getirin.
- Dinamik Beklemeler: Asenkron işlemlerin tamamlanmasını beklerken sabit zaman gecikmeleri yerine, belirli bir koşulun gerçekleştiğini doğrulayan dinamik beklemeler kullanın. Örneğin, bir elemanın sayfada görünmesini veya bir API çağrısının yanıt vermesini bekleyin.
- Tekrar Deneme Mekanizması (Retries): Bazı CI sistemleri, testlerin başarısız olması durumunda otomatik yeniden deneme seçenekleri sunar. Bu, geçici ağ sorunları gibi kısa süreli sorunları maskelemek için kullanışlı olabilir, ancak temel kırılganlık sorununu çözmez. Daha ziyade, ana nedeni bulana kadar bir geçici çözüm olarak düşünülmelidir.

Güvenilir bir test süiti, CI sürecinin temelidir. Kırılgan testleri aktif olarak tespit edip düzelterek, geliştiricilerin CI sonuçlarına olan güvenini artırabilir ve daha hızlı, daha güvenilir bir yayın süreci sağlayabilirsiniz.

CI Pipeline Optimizasyonu: Daha Hızlı ve Daha Güvenilir Derlemeler İçin İpuçları

CI pipeline’ı sadece testleri çalıştırmakla kalmaz, aynı zamanda kodun derlenmesi, bağımlılıkların yüklenmesi ve diğer otomasyon adımlarını da içerir. Bu adımların optimize edilmesi, hem CI sürecinin hızını artırır hem de kaynak kısıtlamalarından kaynaklanan başarısızlıkları azaltır.

Paralel Test Yürütme: Test süitiniz büyüdükçe, testlerin ardışık olarak çalıştırılması çok zaman alabilir. CI sistemlerinin çoğu, testleri birden fazla runner’da veya aynı runner içinde paralel olarak çalıştırma yeteneği sunar. Bu, özellikle bağımsız testler için büyük bir hız artışı sağlar.
Akıllı Önbellekleme (Caching) Stratejileri: Bağımlılıkların her CI çalıştırmasında yeniden indirilmesi ve derlenmesi zaman ve kaynak israfına neden olur. CI sistemlerinin önbellekleme özelliklerini kullanarak, bağımlılıkları veya derleme çıktılarını bir sonraki çalıştırma için saklayabilirsiniz. Örneğin, node_modules dizinini veya Maven/Gradle bağımlılıklarını önbelleğe almak, derleme sürelerini önemli ölçüde kısaltabilir. Ancak, önbelleğin doğru bir şekilde geçersiz kılındığından (invalidate) ve güncel tutulduğundan emin olmak önemlidir.
Küçük ve Odaklanmış CI İşleri: Monolitik bir CI pipeline’ı yerine, farklı adımları (derleme, birim testleri, entegrasyon testleri, dağıtım) ayrı ayrı işlere bölmek daha iyi olabilir. Bu, başarısızlık durumunda sorunu daha hızlı izole etmenizi sağlar ve sadece ilgili adımları yeniden çalıştırmanıza olanak tanır.
Derleme Ortamını Optimize Etme: CI runner’ınızın ihtiyaç duymadığı yazılımları veya servisleri çalıştırmadığından emin olun. Docker konteynerleri kullanıyorsanız, daha küçük ve özel olarak hazırlanmış Docker imajları kullanmak, derleme ortamının daha hafif ve hızlı olmasını sağlar.
Log Analizi ve Hata Ayıklama: CI başarısızlıklarını gidermenin en etkili yollarından biri, CI loglarını dikkatlice incelemektir. Hata mesajlarını okuyun, yığın izlerini takip edin ve başarısızlığın tam olarak nerede ve neden meydana geldiğini anlamaya çalışın. Gerekirse, CI pipeline’ınıza ek hata ayıklama çıktıları ekleyerek daha fazla bilgi toplayın.

CI pipeline’ınızı sürekli olarak gözden geçirmek ve optimize etmek, geliştirme sürecinizin daha verimli ve sorunsuz olmasını sağlayacaktır. Unutmayın, CI sadece bir araç değil, aynı zamanda yazılım kalitesini ve geliştirici deneyimini artıran bir kültürün parçasıdır.

Sıkça Sorulan Sorular (SSS)

CI ortamında karşılaşılan sorunlar hakkında geliştiricilerin kafasındaki bazı temel soruları ve cevaplarını aşağıda bulabilirsiniz:

Soru 1: “Benim makinemde çalışıyor” sorununu en hızlı nasıl tespit edebilirim?

Cevap: En hızlı tespit yöntemi, CI loglarını çok dikkatli bir şekilde incelemektir. Hata mesajları, yığın izleri ve başarısız olan adımın çıktısı size sorunun kökeni hakkında değerli ipuçları verecektir. Ayrıca, yerel ortamınızı CI ortamına mümkün olduğunca benzetmek (örneğin, Docker kullanarak veya aynı yazılım sürümlerini yükleyerek) ve CI’da başarısız olan testi veya komutu yerelde CI’daki gibi çalıştırmaya çalışmak da sorunu yeniden üretmenize yardımcı olabilir.

Soru 2: Her zaman Docker kullanmalı mıyım?

Cevap: Docker, ortam tutarlılığı sağlamak için mükemmel bir araçtır ve birçok durumda şiddetle tavsiye edilir. Özellikle karmaşık bağımlılıkları, farklı işletim sistemi ihtiyaçları olan veya birden fazla programlama dili/runtime kullanan projelerde çok faydalıdır. Ancak, her proje için zorunlu değildir. Basit projelerde veya tek bir dil/runtime kullanan uygulamalarda, iyi yönetilmiş bir CI yapılandırması ve kilit dosyaları da yeterli olabilir. Yine de, uzun vadede sürdürülebilirlik ve tutarlılık için Docker’ı değerlendirmek her zaman iyi bir fikirdir.

Soru 3: Bağımlılık kilit dosyaları neden bu kadar önemli?

Cevap: Kilit dosyaları (package-lock.json, yarn.lock, Pipfile.lock vb.), projenizin tam olarak hangi bağımlılık sürümleriyle çalıştığını kesin olarak belirtir. Bu, farklı geliştiricilerin ve CI ortamlarının aynı bağımlılık kümesini kullanmasını garanti eder. Kilit dosyaları olmadan, paket yöneticisi bildirim dosyasındaki sürüm aralıklarına göre en güncel uygun sürümleri indirebilir; bu da farklı zamanlarda veya farklı ortamlarda farklı bağımlılık sürümlerinin yüklenmesine ve uyumluluk sorunlarına yol açabilir. Bu nedenle, kilit dosyaları “farklı sürümler” kaynaklı hataları önlemek için hayati öneme sahiptir.

Soru 4: CI’da testler neden yereldekinden daha yavaş çalışıyor?

Cevap: CI ortamları genellikle paylaşımlı veya daha kısıtlı CPU, bellek ve disk kaynaklarına sahip olabilir. Ağ gecikmeleri (bağımlılık indirme sırasında), disk G/Ç hızları ve genel sistem yükü gibi faktörler test sürelerini etkileyebilir. Ayrıca, CI ortamında önbellekleme stratejileri doğru uygulanmamışsa, her çalıştırmada bağımlılıkların yeniden indirilmesi veya derlenmesi de yavaşlığa neden olabilir. Bu durumu optimize etmek için paralel test yürütme, akıllı önbellekleme ve daha güçlü CI runner’ları kullanmayı düşünebilirsiniz.

Soru 5: Kırılgan (flaky) testleri nasıl önleyebilirim?

Cevap: Kırılgan testleri önlemenin temel yolu, testleri birbirinden bağımsız, deterministik ve izole hale getirmektir. Harici bağımlılıkları taklit edin (mock/stub), zamanlama bağımlılıklarını ortadan kaldırın (sabit gecikmeler yerine dinamik beklemeler kullanın) ve her test çalıştırması için test verilerini sıfırlayın. Ayrıca, testlerinizi küçük ve odaklanmış tutmak, sorunları daha hızlı tespit etmenize yardımcı olacaktır.

Sonuç: CI Başarısızlıklarını Önlemek İçin İpuçları ve En İyi Uygulamalar

“Benim makinemde çalışıyordu!” cümlesi, yazılım geliştirme dünyasında sıklıkla duyulan, ancak çoğu zaman derinlemesine incelenmesi gereken bir sorunun işaretidir. Gördüğümüz gibi, CI ortamında yaşanan başarısızlıkların çoğu, kodun kendisinden ziyade, ortam farklılıkları, bağımlılık yönetimi eksiklikleri, kaynak kısıtlamaları veya yapılandırma hatalarından kaynaklanmaktadır. Bu sorunları anlamak ve proaktif çözümler geliştirmek, hem geliştirici verimliliğini artırır hem de yazılım kalitesini yükseltir.

Bu makale boyunca ele aldığımız temel stratejileri özetleyecek olursak:

Ortam Tutarlılığına Odaklanın: Yerel geliştirme ortamınızı CI ortamınıza mümkün olduğunca benzetin. Docker gibi konteyner teknolojileri, bu tutarlılığı sağlamak için en güçlü araçlardan biridir.
Bağımlılık Yönetimini Ciddiye Alın: Paket kilit dosyalarını (package-lock.json, Pipfile.lock vb.) sürüm kontrol sistemine dahil edin ve CI’da bağımlılıkların bu kilit dosyalarına göre yüklenmesini sağlayın. Bu, bağımlılık sürümleriyle ilgili sürprizleri ortadan kaldırır.
Kaynak Kısıtlamalarını Göz Önünde Bulundurun: CI runner’larınızın kaynaklarını (CPU, RAM, disk) uygulamanızın ve testlerinizin ihtiyaçlarını karşıladığından emin olun. Zaman aşımı hatalarını ve bellek dışı sorunları analiz edin ve gerekirse CI planınızı yükseltin.
Sağlam ve Güvenilir Testler Yazın: Kırılgan (flaky) testlerden kaçının. Testlerinizi izole edin, harici bağımlılıkları taklit edin ve deterministik sonuçlar verecek şekilde tasarlayın. Zamanlama sorunlarını gidermek için dinamik beklemeler kullanın.
Yapılandırmayı Akıllıca Yönetin: Ortama özel yapılandırma ayarlarını ve hassas bilgileri (secrets) CI sisteminizin güvenli yönetim mekanizmalarını kullanarak yönetin. Kod tabanında hassas bilgi saklamaktan kaçının.
CI Pipeline’ınızı Optimize Edin: Paralel test yürütme, akıllı önbellekleme ve küçük, odaklanmış CI işleri kullanarak pipeline’ınızı hızlandırın ve daha verimli hale getirin.
Logları Okumayı Alışkanlık Haline Getirin: CI logları, başarısızlıkların nedenini anlamak için en değerli kaynaktır. Hata mesajlarını ve yığın izlerini dikkatlice inceleyin.

Sürekli Entegrasyon, modern yazılım geliştirmenin vazgeçilmez bir parçasıdır. CI başarısızlıkları can sıkıcı olsa da, genellikle sisteminizde iyileştirme potansiyeli olan alanları işaret eder. Bu sorunları çözmek için harcanan zaman ve çaba, uzun vadede daha hızlı, daha güvenilir ve daha keyifli bir geliştirme süreciyle karşılığını fazlasıyla verecektir. Unutmayın, iyi bir CI/CD kültürü, sadece kodun değil, tüm geliştirme ekibinin başarısının anahtarıdır.

#YazılımGeliştirme #CIDevOps #SürekliEntegrasyon #TestOtomasyonu #GeliştiriciAraçları #TeknikMakale

Örnek kod: github.com/fatihsoysalcom/ci-local-environment-variable-mismatch