CI/CD Nedir? Sürekli Entegrasyon ve Teslimat Rehberi

CI-CD nedir?

CI/CD, yazılım değişikliklerinin otomatik olarak derlenip test edilmesini (sürekli entegrasyon) ve test geçen sürümün canlıya hazırlanmasını ya da çıkarılmasını (sürekli teslimat veya sürekli dağıtım) sağlayan çalışma yöntemidir. Yani her kod değişikliğini küçük, sık ve güvenilir bir akışla kullanıcıya ulaştırmayı hedefler.

CI-CD nedir sorusunu bir benzetmeyle anlatalım: Bir fabrikadaki kalite kontrol hattını düşünün. Ham parçalar (kod değişiklikleri) banda girer, her istasyon (derleme, test, güvenlik taraması) parçayı ölçer ve kusurlu olanı geri çevirir. Sağlam çıkan parçaları ekip paketleyip sevkiyata hazırlar. Banda kimse elle müdahale etmez, kurallar herkes için aynıdır.

Bu yazıda konuyu kavramdan başlayıp pratiğe kadar götürüyoruz. Hem yeni başlayanlar hem de kendi ekibinde hat kurmak isteyen geliştiriciler için yazdık. Ayrıca her aşamada, sizin projenize uyarlayabileceğiniz küçük örnekler ve kontrol listeleri bulacaksınız.

Bazı kaynaklarda CI-CD diye de yazılan bu kısaltma, aslında iki ayrı soruyu tek akışta cevaplar. CI kısmı kodun sağlam olup olmadığını sorar. CD kısmı ise o sağlam kodun kullanıcıya nasıl ulaşacağını. Üstelik terim bir ürün adı değil, bir çalışma yöntemidir; hangi aracı kullanırsanız kullanın aynı fikir geçerlidir. Peki CI-CD nedir sorusunu soran biri gerçekte ne öğrenmek ister? Çoğu zaman şunu: "Yayın günü stresini nasıl azaltırım?"

CI-CD nedir sorusunun ilk yarısı: sürekli entegrasyon nasıl çalışır?

Sürekli entegrasyon (continuous integration, CI), ekipteki herkesin değişikliklerini ortak koda sık sık birleştirmesi ve her birleştirmenin otomatik olarak derlenip test edilmesi pratiğidir. Martin Fowler'ın bu konudaki klasik makalesi de aynı fikri vurgular: Entegrasyon sorunlarını haftalar sonra değil, oluştuğu anda yakalamak gerekir.

Mantık basit. Bir geliştirici değişikliğini sürüm kontrol sistemine gönderdiğinde, bir sunucu bu değişikliği temiz bir ortamda alır, derler ve testleri çalıştırır. Sonuç birkaç dakika içinde yeşil ya da kırmızı olarak döner. Kırmızıysa, hata henüz taze olduğu için düzeltmesi ucuzdur.

Temiz ortam kullanmak burada kritik bir ayrıntıdır. Çünkü geliştiricinin kendi makinesinde yıllardır birikmiş ayarlar, kurulu araçlar ve unutulmuş dosyalar vardır. Hat ise her seferinde sıfırdan başlar. Böylece "bende çalışıyordu" cümlesi yerini nesnel bir sonuca bırakır: Temiz ortamda çalışmıyorsa, çalışmıyor demektir.

Sürüm kontrol tarafını bilmiyorsanız önce Git ve GitHub kullanım rehberimize göz atın. CI, o akışın hemen üzerine oturur.

CI'ın temel alışkanlıkları şunlardır:

• Değişiklikleri küçük tutarsınız ve ortak dala her gün birleştirirsiniz.
• Derleme ve test adımlarını bir komutla çalıştırılabilir hâle getirirsiniz.
• Kırık derlemeyi ekibin önceliği sayar, hemen düzeltirsiniz.
• Hızlı testleri öne, yavaş testleri sona koyarsınız.

Hızlı geri bildirim, CI'ın en değerli çıktısıdır. Bir test beş dakikada sonuç veriyorsa geliştirici bekler ve hatayı düzeltir. Sonuç saatler sürüyorsa başka işe geçer ve hatayı unutur. Bu nedenle ekipler testleri doğruluk kadar hız açısından da düzenler.

