CI/CD & DevOps
Azure DevOps ile otomatik dağıtım
Sürüm çıkmak heyecan verici olmamalı. Sıkıcı olmalı.
CI/CD, her kod değişikliğinin otomatik olarak derlenip test edilmesi (sürekli entegrasyon) ve onaylandığında aynı yoldan üretime taşınmasıdır (sürekli dağıtım). Amaç hız değil tekrarlanabilirlik: her sürüm aynı adımlardan, aynı kontrollerden geçer ve bir şey ters giderse geri alınabilir.
Deployment'ın stres yarattığı ekiplerde sorun genellikle insanlarda değil, sürecin elle yapılıyor olmasındadır. Elle yapılan her adım unutulmaya açıktır ve bir cuma akşamı geri alınamayan bir hataya dönüşür.
Testten dağıtıma kadar tüm zinciri otomatikleştiriyorum. Hedef basit: her değişiklik aynı yoldan, aynı kontrollerden geçerek üretime gitsin ve bir şey ters giderse tek tuşla geri alınabilsin.
Bunun yan etkisi kültürel: sürüm çıkmak risksiz hale geldiğinde ekipler daha sık ve daha küçük parçalar halinde yayına alır. Küçük sürüm, hata çıktığında sebebi bulmayı da kolaylaştırır — çünkü değişen şey azdır.
Dağıtım sürecinizi konuşalım
Şu cümleler tanıdık geliyorsa
Bu üç belirti, sürüm hattının elle yürüdüğünü gösterir.
“Sürümü sadece bir kişi çıkarabiliyor”
Süreç bir kişinin kafasındaysa, o kişi izinde olduğunda sistem donar. Otomasyonun ilk işi bu bilgiyi kafadan çıkarıp yazıya dökmektir.
“Cuma günü sürüm çıkmayız”
Belirli bir güne sürüm çıkmamak, geri alma mekanizmasına güvenilmediğinin itirafıdır. Güvenilir bir geri alma varsa günün önemi kalmaz.
“Bende çalışıyordu”
Ortamlar arasındaki fark, elle kurulmuş sunucuların doğal sonucu. Aynı imajın her ortamda çalışması bu tartışmayı bitirir.
Neler yapıyorum?
Sürekli entegrasyon
Her commit'te otomatik derleme ve test — bozuk kod ana dala giremez.
Otomatik dağıtım
Azure DevOps ve GitHub Actions ile tek tuşla, tekrarlanabilir sürümler.
Geri alınabilirlik
Sorunlu sürümden hızlı ve güvenli dönüş; “geri alamıyoruz” cümlesi sözlükten çıkar.
İzleme ve uyarı
Sistem sağlığını izleyen, sorunu kullanıcıdan önce haber veren uyarılar.
Gizli bilgi yönetimi
Parola ve anahtarların depoda değil, kasada durması; sürüm hattına yalnızca gerektiği anda verilmesi.
Altyapının koda dökülmesi
Sunucu ve ortam tanımlarının elle değil dosyadan kurulması; aynı ortamı sıfırdan kurabilmek.
Nasıl ilerliyoruz?
Bir süreci otomatikleştirmeden önce anlamak gerekir. Bu yüzden ilk adım, bugün elle yapılan her şeyi görünür kılmaktır.
Mevcut süreci çıkarma
Bugün sürümün nasıl çıktığını, elle yapılan her adımı tek tek not ediyoruz.
Pipeline kurma
Derleme, test ve paketleme adımlarını otomatikleştiriyoruz.
Ortam ve sürüm stratejisi
Test/üretim ortamlarını ve geri alma senaryosunu tasarlıyoruz.
Otomasyon ve devretme
Süreci ekibe devrediyorum; sürüm çıkmak artık kimsenin gecesini almıyor.
Testi olmayan bir projede CI/CD kurulur mu?
Bu soruyu çok duyuyorum ve cevabı evet — ama sırayı değiştirmek gerekiyor. Otomatik testi olmayan bir ekibe önce “test yazın, sonra konuşalım” demek pratikte işe yaramıyor; çünkü test yazma alışkanlığı, testin çalıştığını gördüğünüzde yerleşiyor.
Uyguladığım sıra şu: önce derleme ve paketleme otomatikleşir, sonra ortamlar tekilleşir, sonra dağıtım tek tuşa iner. Bu üç adım tek satır test yazmadan da kurulabilir ve tek başına en büyük riski — elle yapılan dağıtımı — ortadan kaldırır.
Test bundan sonra devreye giriyor ve genelde en kırılgan yerden başlıyor: sisteme para, yetki ya da veri bütünlüğü açısından en pahalıya mal olacak akış. Birkaç doğru yerleştirilmiş test, yüzlerce yüzeysel testten daha çok koruma sağlıyor. Hat kurulduğunda her yeni test kendiliğinden zincire ekleniyor.
Uygulamanın kendisi de buluta uygun hale gelecekse bu iki çalışma birlikte yürüyor — cloud-native geliştirme tarafında anlattığım yapılandırma ve sağlık kontrolü konuları, sürüm hattının güvenilir çalışmasının da ön koşulu.
Sık sorulan sorular
CI/CD nedir, pratikte neyi değiştirir?
Sürekli entegrasyon her değişikliği otomatik derleyip test eder; sürekli dağıtım onaylanan sürümü aynı adımlarla üretime taşır. Pratikte değişen şey şu: sürüm çıkmak bir olay olmaktan çıkar, rutin bir işe dönüşür. Ekipler daha sık ve daha küçük parçalar halinde yayına alır, hata çıktığında sebebi bulmak kolaylaşır.
Küçük bir ekibin CI/CD'ye ihtiyacı var mı?
Özellikle küçük ekiplerin var. Kalabalık ekiplerde süreç bilgisi birkaç kişiye dağılmış olur; üç kişilik bir ekipte sürüm çıkarmayı bilen tek kişi izne çıktığında iş durur. Otomasyon burada bir lüks değil, süreklilik güvencesi.
Azure DevOps mu, GitHub Actions mı?
İkisiyle de çalışıyorum. Kodunuz zaten GitHub'daysa Actions genelde daha az sürtünmeli. Azure DevOps, iş takibi ve sürüm yönetiminin aynı yerde toplanması istendiğinde ve kurumsal yetkilendirme ihtiyacı olduğunda öne çıkıyor. Karar aracın kendisinden çok ekibin bugün nerede çalıştığına bağlı.
Otomatik testimiz yok, yine de kurulabilir mi?
Evet. Derleme, paketleme ve dağıtımın otomatikleşmesi tek satır test gerektirmiyor ve en büyük riski zaten ortadan kaldırıyor. Testleri sonra, en kritik akıştan başlayarak ekliyoruz; hat kurulduğu için her yeni test kendiliğinden zincire giriyor.
Geri alma (rollback) nasıl çalışıyor?
Her sürüm değiştirilemez bir paket olarak saklanıyor; geri alma, önceki paketi yeniden yayına almak demek. Kritik nokta veritabanı: şema değişiklikleri geriye uyumlu yazılmadığında kodu geri almak yetmiyor. Bu yüzden şema değişikliklerini kod sürümünden ayrı ve iki yönlü çalışacak şekilde planlıyoruz.
Kurulumdan sonra bakımı kim yapıyor?
Ekibiniz. Hattı devretmek işin bir parçası: adımların ne yaptığı belgeleniyor, ekip bir sürümü baştan sona kendisi çıkarıyor ve ancak ondan sonra süreci bırakıyorum. Sonrasında ihtiyaç oldukça danışmanlık veriyorum, ama günlük işleyiş size kalıyor.
Sürüm çıkmak hâlâ bir ekip etkinliğiyse
Bunu değiştirebiliriz. Mevcut sürecinize birlikte bakalım; ilk görüşme ücretsiz.
Sürüm hattı için ön görüşme talep edinSürüm hattını daha geniş bir yazılım kurgusunun parçası olarak ele almak isterseniz Antalya yazılım danışmanlığı sayfasına bakabilirsiniz.