Azure ile Spring Testlerinde Docker Kullanınca Ne Değişiyor?

⏱️ 5 dk okuma📅 1 Nisan 2026🔄 Güncelleme: 10 Nisan 2026👁️ görüntülenme

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.

💡 Bilgi: Docker tabanlı testler en çok şu üç yerde parlıyor: lokal geliştirme, pull request doğrulaması ve CI üzerinde hızlı geri bildirım almak. Ama üretim davranışını bayağı temsil ediyor sanmayın; hayatı akışlarda yine bulutta entegrasyon testi şart.

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. Bu konuyla ilgili azd Mart 2026: AI Ajanları ve Copilot’la Yeni Dönem yazımıza da göz atmanızı tavsiye ederim.

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. GitHub Secret Scanning Büyüdü: Yeni Detektörler, Daha Az Sızıntı yazımızda bu konuya da değinmiştik. Daha fazla bilgi için GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü? yazımıza bakabilirsiniz.

Bileşen	Ne işe yarar?	Benim yorumum
spring-cloud-azure-starter-storage-blob	Blob istemcisini sağlar	Zor kısmı sadeleştiriyor
spring-boot-starter-test	Test çatısını getirir	Zaten olmazsa olmaz
spring-cloud-azure-docker-compose	Docker Compose entegrasyonu sağlar	Tatlı olan kısım burada başlıyor
Azurite	Blob/Queue/Table emülasyonu yapar	Tam servis değil ama iş görüyor

Maven tarafında bağımlılıklar

Kullanılan yapı gayet tanıdık aslında (şaşırtıcı ama gerçek). pom.xml içine Spring Cloud Azure dependency yönetimi ekleniyor ve ardından blob starter ile test desteği geliyor. Ben AZ-104 ve AZ-305 hazırlığı yaparken bile bu tarz dependency zincirlerinin ne kadar kritik olduğunu tekrar tekrar gördüm; küçük bir versiyon farkı bazen bütün testi devirebiliyor.


< version.spring.cloud.azure>7.1.0</version.spring.cloud.azure>

<dependencyManagement>
<dependencies>
<dependency>
<groupId> com.azure.spring</groupId>
spring-cloud-azure-dependencies
<version>${version.spring.cloud.azure}</version>
<type> pom</type>
<scope> import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId> qcom.azure.spring</groupId>

Şahsen, Kod bloğunda bilerek devamını kesiyorum çünkü esas mesele satır satır ezberlemek değil… yapı taşlarını anlamak daha önemli (ve evet, o küçük yazım hatasını sız de fark ettinizse iyi). Dependency import mantığını oturtunca diğer servisler için de aynı modeli genişletebiliyorsunuz.

Docker Compose dosyası nasıl görünüyor?

`storage-compose.yaml` dosyasında Azurite servisini ayağa kaldırıyorsunuz ve portları tanımlıyorsunuz. Bu bölüm çok kısa görünür ama etkisi büyük olur çünkü tüm altyapının kapısı buradan açılıyor. Daha fazla bilgi için CodeQL Autofix Raporları Artık Daha Gerçekçi yazımıza bakabilirsiniz.

services:
storage:
image: mcr.microsoft.com/azure-storage/azurite:latest
ports:
— '10000'
— '10001'
— '10002'
command: azurite - l /data --blobHost 0_0_0_0 --queueHost 0_0_0_0 --tableHost 0_0_0_0 --skipApiVersionCheck

Şunu fark ettim: E tabiî burada komut parametrelerinde dikkat etmek lazım. Asıl mesaj şu: container içindeki emülatörü dışarı açıp uygulamanızın ona bağlanmasını sağlıyorsunuz.. Bence bu modelin en güzel tarafı tekrar üretilebilir olması. Bugün laptopta çalışan şey yarın CI’da da aynı şekilde koşuyor — teoride değil, pratikte! Copilot’la Kendini Otomatikleştirmek: Ajanlarla Yeni Çalışma Şekli yazımızda bu konuya da değinmiştik.

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.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102