Dallanma stratejisi sürekli entegrasyonu nasıl etkiler?

Sürekli entegrasyonun özü sık birleştirmedir, bu yüzden uzun ömürlü dallar en büyük engeldir. Bir dal haftalarca ana koddan ayrı yaşarsa, birleştirme günü büyük bir çatışmaya dönüşür. Martin Fowler'ın makalesi de tam bu nedenle ana dala sık ve küçük birleştirmeyi önerir.

Pratikte iki yaygın model görürsünüz. Birincisinde geliştirici kısa ömürlü bir dal açar, küçük değişikliği yapar ve birleştirme isteğiyle ana dala getirir. İkincisinde ekip, doğrudan ana dala çok küçük adımlar gönderir; buna gövde tabanlı geliştirme denir.

İki modelde de ortak kural şudur: Ana dal her zaman yeşil kalmalıdır. Bunun için ana dalı korumaya alır, birleştirmeden önce hattın başarılı olmasını zorunlu kılarsınız. Yarım kalmış bir özelliği ana dalda saklamanız gerekirse, kodu bir bayrakla kapalı tutmak dalı haftalarca açık bırakmaktan çok daha güvenlidir.

Sürekli teslimat ile sürekli dağıtım arasındaki fark nedir?

CD kısaltması iki farklı kavramı karşılar ve karışıklığın çoğu buradan çıkar. Sürekli teslimat (continuous delivery), testleri geçen her sürümün her an canlıya çıkarılabilir durumda tutulması demektir. Son adımı, yani canlıya çıkış kararını, bir insan verir.

Sürekli dağıtım (continuous deployment) ise bir adım ileri gider: Tüm otomatik kontrolleri geçen değişiklik, onay beklemeden doğrudan canlıya çıkar. Arada insan onayı yoktur.

Pratikte fark şudur: Teslimatta "hazır" olan sürümü ne zaman yayınlayacağınıza siz karar verirsiniz. Dağıtımda karar, kurduğunuz testlerin ve kontrollerin kalitesine devredilmiştir. Bu nedenle sürekli dağıtıma geçmek için güçlü bir test güvencesi ve hızlı geri alma yolu gerekir.

Martin Fowler'ın sürekli teslimat tanımı da bu ayrımı destekler: Önemli olan, yazılımın her an güvenle yayınlanabilir olmasıdır. Yayınlama sıklığı bir iş kararıdır.

Bir örnekle pekiştirelim. Bir haber sitesinde küçük bir içerik düzeltmesi, otomatik kontrolleri geçince dakikalar içinde yayına girebilir; bu dağıtım modeline uyar. Ödeme akışına dokunan bir değişikliği ise ekip, son bir elle kontrolün ardından yayınlamak isteyebilir; bu da teslimat modelidir. Yani iki model aynı ekipte, farklı hatlarda yan yana yaşayabilir.

Tipik bir CI/CD boru hattı hangi aşamalardan oluşur?

Boru hattı (pipeline), bir değişikliğin koddan canlıya kadar geçtiği otomatik aşamaların sıralı listesidir. Her aşama bir öncekinin başarısına bağlıdır; biri kırılırsa hat durur ve sonraki aşamalar çalışmaz.

Çoğu projede şu aşamaları görürsünüz:

1. Kaynak: Geliştirici bir değişiklik gönderir ya da birleştirme isteği açar, bu da hattı tetikler.
2. Derleme: Hat kodu derler, bağımlılıkları indirir ve çalıştırılabilir bir çıktı üretir.
3. Test: Birim testleri, entegrasyon testleri ve gerekirse uçtan uca testler çalışır.
4. Güvenlik ve kalite taraması: Araçlar bağımlılık açıklarını, kod kalitesini ve gizli anahtar sızıntılarını denetler.
5. Paketleme: Çıktı, tek bir sürüm numarasıyla taşınabilir pakete ya da konteyner imajına dönüşür.
6. Dağıtım: Paket önce test ortamına, onaydan sonra canlıya yerleşir.
7. Doğrulama ve izleme: Canlıya çıkışın ardından sağlık kontrolleri ve izleme devreye girer.

