CI/CD Nedir? Sürekli Entegrasyon ve Teslimat Basitçe Açıklandı

CI/CD, her kod değişikliğinin otomatik olarak derlendiği, test edildiği ve — geçerse — yayına hazırlandığı ya da yayınlandığı bir yazılım yayınlama yöntemidir. CI (sürekli entegrasyon), değişikliklerin sık sık birleştirilmesi ve her seferinde otomatik testlerle kontrol edilmesi anlamına gelir. CD (sürekli teslimat ya da dağıtım) ise geçen değişikliklerin, manuel iş çok az olacak şekilde paketlenip kullanıcılara doğru yönlendirilmesi demektir.

Asıl amaç basittir: hataları haftalar sonra bir müşteri bulmadan, yapıldıkları dakikalar içinde yakalamak.

AI ile geliştirirken CI/CD neden önemli?

AI oluşturucular kod değişikliklerini çok hızlı yapar. Tek bir istem on dosyaya dokunabilir. Bu hız harika bir şeydir; ta ki ödeme sayfasındaki bir değişiklik sessizce giriş sayfasını bozana ve bir kullanıcı size e-posta yazana kadar.

CI/CD tam olarak bu durum için bir güvenlik ağıdır. Her değişikliğin iyi olduğuna güvenmek yerine, bir pipeline her seferinde aynı kontrolleri çalıştırır:

• Uygulama hatasız derlenmeye devam ediyor mu?
• Otomatik testler hâlâ geçiyor mu?
• Kod projenin kurallarına uyuyor mu (tipler, biçimlendirme, güvenlik kontrolleri)?

Herhangi bir kontrol başarısız olursa değişiklik kullanıcılara ulaşmadan durdurulur. Kod değişiklikleriniz ne kadar hızlıysa, asla yorulmayan ve hiçbir adımı atlamayan bir kontrol o kadar değerlidir.

Günlük hayattan bir benzetme

Her sabah ekmeği marketlere satan bir fırını düşünün.

• CI/CD olmadan, her fırıncı bir hafta boyunca kendi tarifinde küçük değişiklikler yapar, sonra cuma gecesi herkes bunları birleştirir ve ekmeğin hâlâ kabarıp kabarmayacağını umar. Kabarmadığında kimin değişikliğinin sorunlara yol açtığını kimse bilmez.
• CI ile, her küçük tarif değişikliği hemen bir deneme ekmeğine uygulanır ve kontrol edilir — tat, ağırlık, şekil. Hatalı bir değişiklik aynı gün yakalanır ve tam olarak hangisi olduğunu bilirsiniz.
• CD ile, kontrolden geçen ekmekler doğrudan dağıtım aracına gider; her seferinde aynı şekilde paketlenip etiketlenirler. Sabah 5'te birinin kutuları elle doldurmasına gerek kalmaz.

Kontrol fırıncıları daha iyi yapmaz. Hatalarını ucuz hale getirir.

Bir CI/CD pipeline'ı nasıl çalışır?

Bir pipeline, bir şey olduğunda — genellikle biri kodu GitHub gibi bir depoya gönderdiğinde — bir CI/CD hizmetinin otomatik olarak çalıştırdığı adımlar listesidir. Tipik bir pipeline şöyle görünür:

Her adım, birinin dizüstü bilgisayarında değil, temiz bir makinede çalışır; böylece "benim bilgisayarımda çalışıyordu" bahanesi ortadan kalkar. Bir adım başarısız olursa pipeline durur ve değişikliği yapan kişiye bildirir.

Adımlar, kodla birlikte duran bir yapılandırma dosyasında tanımlanır. Örneğin GitHub Actions'ta bu, deponun .github/workflows klasöründeki bir YAML dosyasıdır.

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

"CD" kısaltması belirsizdir ve insanlar onu iki şekilde de kullanır:

Sürekli dağıtım yalnızca testler iyiyse iyi çalışır. Testleriniz ödeme sürecini kapsamıyorsa, sürekli dağıtım bozuk bir ödeme sürecini de keyifle yayına alır.

Çalışan bir örnek: pipeline'lı bir rezervasyon uygulaması

Diyelim ki bir kuaför rezervasyon uygulamanız var ve kodu bir GitHub deposunda. Bir AI oluşturucuya "ilk kez gelen müşterilere %10 indirim ekle" diyorsunuz.

