Azure ile Spring Testlerinde Docker Kullanınca Ne Değişiyor?
Bir şey söyleyeyim: gerçek Azure kaynağı açmadan test koşabilmek, özellikle ekip büyüyünce bayağı rahatlatıyor. 2023’te Ankara’da bir finans müşterisinde çalışırken, blob erişimi için her küçük değişiklikte ortam beklemekten herkes sıkılmıştı; testler lokal akıyordu. Prod benzeri davranış gelmiyordu. İşte tam orada Docker + emülatör yaklaşımı resmen nefes aldırdı (ben de ilk duyduğumda şaşırmıştım)
Bugün konuşacağım konu da bunun Spring tarafındaki karşılığı. Spring Cloud Azure kullanıyorsanız, Storage Blob gibi servisleri test ederken “Azure’a gerçekten bağlanayım mı, yoksa yerelde simüle mi edeyim?” sorusu var ya… çoğu zaman cevap çok net: önce yerelde hallet (yanlış duymadınız). Hem hızlısın hem de maliyet sürprizi yaşamıyorsun.
Spring Cloud Azure ne iş görüyor?
Spring Cloud Azure, Spring uygulamalarının Azure servisleriyle konuşmasını kolaylaştıran açık kaynak bir katman gibi düşünebilirsiniz. Yanı kodunuzda her seferinde düşük seviyeli bağlantı ayarlarıyla boğuşmak yerine, daha düzenli bir entegrasyon modeli alıyorsunuz. Ben bunu ilk kez 2021’de İzmir’de bir e-ticaret projesinde denemiştim; özellikle Storage ve Key Vault tarafında ciddi sadeleşme olmuştu.
Açık konuşayım, “kolaylaştırıyor” lafı bazen fazla havalı kaçıyor. Her şey güllük gülistanlık değil; sürüm uyumu, autoconfiguration davranışı. Test bağlamı doğru kurulmazsa iş çabuk karışıyor. Ama düzgün kurulduğunda fena değil, hatta baya iş görüyor.
Bir de şu var: Spring ekosisteminde test yazmak zaten başlı başına hassas iş. Bir yandan context açılış — kendi adıma konuşayım — süresi can sıkıyor, bir yandan dış bağımlılıkları izole etmeniz gerekiyor. Bu yüzden Docker ile çalışmak bana hep “laboratuvar ortamı” hissi veriyor; masada gerçek servisin minik bir kopyası var gibi.
Neden Docker ile test etmek mantıklı?
Lafı gevelemeden söyleyeyim: çünkü hızlısınız. Gerçek Azure kaynağı oluşturup silmek çoğu senaryoda gereksiz yere zaman yediriyor. En çok da de CI pipeline içinde ya da geliştiricinin laptop’ında her commit için bulut kaynağı ayağa kaldırmak pek tatlı değil.
Şunu söyleyeyim, 2019’da Gebze’de bir lojistik firmasında benzer bir şeyi VM tabanlı yapmaya çalışmıştık; test altyapısı ağırlaşınca ekip geri çekilmişti. O zamanlar Docker Compose olsaydı işler başka olurdu diye düşünmüşpek çok doğrusu. Şimdi aynı problemi daha temiz çözebiliyorsunuz: Azurite gibi emülatörleri ayağa kaldırıp storage senaryolarını doğruluyorsunuz.
Tabiî burada dürüst olayım: emülatör gerçek servis değil (inanın bana). Mesela API uyumluluğu veya bazı edge-case davranışlar birebir aynı olmayabiliyor. Kağıt üstünde süper duran şeyin pratikte küçük pürüzleri çıkabiliyor; bu yüzden ben bunu “ilk güvenlik ağı” olarak görüyorum, son söz olarak değil.
Mantık nasıl kurulur?
Buradaki temel fikir şu: uygulamanızın storage erişimini Azurite üzerinden yapıyorsunuz ve bunu test sırasında otomatik olarak ayağa kaldırıyorsunuz. Yanı geliştirici “docker compose up” dediğinde arka planda sahne kuruluyor… oyuncular hazır oluyor… sonra da test başlıyor.
Garip gelecek ama, Bunu ilk kez denediğimde hoşuma giden şey şu öldü: uygulama kodu ile test altyapısı birbirinden ayrıldı. Bu ayrım küçük projede bile değerli ama enterprise tarafta altın kadar kıymetli oluyor. Çünkü herkes aynı varsayımla ilerliyor; biri localde manuel çalıştırdı diye sonuç değişmiyor.
Durun, bir saniye. Daha fazla bilgi için
Test kodu neden değerli?
Vallahi, Kod tarafında amaç basit: blob’a yazdığınız veriyi okuyup doğrulamak ya da tam tersi senaryoyu sınamak. Bunun güzelliği şu — unit test dediğimiz şey artık yalnızca mock yağmurundan ibaret kalmıyor, gerçekçi bir çevreye biraz daha yaklaşıyor.
Bunu Logosoft’ta geçen yıl İstanbul’daki bir kamu kurumuna danışmanlık verirken çok net yaşadık.Müşteri sürekli “test geçti ama prod’da patladı” diyordu.Sebep kötü niyet değildi; testlerin tamamı aşırı soyuttu.Docker destekli yerel emülasyon ekleyince sorunların yarısı daha merge olmadan yakalanmaya başladı (ben de ilk duyduğumda şaşırmıştım)
Gerçek servise birebir eşit olmayan her emülatörün ortak kaderi şudur: hız kazandırır ama sizi tembelleştirmemeli! Kritik akışlarda yine canlı servisle son kontrol yapmak gerekir.
Küçük startup için ne anlama geliyor?
Size bir şey söyleyeyim, Küçük ekiplerde bu yaklaşım tam isabet oluyor çünkü bütçe sınırlı oluyor ve geliştirici sayısı az olduğunda ortak lokal ortam ihtiyacı artıyor. Bir startup için her değişiklikte Azure resource provisioning yapmak gereksiz lüks sayılır.
Ayrıca yeni başlayan ekiplerde hata ayıklama süresini ciddi azaltır. Geliştirici sabah kodu değiştirip öğlene kadar sonucu görebiliyor.Beklediğiniz kadar gösterişli olmasa da iş görüyor, hatta bazen release hızını doğrudan artırıyor.
Büyük enterprise’da neyi çözüyor?
Büyük organizasyonda mesele hızdan öte standardizasyon oluyor. Farklı takımlar farklı makinelerde farklı sonuç alıyorsa ortada operasyonel kâbus vardır.Docker tabanlı yaklaşım bunu kırıyor.
Sadece bununla bitmiyor… Enterprise ortamda security review. FinOps baskısı da var.Gereksiz Azure resource oluşturmadığınız için maliyet kontrolünüz iyileşiyor, bir de sandbox kaosu azalıyor.Ben AZ-500 üzerine çalışırken bile bu izolasyon fikrinin güvenlik açısından ne kadar temiz durduğunu sık sık not etmişimdir.
- Lokal geliştirmede hızlı geri bildirım verir.
- CI içinde tekrarlanabilirlik sağlar. — bunu es geçmeyin
- Maliyet kontrolüne yardım eder.
- Sorunları prod’a çıkmadan yakalama şansı verir.
- Ama gerçek servisin tüm davranışlarını kapsamaz.
Sahada gördüğüm birkaç pratik ders
Neyse uzatmayalım, en önemli derslerden biri versiyon kilidi konusu: `latest` etiketi kulağa rahat geliyor ama uzun vadede ufak sürprizler çıkarabiliyor. Geçen mart ayında Berlin’deki bir fintech müşterisinde sadece image güncellemesi yüzünden iki test flaky hâle gelmişti. Sebep net:sabit sürüm yerine kayan etiket kullanılmıştı.
.
Sıkça Sorulan Sorular
Spring Cloud Azure ile Docker kullanınca testlerde tam olarak ne değişiyor?
Aslında test akışında “gerçek Azure’a bağlanma” yerine yerel bir emülasyon/containers yaklaşımına geçiyorsun. Bu sayede testler daha hızlı başlıyor ve bulutta kaynak aç-kapa derdi azalıyor. Ayrıca CI tarafında her koşuda tutarlılık yakalamak daha kolay oluyor. Benim deneyimimde en büyük fark, geliştiricilerin “bekleyip ortam gelsin” stresinin ciddi azalmasıydı.
Azurite (emülatör) ile Storage Blob testleri gerçek Azure ile ne kadar benzer?
Azurite, Storage Blob senaryolarını hızlıca doğrulamak için çok işe yarıyor; ama birebir aynı davranışı garanti etmiyor. API uyumluluğu veya bazı edge-case’lerde küçük farklar çıkabiliyor. Bu yüzden ben emülatörü “ilk güvenlik ağı” gibi görüyorum; kritik akışlar için yine de bulutta entegrasyon testi şart.
Docker ile Azure emülatörlerini CI pipeline’da çalıştırmak için en iyi pratik ne?
En iyi pratik, emülatörleri pipeline içinde ayağa kaldırıp test bitince kapatacak şekilde kısa ömürlü container’lar kullanmak. Böylece her PR’da hızlı geri bildirım alırsın ve kaynak maliyeti oluşmaz. Ayrıca testlerin, container health check’leri tamamlanmadan başlamamasına dikkat etmek önemli; yoksa “arada geçiyor” gibi sınır bozucu flakiness yaşanabiliyor.
Yerelde emüle etmek yerine her zaman gerçek Azure’a bağlanmak ne zaman daha doğru olur?
Gerçek Azure’a bağlanmak, prod’e en yakın davranışı görmek istediğin kritik entegrasyon testlerinde daha doğru. Özellikle kimlik doğrulama, ağ kısıtları, özel konfigürasyonlar ve performans/limit testlerinde emülatör yetmeyebiliyor. Ben genelde şu şekilde yapıyorum: çoğu birim/entegrasyon testi yerelde, “gate” testleri işe bulutta gerçek servise karşı çalışıyor.
Kaynaklar ve İleri Okuma
- Spring Cloud Azure (Microsoft Learn) — Spring uygulamalarını Azure servisleriyle entegre etmeye yönelik resmî dokümantasyon.
- Azurite ile Azure Storage Emülasyonu (Microsoft Learn) — Docker/azurite kullanarak Storage senaryolarını yerelde test etme rehberi.
- Spring Uygulamalarında Test Stratejileri (Microsoft Learn) — Spring tabanlı test yaklaşımları ve entegrasyon testi perspektifleri.
- Azure SDK for Java GitHub (Resmî depo) — Azure servisleriyle çalışan Java/Spring bileşenlerinin kaynak ve örneklerine erişim.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