Bu sıra sabit bir kural değildir. Küçük bir web sitesinde yalnızca derleme, test ve dağıtım olabilir. Büyük bir üründe ise ekip her aşamayı kendi alt adımlarına böler.

Hattın tamamı, kaynak depoya bağlı bir yapılandırma olarak tanımlanır; böylece hat da kod gibi gözden geçirilir. Önemli bir ilke de "hızlı hata" (fail fast) fikridir. Yani en ucuz kontroller başta, pahalı olanlar sonda çalışır. Böylece bir hata varsa, hat boşuna zaman harcamadan durur.

Bir değişiklik boru hattında nasıl ilerler? Örnek senaryo

Somutlaştıralım. Bir e-ticaret ekibinde geliştirici, sepet sayfasındaki indirim hesabını düzeltir. Değişikliği ayrı bir dalda yapar ve birleştirme isteği açar. Bu an hattı tetikler.

Hat önce kodu derler. Ardından birim testleri çalışır ve bir test, indirimin yüzde hesabında beklenmeyen bir yuvarlama farkı bulur. Hat kırmızıya döner ve birleştirmeyi durdurur. Geliştirici hatayı aynı gün içinde düzeltir ve hat yeşile döner.

Birleştirmeden sonra hat paketi üretir ve test ortamına yerleştirir. Orada otomatik uçtan uca testler sepet akışını dener. Bunlar da geçerse sürüm, teslimat modelinde onay bekler; dağıtım modelinde ise kendiliğinden canlıya çıkar. Bu bir örnek senaryodur, gerçek bir müşteri vakası değildir.

Dikkat edin: Ekip hatayı müşteriye ulaşmadan, üstelik düzeltmesi en ucuz anda yakaladı. CI/CD'nin asıl değeri budur.

Aynı senaryoda hat olmasaydı ne olurdu? Büyük olasılıkla hata birleştirmeden günler sonra canlıda fark edilir, müşteri şikayet eder ve ekip hangi değişikliğin sorumlu olduğunu bulmak için zaman harcardı. CI, bu zinciri en başta keser.

Test piramidi boru hattında hangi testleri hangi sırayla çalıştırır?

Test piramidi, çok sayıda hızlı testi tabana, az sayıda yavaş testi tepeye koyan bir düşünme biçimidir. Hat bu mantığı izler: Önce en hızlı ve en ucuz kontroller çalışır. Çünkü hata orada yakalanırsa, pahalı testleri başlatmaya gerek kalmaz.

• Statik kontroller: Biçim, tür ve basit kalite kuralları saniyeler içinde biter ve en başa girer.
• Birim testleri: Tek bir fonksiyonu ya da sınıfı, dış bağımlılık olmadan dener.
• Entegrasyon testleri: Birkaç parçanın veritabanı gibi gerçek bileşenlerle birlikte çalışmasını dener.
• Uçtan uca testler: Kullanıcının yaptığı akışı baştan sona dener, ama daha yavaş ve daha kırılgandır.

Örneğin bir sipariş formunda, tutar hesabını birim testleriyle yüzlerce kez denemek ucuzdur. Buna karşılık formun tarayıcıda baştan sona çalışmasını yalnızca birkaç kritik senaryoyla denersiniz. Böylece hat hem hızlı kalır hem de en önemli akışları korur.

Yavaş testleri paralel çalıştırmak da süreyi kısaltır. Ancak paralel çalışmak için testlerin birbirinden bağımsız olması gerekir.

Ortamlar (geliştirme, test, canlı) boru hattında nasıl yer alır?

Ortam, yazılımın çalıştığı ayrı bir kurulumdur. Boru hattı çoğu zaman en az üç ortamı kullanır: geliştirme, test (ya da hazırlık) ve canlı. Her biri farklı bir soruya cevap verir.

