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

⏱️ 5 dk okuma📅 1 Nisan 2026🔄 Güncelleme: 3 Nisan 2026👁️ 18 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. Yani 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.

Tabii 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 bildirim 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. Yani 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 oldu: 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.

<properties>
<version.spring.cloud.azure>7.1.0</version.spring.cloud.azure>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.azure.spring</groupId>
<artifactId>spring-cloud-azure-dependencies</artifactId>
<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ı siz 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 tabii 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 bildirim 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ı.

İçeriği paylaş: