⏱️ 5 dk okuma📅 13 Mart 2026🔄 Güncelleme: 23 Haziran 2026
Azure App Service Slot Swap: Tek Komutla Değişim
Azure App Service Slot Swap Nedir, Ne Değildir?
Şöyle sorayım: “Deployment sürecinde insanı yoran şey ne?” Cevap çok net; plansız aksaklıklar! Aslında şu Azure App Service’in slot mantığı yıllardır hayatımızda dolanıyor. Production ile staging, hatta bazen test veya pre-prod gibi ayrı ortamlar kuruyorsun, yeni versiyonun hazır mı – hani canlıya geçeceksin – swap’la hemen değiştiriyorsun ve maksat sıfır kesinti. Masal gibi anlatılıyor ama… Gerçekte ufak detaylarla iş bambaşka türlü çetrefilli hâle gelebiliyor.
Sistemci ya da bulut mimarı kimliğimle şunu söyleyeyim: Portal’dan ‘swap’ butonuna tıklamaktan başlarda heyecan duyan biri zamanla “Bu işi otomasyonda nasıl çözeceğiz yahu?” diye hayıflanıyor. Ekip sayısı arttıkça ya da deployment trafiği çoğaldıkça işler kontrolden çıkıyor (bence). Şimdi işe devreye farklı bir olay girdi: Azure Developer CLI (kısaca azd)‘nın slot swap komutu işleri gerçekten akıcı bir seviyeye çıkarıyor, önü fark ettim.
Slot Swap’ın Temeli
İşin özünde, Azure App Service’in slot mantığı, farklı ortamlar arasında hızlı ve risksiz geçiş yapmak için tasarlanmış. Hani dedim ya, staging’de test edilen bir sürüm, tek tuşla production’a taşınıyor. Burada asıl amaç, canlı ortamı ayakta tutmak ve minimum kesintiyle versiyon güncellemeleri yapmak.
Slotların Kullanım Senaryoları
Staging ve Production Ayrımı: En klasik senaryo. Staging’de test ediliyor, canlıya swap ile çıkıyor.
Pre-prod veya Test Ortamları: Büyük projelerde birden fazla slot açılıyor; her biri farklı test amaçlarına hizmet ediyor.
A/B Testing: Kullanıcıların bir kısmı yeni slot üzerinden yönlendirilebiliyor, deneyim karşılaştırması yapılabiliyor.
Kişisel Deneyim: İlk Swap Denemem (2019)
2019’da bir sağlık teknolojileri projesinde, Azure App Service slot swap’ı ilk defa canlıda kullanmıştık. O dönem Staging slotuna yeni bir API sürümünü deploy edip, swap işlemini başlatınca, beklediğim gibi sorunsuz geçti. Fakat hemen ardından bir config karmaşası yüzünden troubleshoot süreci başladı. O gün minik bir downtime yaşanmıştı, ders çıkardık: slotlar arası config ve variable yönetimine ekstra dikkat şart!
💡 Bilgi: Slot swap sırasında ayrıca ek yapılandırma dosyalarıyla uğraşmaya gerek yok—hazır kurulu azd projeniz olduğu anda sistemi kendisi çözebiliyor! Kural bu.
Azure App Service slot swap, staging/test sürümlerini production’a minimum kesintiyle taşımayı amaçlar; Azure Developer CLI (azd) işe bu geçişi otomatikleştirerek süreci hızlandırır.
Özellik
Slot Swap ile
azd appservice swap ile
Hedef
Staging/pre-prod ile production arasında hızlı geçiş
Bu geçişi komutla uçtan uca otomatikleştirme
Deployment akışı
Yeni sürümü ilgili slota deploy et, sonra swap uygula
Slotlar arası config/variable uyumu kritik olabilir
Hazır azd projesi varsa ekstra uğraş olmadan çözümleyebilir
Not: Swap öncesi slotlar arası config/variable tutarlılığını kontrol etmek, olası troubleshoot’ları azaltır.
azd appservice swap ile Baştan Sona Otomasyon
Bendeki ilk izlenim şöyle öldü: İlk defa azd appservice swap‘ı denediğimde beklediğim kadar karmaşık olmadığını gördüm—bir garip his! Hep ekstra parametreler hazırlamaya şartlandığımızdan fazlasını aradım önce. Yok… Proje zaten tanımlıysa azd kendi ortamınızı algılıveriyor. Diyelim ki sadece bir slotunuz var; sekmeli soru-cevap yok, doğrudan production ile staging arasında anında takas… Güzel iş! Nedense eski usül CLI’lardaki yorgunluğa alışmışız resmen.
Açıkçası, Peki gerçekte süreç nasıl ilerliyor?
Kodu geliştirip staging slota atıyorsun.
Dikkatlice test ediyorsun—ufak tefek bug avı.
En son swap komutu—ve çat diye prod’da yeni sürüm!
Şunu unutmayın (tecrübeyle sabit): Uygulamanız tek parça değilse yanı microservices mimariniz varsa --service bayrağıyla her servisi teker teker seçebilirsiniz. Her şeye tek komut yetmeyebilir; ince ayar yapmak sizin elinizde.
Kullanım Biçimleri ve Pratik İpuçları
Madem laf uzatmak istemiyorum, biraz örnek üzerinden devam edelim. Staging’de her şey yolunda mı? Canlıya almak an meselesi:
Düşünün ki ortamda onlarca servis dolaşıyor (inanın bana). O zaman isme göre hedef göstererek nokta atışı yaparsınız:
azd appservice swap --service api --src staging --dst @main
Slot swap’ın bence en şahane tarafı şu:
Geliştiricinin üzerinde sabaha karşı canlıya geçti mi stresi kalmaz! Testi bitir–swap gönder–bitti gitti!
Otomasyona Geçiş Süreci: Gerçek Bir Proje Örneği
2022’de, Logosoft danışmanlığında yürüttüğümüz bir finans uygulamasında, CI/CD pipeline ile slot swap sürecini tam otomasyonla tümleşik ettik. Her push sonrası staging’e deployment, ardından entegrasyon testleri ve swap işlemleri zincirleme yürüdü. Sonunda, canlıya geçiş neredeyse “insansız” öldü. Takımda vakit ve stres ciddi azalırken, hata oranı da neredeyse sıfırlandı. Otomasyonun tadı orada çıktı resmen (kendi tecrübem)
Peki Ya Dezavantajları? Teoride Harika, Pratikte Bakalım…
Hani, Pembe tablo çizmek isterdim ama gerçekçi olayım.
Bir keresinde büyükçe bir e-ticaret platformunda prod ortamında slotlar yer değiştirdikten sonra environment variables kısa süreliğine karıştı. Mini çaplı downtime kaçınılmaz öldü! Yanı “hiç kesinti olmuyor” demesi kolay da pratikte dikkat etmezsen sorun yaşarsın.
Aynı config herkese uyar mı?: Bazen değişken isimleri tutmaz — connection string başka yerde farklıdır mesela — kod patlayabilir!
Zincirleme dependency faciası: Microservices kullananlarda mesajlaşma kuyruğu veya önbellek yönetimi karmaşıksa hatayı yakalamak zorlanıyor insan. Bir de rollback gerekiyorsa… İşte asıl orada ter basıyor!
Bitişik ayarlar: Eğer domain veya ağ katmanı özelleştirilmişse slotların davranışlarını iki kere kontrol edin derim; ek test şart oluyor genellikle.
Bana kalırsa en makul reçete: Swap’tan önce bütün entegrasyon testlerini staging’de koşmak—otomasyon burada kritik rol oynar ve uygulama ayarlarınızı mutlaka slot-specific configuration‘a dayandırmak gerekir.
Bunun Yerine Alternatif Yöntemler Var Mı?
Şöyle söyleyeyim, Dürüst olayım; hâlâ birçok kişi Portaldan tıklayarak veya klasik Azure CLI yöntemiyle (az webapp deployment slot swap...) işlem yapıyor. Yanlış mı? Yok canım.
Ama inan bana azd’deki dahil çalışma şekli özellikle sürekli değişken ortamlarda ciddi hız kazandırıyor — hele ekip büyüdüyse eski teknikler gününde biraz antik kalabiliyor hani.
Kişisel Anekdot: Rollback Stresim (2021)
2021’de dev bir SaaS ürünü için slot swap sonrası rollback’e mecbur kaldık. Swap’tan hemen sonra bazı kullanıcılar hatalı config nedeniyle erişim sorunu yaşadı. Yarım saatlik hızlı rollback ile staging’e döndük fakat o sırada hem operasyon hem iletişim yoğunluğu fazlaydı. Swap’ın ne kadar risksiz olabileceğini ancak doğru konfigürasyon. Testlerle anladım, o gün işin “insansız” tarafı bence hayat kurtardı.
Neden Geliştirici İçin Büyük Kolaylık? Vakit Kazandıran Küçük Detaylar…
Takımlar için terminalden hükmetmek üretkenlik açısından bence cidden sihir etkisi yaratıyor
Düşündünüz mü hiç?.. Çoğu günümüz terminal ekranıyla geçiyor aslında—öyle garip panellerden link ararken kafa dağıtmanın anlamı gerçekten yok.
Sadece console’dan ayrılmadan deployment’ı tamamlamak = hata azaltan en büyük pratiklerden biri benim gözümde.
Neden mi?
Zincirleme Otomasyon Sağlıyor: Eğer CI/CD pipeline varsa tüm akış insansız kusursuz dönebilir (hayal değil).
Koddan Geldiği Gibi Tanımlama: Zaten var olan projeyi tekrar tekrar tanımlamak zorunda değilsin – yaml dosyası aramak geçmişte kaldı diyebilirim.
Ekip Standartları Sağlamlaşıyor: Aynı aracı herkes kullanınca bilgi paylaşımı daha düzgün ilerleyebiliyor.
Kopukluk Kalmadı: “Oradan oraya kopyala-yapıştır” devri tarihe karışmalıydı — sonunda oluyor.
Bir projede swap işlemini CLI üzerinden hızlıca tamamlamak, özellikle büyük ekiplerde zamandan ciddi tasarruf ettiriyor. Yanı, terminalden dakikalar içinde yapılan swap, eski günlerde saatlerce hazırlık ve kontrol gerektiren bir işti. Takım içi bilgi paylaşımı da artıyor, herkes aynı araç üzerinde ilerlediği için onboarding süresi kısalıyor.
Debug & Rollback Kolaylığı
Swap sürecinde bir sorun yaşandığında, geri dönmek için tek bir komut yeterli oluyor. Hem debug hem de rollback için, azd CLI’nın sunduğu pratiklik bence game-changer. Eskiden portalda tek tek slotları kontrol etmek, neredeyse takımı yavaşlatıyordu.
Geliştirici Deneyimi Üzerinden Kişisel Notlar
2023’te bir sosyal medya entegrasyonu projesinde swap’ı test ederken, swap sonrası sistemin beklenmedik şekilde hızlı açılması beni şaşırttı. Kod testleri staging’de yeterince uzun yapılınca, swap sonrası yaşanacak sürprizler minimuma iniyor. Yanı, profesyonel hayatımdaki en fazla “oh be!” dediklerimden biri buydu.
Sıkça Sorulan Sorular
Slot swap sırasında environment variables nasıl korunur?
Azure App Service slot swap işlemi sırasında, slot-specific ayarlar (örneğin, connection string veya environment variables) slotlarla birlikte hareket eder. Yanı staging’de tanımladığın bir variable, swap sonrası production’a geçer. Fakat, global ayarlara dikkat etmelisin; config karmaşası için swap öncesi hızlı bir check-up yap.
Swap işlemi tamamen geri alınabilir mi?
Evet, swap işlemi ters yönde tekrar çalıştırılarak geri alınabiliyor. Azd CLI veya Azure portal üzerinden swap reverse yapılabilir. Fakat, veri kaybı veya state değişimi varsa, rollback öncesi bu noktaları gözden geçirmek şart.
Slot swap işleminin CI/CD ile entegrasyonu mümkün mü?
Bence mümkün. Bilhassa GitHub Actions, Azure DevOps veya Jenkins gibi araçlarla swap işlemini CI/CD pipeline’a entegre edebilirsin. Her build sonrası swap komutunu otomatik tetiklemek, insan hatasını ciddi azaltıyor.
Swap sonrası performans testleri önerilir mi?
Bence swap sonrası kısa bir smoke test ve performans testini mutlaka eklemelisin. Çünkü canlı ortamda beklenmedik bir performans sorunu oluşabilir. Swap işlemi tamamlandıktan hemen sonra test scriptlerini devreye almak, gecikmesiz müdahale şansı yaratıyor.
Swap işlemi sırasında downtime yaşanır mı?
Swap işlemi teorik olarak sıfır kesinti ile gerçekleşiyor. Ne var ki, config veya dependency sorunlarında mini downtime yaşanabiliyor. Swap öncesi kapsamlı test ve ayar kontrolü ile riskler azaltılabilir.
Sözün Özü ve Tavsiyelerim
Şu terminalde kod editöründe harcanan vakti ölçsem şaşırırsınız herhalde…
Kendi adıma toparlarsam:
Modern Azure projelerinde hızlı. Firesiz bir dağıtımı kafaya taktıysanız mutlaka yeni nesil azd appservice swap’a göz kırptın derim! (bizzat test ettim). Denemezsen pişman olursun bile demiyorum—muhakkak gerekecek:) Bunu unutma;
Büyük takımlarda standart yöntem her zaman hata ihtimalinizi minimumda tutar (çok kritik!).
Sürekli deploy edilen SaaS dünyasında otomasyon yoksa başarı gelmesi mucize olur.
Aynı anda birkaç proje idare ediyorsan yepyeni araçların zamanı geri kazandırması kaçınılmazdır fakat… dokümantasyonu okumadan direkt dalmayın lütfen!
Eğer hâlâ tamamen otomatize olmamış deployment sürecindeyseniz “ben böyle iyiyim” demeyin — ileri taşıyacaksanız artık dönemin teknolojisine geçmeye başlayın diyorum ben!
Birkaç saat ufak öğrenme eğrisinden çekinmeyin — sonrası ışık hızına ulaşacak neredeyse;) Denedikten üç gün sonra fark edecek ve iyi ki diyeceksiniz emin olun!
Bakın, Vallahi, Dahası var tabiî;
Eğer bulut sistemlerinde hizmet sürekliliği konularına ilginiz varsa size şu bağlantıyı bırakıyorum:“Azure’da Kesintisiz Çalışmayı Tasarlamak. Orada başka açılımlardan da bahsettim çünkü.
Asıl merak ettiğim kısım burası mı? Terminale taşınan modern araçlar sizce gelecekte yazılım süreçlerinin neresini değiştirir? Yorumlara kendi hikâyelerinizi yazmayı unutmayın–belki sıradaki içerikte sizin maceranızı konuşuruz 😉
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.
Çerez tercihleriZorunlu çerezler sitenin çalışması için kullanılır. Analitik çerezler yalnız açık izninizden sonra Google Analytics ve Microsoft Clarity için etkinleştirilir. KVKK ve Çerez Politikası
✉
Haftalık Bülten
Azure, DevOps ve Yapay Zeka dünyasındaki en güncel içerikleri her hafta doğrudan e-postanıza alın.