• Geliştirme ortamı: Geliştiricinin kendi makinesi ya da paylaşılan deneme alanıdır. Burada hız önemlidir, veri gerçek değildir.
• Test ortamı: Canlıya olabildiğince benzeyen bir kopyadır. Ekip otomatik ve elle doğrulamayı burada yapar.
• Canlı ortam: Gerçek kullanıcıların kullandığı sistemdir. Buraya yalnızca hattın doğruladığı paket çıkar.

Altın kural, aynı paketin ortamlar arasında değişmeden ilerlemesidir. Test ortamında denediğiniz paketi canlıda yeniden derlerseniz, test ettiğinizden farklı bir şey yayınlamış olabilirsiniz. Ortama özgü ayarları paketin içine değil, dışarıdan verilen yapılandırmaya koyarsınız.

Gizli anahtarları ve şifreleri ise kodun içinde değil, CI/CD aracının gizli değişken alanında saklarsınız.

Test ortamının canlıya ne kadar benzediği, yakaladığınız hataların kalitesini belirler. Veritabanı sürümü, işletim sistemi ya da ağ ayarları farklıysa test geçer, ama canlıda hata çıkar. Konteyner kullanmak bu farkı azaltmanın yaygın yoludur.

CI-CD nedir ve manuel yayından hangi noktalarda ayrışır?

Farkı görmek için üç yaklaşımı yan yana koyalım. Tablo, bir ekibin hangi noktada olduğunu anlamanıza yardım eder.

Tablodan çıkan sonuç net: CI, CD'nin ön koşuludur. Testi olmayan bir kodu otomatik yayına bağlamak, hatayı hızlandırmaktan başka işe yaramaz.

Bu tabloyu bir merdiven gibi okuyun. Her basamak bir öncekini temel alır ve ekibin hepsini aynı anda atlaması gerekmez. Birçok ekip uzun süre CI aşamasında kalır; bu da gayet sağlıklı bir durumdur.

CI/CD kullanmak ekibe neler kazandırır?

Kazanç tek bir şey değil; birbirini besleyen birkaç etki var. Bunları somut tutalım, ama rakam vermiyoruz, çünkü kazanç ekipten ekibe değişir.

İlk olarak geri bildirim kısalır. Geliştirici hatayı, yazdığı kodu hâlâ hatırlarken görür. İkinci olarak yayın korkusu azalır. Küçük ve sık yayınlar, büyük ve nadir yayınlardan çok daha az risk taşır; sorun çıkarsa suçlu aramak yerine tek değişikliğe bakarsınız.

Üçüncü kazanç, tekrarlanabilirliktir. Yayın adımları bir yazıya, yani hat tanımına dönüştüğü için "bende çalışıyordu" sorunu azalır. Yeni katılan biri de yayını ilk gününde güvenle çalıştırabilir.

Dördüncü olarak bilgi ekibe yayılır. Yayın süreci tek bir kişinin kafasında kalmaz. Bir kişi izne çıktığında ya da işten ayrıldığında yayın yapılamaz hâle gelmez.

DORA araştırma programı, yazılım teslim performansını yayın sıklığı, değişiklik başarısızlık oranı gibi ölçütlerle izlemeyi önerir. Bu ölçütlerin güncel tanımlarını DORA'nın resmi sitesinden kontrol edebilirsiniz.

Müşteri tarafında da fark görünür. Hata düzeltmeleri günler yerine saatler içinde yayına girer, böylece kullanıcı sorunla daha az karşılaşır. Pazarlama ekipleri için de değerlidir: Kampanya sayfasındaki bir düzeltme, planlı yayın gününü beklemeden canlıya çıkabilir.

CI/CD başarısını hangi ölçütlerle izlersiniz?

Hattı kurmak yalnızca başlangıçtır; iyileştiğini görmek için ölçmeniz gerekir. DORA araştırma programı, yazılım teslim performansını yayın sıklığı, bir değişikliğin canlıya çıkma süresi, değişikliklerin ne kadarının soruna yol açtığı ve hizmetin ne kadar sürede toparlandığı gibi ölçütlerle izlemeyi önerir. Güncel tanımları DORA'nın resmi sayfasından okuyabilirsiniz.