1. Değişiklik yeni bir dala gönderilir ve bir pull request açılır.
2. Pipeline başlar. Paketleri kurar ve uygulamayı derler — bu geçer.
3. Testleri çalıştırır. "geri dönen bir müşteri tam fiyat öder" testi başarısız olur: indirim herkese uygulanıyor.
4. Pull request'te kırmızı bir çarpı görünür. Değişiklik birleştirilemez.
5. AI'dan düzeltmesini istersiniz. Düzeltmeyi gönderir; pipeline yeniden çalışır ve her şey geçer.
6. Değişiklik birleştirilir. Pipeline bunu bir hazırlık ortamına dağıtır; orada bir deneme rezervasyonu yaparsınız.
7. Onaylarsınız ve üretime dağıtılır.

Pipeline olmasaydı, 3. adımdaki sorun müşterilerinizin cüzdanında ortaya çıkardı.

Temel terimler

Yaygın yanlış anlamalar

• "CI/CD uygulamamın test edildiği anlamına gelir." Bir pipeline yalnızca sahip olduğunuz testleri çalıştırır. Hiç test yoksa CI yalnızca uygulamanın derlendiğini kanıtlar — daha fazlasını değil. AI'dan en önemli akışlar için testler yazmasını isteyin.
• "CI/CD yalnızca büyük şirketler içindir." GitHub Actions gibi barındırılan araçların kurulumu kısa bir yapılandırma dosyası gerektirir ve küçük ekipler bunları sık kullanır. Çaba gerektiren şey araç değil, testlerdir.
• "Otomatik dağıtım, kimsenin hiçbir şeyi kontrol etmediği anlamına gelir." İyi pipeline'lar kontrol ekler, kaldırmaz. Birçok ekip üretimden önce bir insan onay adımını korur.
• "Pipeline yeşilse uygulama çalışıyordur." Bu, otomatik kontrollerin geçtiği anlamına gelir. Yine de değişikliği kendiniz deneyin, ideal olarak bir önizlemede ya da hazırlık ortamında.
• "CI/CD yedeklerin yerini alır." Almaz. Testleri geçen kötü bir veritabanı migrasyonu gerçek verilere yine zarar verebilir. Yedekleri ve geri alma yolunu saklayın.

AI oluşturucunuza ne sormalısınız?

• "Kayıt olma, giriş yapma ve ödeme süreçleri için otomatik testler yaz ve bunların nasıl çalıştırılacağını göster."
• "Her pull request'te bağımlılıkları kuran, uygulamayı derleyen ve testleri çalıştıran bir GitHub Actions iş akışı kur."
• "Pipeline'a bir tip kontrolü ve bir linter ekle; hatalarda başarısız olsun."
• "Pipeline'ın her adımının ne yaptığını sade bir dille açıkla."
• "Bir dağıtım yarıda kalırsa ne olur? Nasıl geri alırım?"
• "Hiçbir gizli anahtarın depoya gömülmediğinden ya da pipeline günlüklerinde yazdırılmadığından emin ol."

Uygulamanız API anahtarları kullanıyorsa, pipeline'ın da onlara ihtiyacı vardır — CI aracında şifreli sırlar olarak saklanmalı, yapılandırma dosyasında asla yer almamalıdır. Bkz. ortam değişkenleri ve sırlar.

Mythex'te CI/CD

Mythex sizin için bir CI pipeline'ı çalıştırmaz, ama aynı ihtiyaçların birçoğunu kendi yöntemiyle karşılar:

• Kontrol noktaları (checkpoints). Her başarılı agent turundan sonra Mythex bir git kontrol noktası kaydeder ve bir değişiklik ters giderse Bu noktaya geri dön ile projeyi geri alabilirsiniz. Bkz. Sohbet.
• Uygulama testi (App Testing). /test yazın; agent canlı önizlemenizde bir kullanıcı gibi gezinir ve bozuk akışları bildirir — her yayından önce yararlıdır. Bkz. App Testing.
• Yayınlamak bilinçli bir adımdır. Değişiklikler önce özel önizlemede görünür; herkese açık uygulamanız yalnızca tekrar yayınladığınızda güncellenir — sürekli dağıtımdan çok sürekli teslimata yakındır.
• GitHub senkronizasyonu (Pro). Projeyi bir GitHub deposuna senkronize ederseniz, her gönderimde testleri çalıştırmak için kendi GitHub Actions iş akışlarınızı ekleyebilirsiniz. Bkz. GitHub ve dışa aktarma.

Canlıya çıkmadan elle test edilecekler için kontrol listesi için uygulamanızı canlıya almadan önce nasıl test edersiniz yazısına, sürüm kontrolüyle çalışmak için ise AI ile geliştirilen uygulamada Git nasıl kullanılır yazısına bakın.

Sorular