Bu ölçütleri kişileri sıralamak için değil, sistemi iyileştirmek için kullanın. Birini baskıyla yükseltmeye çalışırsanız, ekip ölçütü kandırmanın yollarını bulur.

Kendi ekibiniz için daha basit göstergeler de işe yarar:

• Hattın ortalama süresi ve zamanla nasıl değiştiği.
• Hattın kırmızıya döndüğü birleştirme isteklerinin oranı.
• Aynı kodda bazen geçen bazen kalan, yani kararsız testlerin sayısı.
• Hata yakalandığı andan düzeltildiği ana kadar geçen süre.

Bu yazıda hedef rakam vermiyoruz, çünkü iyi değer ekipten ekibe değişir. Önemli olan, kendi çizgisinizin yukarı mı aşağı mı gittiğini görmektir.

Geri alma ve kademeli yayın CI/CD içinde nasıl çalışır?

Otomatik yayın, otomatik geri alma yolu olmadan yarım iştir. Geri alma (rollback), canlıda sorun çıktığında bir önceki sağlam sürüme hızlıca dönmektir. Paketleri sürüm numarasıyla sakladığınız için bu, çoğu zaman eski paketi yeniden yerleştirmekten ibarettir.

Kademeli yayın ise riski dağıtır. Yeni sürümü önce küçük bir kullanıcı dilimine açarsınız, izleme temiz kalırsa genişletirsiniz. Böylece hata olsa bile herkesi değil, küçük bir grubu etkiler.

Burada devreye özellik bayrakları girer. Kodu canlıya gönderirsiniz, ama özelliği bir bayrakla kapalı tutarsınız; açma kararı yayından bağımsız olur. Feature flag nedir yazımızda bu yaklaşımı ayrıntılı anlattık. Burada tekrar etmeyeceğiz.

Veritabanı değişiklikleri ayrı bir dikkat ister. Şema değişikliğini geriye dönük uyumlu adımlara bölmezseniz, kod geri alınsa bile veri geri alınamaz.

Canlı izleme olmadan kademeli yayının anlamı kalmaz. Hata oranı, yanıt süresi ve kullanıcı geri bildirimi gibi sinyalleri izlemelisiniz. Sinyaller bozulursa geri alma kararını kimin ve hangi eşikte vereceğini önceden yazın; çünkü sorun anında tartışmak zaman kaybettirir.

CI/CD yalnızca web siteleri için mi geçerlidir?

Hayır, mantık her yazılım türünde işler. Mobil uygulama, masaüstü programı, kütüphane, altyapı tanımı ve hatta dokümantasyon sitesi bile aynı akışı kullanabilir: değişiklik gelir, otomatik doğrulanır, paketlenir ve dağıtılır.

Yalnızca son adım değişir. Bir web sitesinde dağıtım, sunucuya yeni sürümü yerleştirmektir. Mobil uygulamada son adım çoğunlukla mağaza inceleme sürecine bağlıdır, dolayısıyla ekipler genellikle sürekli teslimat noktasında durur.

Kurumsal bir web sitesi ya da vitrin için de değer vardır. Örneğin içerik değiştiğinde siteyi otomatik derleyip yayınlayan bir hat, elle dosya kopyalama hatalarını ortadan kaldırır. Böylece siteyi yayınlayan kişi değişse bile süreç aynı kalır.

Boru hattına güvenlik taramasını nasıl eklersiniz?

Güvenlik, hattın sonunda yaptığınız tek bir kontrol değil, her aşamaya yayılan bir alışkanlık olmalıdır. Buna sık sık "sola kaydırma" denir: Sorunları ne kadar erken yakalarsanız, düzeltmesi o kadar ucuz olur.

Tipik taramalar şunlardır:

• Bağımlılık taraması: Kullandığınız kütüphanelerde bilinen açık olup olmadığına bakar.
• Gizli anahtar taraması: Şifrenin ya da erişim anahtarının yanlışlıkla koda girmesini yakalar.
• Statik kod analizi: Kodu çalıştırmadan riskli kalıpları arar.
• İmaj taraması: Konteyner imajındaki eski ya da açık paketleri bulur.

Hangi risklere bakacağınızı seçmek için OWASP Top 10 rehberimiz iyi bir başlangıçtır. Konteyner tarafı için ise Docker nedir yazımıza bakabilirsiniz.

Bir uyarı: Tarama araçları kusursuz değildir. Çıkan her bulguyu körü körüne engel saymak yerine, öncelik belirleyip kritik olanları hattı durduracak şekilde bağlarsınız.

Hattın kendisi de bir saldırı hedefidir. Çünkü canlıya çıkış yetkisi ve gizli anahtarlar hatta toplanır. Bu yüzden hat erişimini en az yetki ilkesiyle verir, üçüncü taraf eklentileri dikkatle seçer ve hat tanımındaki değişiklikleri de gözden geçirirsiniz.

Hangi CI/CD araç türleri vardır?

CI-CD nedir sorusunun araç tarafı, çoğu okur için en karışık kısımdır. Araçları iki ana gruba ayırabilirsiniz. Birincisi barındırılan servislerdir: Altyapıyı sağlayıcı işletir, siz yalnızca hat tanımını yazarsınız. İkincisi kendi sunucunuzda çalıştırdığınız araçlardır: Kurulum, güncelleme ve yedekleme sizin sorumluluğunuzdadır.

Bazı projeler karma yol seçer. Hattın büyük kısmı barındırılan serviste çalışır, hassas dağıtım adımları ise kendi sunucunuzdaki bir çalıştırıcıda yürür.

Resmî belgelerden örnek vermek gerekirse GitHub Actions ve GitLab CI/CD, bu iki dünyanın tanınmış temsilcileridir. İkisi de hattı depodaki bir yapılandırma dosyasıyla tarif etmenize izin verir. Bu bir tavsiye değil, belgesi okunabilir örneklerdir; ürün seçimi ekibinizin yığınına bağlıdır.

Seçerken şu sorulara bakın: Kodunuz zaten nerede duruyor? Gizlilik ya da uyum nedeniyle kodun dışarı çıkmaması gerekiyor mu? Hattın bakımıyla kim ilgilenecek? Bu üç sorunun cevabı, çoğu zaman aracın markasından daha belirleyicidir.

GitHub Actions ve GitLab CI gibi araçlar kavram olarak nasıl çalışır?

Araçlar farklı isimler kullansa da ortak bir model paylaşır. Önce bir olay (örneğin kod gönderimi ya da birleştirme isteği) hattı tetikler. Sonra tetiklenen iş, bir çalıştırıcıda (runner) temiz bir ortamda yürür. Çalıştırıcı, işi yapan geçici makinedir.

Hat tanımı, depoda bir yapılandırma dosyası olarak durur. Bu dosyada işleri, sıralarını, hangi koşulda çalışacaklarını ve ortam değişkenlerini yazarsınız. Hat tanımı kodla birlikte sürüm kontrolüne girdiği için, ekip hattın kendisini de inceleyebilir ve eski hâline döndürebilir.

İşlerin ürettiği çıktıları (derleme paketi, test raporu) araç artefakt olarak saklar ve sonraki aşamalara aktarır. Önbellek de benzer şekilde, bağımlılıkları her seferinde yeniden indirmemeniz için vardır.

Ayrıntılar için resmî kaynaklara bakın: GitHub Actions belgeleri ve GitLab CI/CD belgeleri. Menü adları ve söz dizimi zamanla değiştiği için güncel hâli oradan doğrulayın.

Bazı araçlar matris çalıştırmayı da destekler. Yani aynı testi farklı işletim sistemi ya da dil sürümü kombinasyonlarında paralel yürütür. Kütüphane yazanlar için bu çok değerlidir; tek ürün geliştirenler için ise çoğunlukla gereksizdir.

Küçük bir ekip CI/CD'ye nereden başlamalı?

Her şeyi bir anda kurmaya çalışmayın. Küçük adımlarla ilerlemek hem öğrenmeyi hem de güveni artırır. Aşağıdaki sıra, küçük ekiplerde işe yarayan bir yoldur.

1. Kodunuzu sürüm kontrol sisteminde tutun ve ortak bir ana dal belirleyin.
2. Derleme ve testi tek komutla çalıştırabildiğinizden emin olun.
3. İlk hattı yalnızca derleme ve test için kurun; her birleştirme isteğinde çalışsın.
4. Kırmızı hat varken birleştirmeyi engelleyin.
5. Paketi tek bir yerde üretin ve sürüm numarası verin.
6. Test ortamına otomatik dağıtım ekleyin.
7. Canlıya çıkışı önce onaylı (teslimat) olarak bağlayın, güven oluştukça otomatiğe geçmeyi düşünün.
8. Geri alma adımını yazın ve bir kez prova edin.

Test hiç yoksa önce birkaç kritik akışa test yazın: giriş, ödeme, form gönderimi gibi. Test yazma mesleğine dair daha geniş bilgi için test otomasyon mühendisi yazımıza göz atabilirsiniz.

İlk haftalarda amaç mükemmel bir hat değil, çalışan bir hattır. Ayrıca hattı ekip sohbeti gibi herkesin göreceği bir yere bildirim gönderecek şekilde bağlamak, kırmızı hattın fark edilmesini hızlandırır. Böylece kimse "hat kırık muydu?" diye sormak zorunda kalmaz.

CI/CD başlangıç kontrol listesinde neler olmalı?

CI-CD nedir sorusunu pratiğe çevirmek için hattı kurmadan önce ve kurduktan sonra bu listeyle kendinizi sınayın. Her madde evet ya da hayır cevabı verir.

• Her birleştirme isteğinde derleme ve test otomatik çalışıyor mu?
• Hat süresi, geliştiricilerin beklemeyi bırakmayacağı kadar kısa mı?
• Testleriniz kararlı mı, yoksa ara sıra sebepsiz mi kırılıyor?
• Gizli anahtarlar kodun dışında, araçların gizli alanında mı duruyor?
• Test ve canlı ortamda aynı paketi mi çalıştırıyorsunuz?
• Canlıya çıkışı kimler başlatabiliyor ve bu yetki kayıt altında mı?
• Geri alma yolunuz yazılı mı, hiç denediniz mi?
• Canlıya çıkıştan sonra izleme ve uyarı var mı?
• Hat tanımı sürüm kontrolünde ve gözden geçirmeye açık mı?

Cevabı "hayır" olan her madde, bir sonraki iyileştirme görevinizdir. Hepsini aynı hafta çözmek zorunda değilsiniz.

CI/CD'de en sık yapılan hatalar nelerdir?

CI-CD nedir öğrenmek kadar, nelerin ters gidebileceğini bilmek de önemlidir. Hatalar çoğunlukla araçtan değil, alışkanlıktan gelir. En sık görülenleri sıralayalım.

Birincisi, testsiz otomasyondur. Hat yeşil yanıyor ama hiçbir şeyi doğrulamıyorsa, bu yalnızca sahte bir güvendir. İkincisi, kararsız (flaky) testlerdir. Aynı kodda bazen geçen bazen kalan test, ekibi kırmızıyı görmezden gelmeye alıştırır.

Üçüncüsü, çok yavaş hatlardır. Hat yarım saat sürüyorsa geliştiriciler beklemek yerine başka işe geçer ve bağlam kaybeder. Hızlı testleri öne alın, ağır testleri paralel çalıştırın.

Dördüncüsü, canlıya özel elle yapılan ayarlardır. Sunucuda elle değiştirilen bir ayar, bir sonraki dağıtımda sessizce kaybolur. Her şeyi yapılandırma olarak tarif etmelisiniz.

Beşincisi, gizli anahtarların koda ya da günlüklere sızmasıdır. Hat çıktısının herkese açık olabileceğini unutmayın; şifre basan bir komut büyük bir risk yaratır.

Altıncı hata, hattı tek bir kişiye bağlamaktır. Hattı yalnızca bir kişi biliyorsa, o kişi izne çıktığında süreç durur. Bu yüzden bilgiyi ekibe yayın ve hat tanımını kısa bir belgeyle destekleyin.

CI/CD hangi durumlarda gereksiz ya da riskli olur?

CI/CD her projeye aynı derecede yarar sağlamaz. Dürüst olmak gerekirse, tek seferlik küçük bir sayfa için tam bir hat kurmak emeğe değmeyebilir. Yılda birkaç kez değişen, testi olmayan bir vitrin siteyi elle yayınlamak makul olabilir.

Riskin kendisi ise otomasyonun yanlış kurulmasından gelir. Güvenlik denetimi olmayan bir hat, hatalı ya da kötü niyetli bir değişikliği de hızla canlıya taşır. Bu yüzden canlıya çıkış yetkisini, birleştirme onayını ve gizli anahtar erişimini dikkatle sınırlayın.

Düzenlenmiş sektörlerde (örneğin kişisel veri işleyen sistemlerde) değişiklik kaydı ve onay izi gerekebilir. Bu durumda otomasyonu bırakmaz, onay adımlarını hatta ekleyerek kayıt altına alırsınız. Hukuki gereklilikler için hukuki danışmanlık almalısınız; bu yazı hukuki danışmanlık değildir.

CI/CD ile mikroservis, Docker ve JWT gibi terimleri nasıl ayırt edersiniz?

Yazılım dünyasında terimler iç içe geçtiği için karışıklık doğal. Aşağıdaki tablo, CI/CD'nin komşu kavramlarla farkını gösterir. Komşu konuların kendi yazıları var; burada yalnızca kısa bağlam veriyoruz.

Mikroservis mimarisi yazımızda bölünmüş uygulamaların neden daha fazla otomasyon gerektirdiğini anlattık. JWT nedir yazımız ise kimlik doğrulama tarafını ele alıyor; CI/CD ile doğrudan ilgisi, anahtarların hat içinde güvenle saklanmasından ibaret.

Kendi projeniz için CI/CD hattını nasıl kurarsınız?

Hat kurmak, bir araç seçmekten çok süreci tanımlamaktır. Önce ekibinizin bugünkü yayın şeklini yazın: kim, hangi adımlarla, ne sıklıkla yayınlıyor? Sonra en sancılı üç adımı otomatikleştirin.

Elinizde kod tabanı büyükse, her şeyi bir anda taşımayın. Önce bir servisi ya da bir modülü hatta bağlayın, öğrendiklerinizi diğerlerine yayın. Kısa bir pilot, büyük bir geçişten daha az risk taşır.

Talha Aslan ve ekibi olarak özel yazılım projelerinde yayın sürecini de tasarımın parçası sayıyoruz. Kendi ürününüz için bir yayın hattı planlıyorsanız, özel yazılım geliştirme hizmetimiz kapsamında ihtiyacınızı birlikte değerlendirebiliriz. Sitenizi yayına almadan önce yayın öncesi test sürecimiz de işinize yarar.

Pilotu seçerken sık değişen ama kritik olmayan bir bileşenle başlamak akıllıcadır. Hatayı orada yaşar, öğrenir ve kritik bileşenlere hazırlıklı gidersiniz. CI-CD nedir sorusunun pratik cevabı da zaten budur: küçük başlayan, öğrenen ve genişleyen bir süreç.

CI-CD nedir sorusunun özeti: akılda tutulacaklar neler?

Kısa özetle: CI/CD, kod değişikliklerini otomatik derleyip test eden ve güvenle yayına hazırlayan bir disiplindir. CI sorunları erken yakalar. Teslimat, yayına hazır olmayı garanti eder. Dağıtım ise son adımı da otomatiğe bağlar.

Başarının üç ayağı şunlardır: güvenilir testler, hızlı bir hat ve denenmiş bir geri alma yolu. Bunlardan biri eksikse otomasyon rahatlık değil, risk getirir.

Küçük başlayın, ölçün, sonra büyütün. Araç seçimi, hattın kalitesinden daha az önemlidir. Ve unutmayın: En iyi hat, ekibin güvenle ve sıkılmadan kullandığı hattır.

Son olarak soruya tek cümleyle dönersek: CI/CD, yazılımı sık, küçük ve güvenle teslim etmenin otomatik yoludur.