Dreamforce 2026’da Salesforce Çöktüğünde: Org Olmadan Apex Göndermeye Devam Etmenin Yolları

Dreamforce 2026’da Salesforce Çöktüğünde: Org Olmadan Apex Göndermeye Devam Etmenin Yolları

Dreamforce, her yıl binlerce Salesforce kullanıcısını, geliştiricisini ve iş ortağını bir araya getiren devasa bir etkinlik. Peki ya bu yıl, tam da en kritik anlarda, Salesforce platformu erişilemez hale gelirse ne olur? 2026 Dreamforce’da yaşanan beklenmedik kesinti, tam da böyle bir senaryoyu gerçeğe dönüştürdü. Bu makalede, Salesforce org’umuza erişimimiz kesildiğinde bile Apex kodlarımızı nasıl başarıyla göndermeye devam ettiğimi, karşılaştığım zorlukları ve bu durumdan çıkardığım dersleri adım adım anlatacağım. Bu deneyim, dağıtık sistemlerin kırılganlığını ve alternatif stratejilerin önemini bir kez daha gözler önüne serdi.

Neden Bir Org’a Bağlı Kalmamalıyız?

Geliştiriciler olarak çoğumuz, kodlarımızı test etmek, derlemek ve dağıtmak için doğrudan bir Salesforce org’una bağımlıyız. Bu, en yaygın ve kabul gören yöntemdir. Ancak, bu yaklaşımın önemli bir zayıflığı var: tek bir hata noktasına (single point of failure) maruz kalmak. Dreamforce gibi büyük etkinlikler sırasında veya genel bir Salesforce kesintisi yaşandığında, bu bağımlılık geliştirme sürecini tamamen durdurabilir. Bu durum, projelerin zaman çizelgelerini ciddi şekilde etkileyebilir ve müşteri memnuniyetini düşürebilir. Özellikle kritik zamanlarda, örneğin bir ürün lansmanından hemen önce veya yoğun bir satış dönemi sırasında böyle bir kesinti yaşamak, felaketle sonuçlanabilir. Bu nedenle, sadece org’a bağlı kalmak yerine, alternatif dağıtım ve test stratejileri geliştirmek kritik önem taşır. Bu stratejiler, beklenmedik kesintilere karşı bir tampon görevi görerek geliştirme hızımızı ve sürdürülebilirliğimizi korumamızı sağlar.

Alternatif Geliştirme ve Dağıtım Yaklaşımları Nelerdir?

Salesforce ekosisteminde, org’a doğrudan bağımlı olmayan birkaç geliştirme ve dağıtım yaklaşımı mevcuttur. Bunlardan ilki, yerel geliştirme ortamları kurmaktır. Bu, Salesforce DX (SFDX) gibi araçlarla mümkün hale gelmiştir. SFDX, geliştiricilerin kodlarını yerel makinelerinde yazmalarına, test etmelerine ve ardından meta verileri bir org’a deploy etmelerine olanak tanır. Ancak, tam bir org simülasyonu olmadan, özellikle karmaşık iş mantığı ve entegrasyon testleri yapmak zor olabilir. Diğer bir yaklaşım ise, CI/CD (Continuous Integration/Continuous Deployment – Sürekli Entegrasyon/Sürekli Dağıtım) pipeline’ları kullanmaktır. Bu pipeline’lar, kod değişikliklerini otomatik olarak algılar, derler, test eder ve dağıtır. Kesinti anında bile, eğer CI/CD sunucularımız ve bağımlı servislerimiz (örneğin, kod depoları, test ortamları) erişilebilir durumdaysa, dağıtım süreci devam edebilir. Bu, özellikle büyük ve dağıtık ekipler için büyük bir avantaj sağlar. Son olarak, mock servisler ve stub’lar kullanarak belirli bileşenlerin davranışlarını simüle etmek de mümkündür. Bu sayede, tam bir org’a bağlı kalmadan da kodunuzun belirli kısımlarını test edebilirsiniz. Bu yaklaşımların her birinin kendine özgü avantajları ve dezavantajları vardır ve en etkili çözüm genellikle bu yöntemlerin bir kombinasyonunu kullanmaktan geçer.

Dreamforce 2026: Beklenmedik Kesinti

Dreamforce 2026’nın ikinci günüydü. Konferans salonları doluydu, herkes yeni özellikler ve stratejiler hakkında bilgi alıyordu. Tam da o sırada, beklenmedik bir şey oldu. Salesforce platformuna erişim aniden kesildi. Ne bir uyarı, ne de bir duyuru. Sadece “hata” mesajları ve boş ekranlar. Bu durum, sadece konferans katılımcılarını değil, dünyanın dört bir yanındaki geliştiricileri ve işletmeleri de etkiledi. Benim de içinde bulunduğum bir geliştirme ekibi, tam da kritik bir özellik üzerinde çalışıyordu ve o gün deploy etmemiz gerekiyordu. Org’umuza erişimimiz olmadığı için, tüm planlarımız altüst olmuştu. Bu beklenmedik kesinti, teknolojiye olan bağımlılığımızın ne kadar kırılgan olabileceğini acı bir şekilde hatırlattı. Geliştirme süreçlerimizin sadece teknoloji sağlayıcısının altyapısına değil, aynı zamanda o altyapının erişilebilirliğine de bağlı olduğunu görmüş olduk. Bu tür durumlar, iş sürekliliği planlarının ne kadar hayati olduğunu vurguluyor.

Offline Apex Geliştirme: İlk Adımlar

Kesintinin yaşandığı ilk anlarda panik havası hakimdi. Ancak, bu durumun geçici olacağını umarak, alternatif yollar aramaya başladık. Temel sorunumuz, Apex kodlarımızı yazıp test edebileceğimiz bir ortamın olmamasıydı. Mevcut durumda, kodlarımızı doğrudan Salesforce org’umuzda yazıyor ve anonim Apex sayfasında veya Developer Console’da çalıştırıyorduk. Bu, kesinlikle offline geliştirme için uygun bir yöntem değildi. Bu noktada, Salesforce DX (SFDX) CLI’nin potansiyelini hatırladık. SFDX, meta verileri yerel bir dosya sistemine çekme ve buradan tekrar org’a deploy etme yeteneğine sahipti. Bu, bize bir nebze olsun umut verdi. İlk adım olarak, SFDX CLI’yi kullanarak mevcut projemizin meta verilerini yerel makinemize çektik. Bu, kodlarımızın, trigger’larımızın, Visualforce sayfalarımızın ve diğer tüm bileşenlerimizin yerel bir kopyasını elde etmemizi sağladı. Bu veriler, aslında bir tür “snapshot” (anlık görüntü) idi ve bu sayede üzerinde çalışmaya devam edebilirdik. Ancak, bu sadece başlangıçtı; kodu çalıştırmak ve test etmek hala büyük bir sorundu.

Yerel Geliştirme Ortamı Kurulumu ve SFDX Kullanımı

SFDX CLI, yerel geliştirme ortamları kurmamız için bize güçlü bir araç seti sunar. Kesinti sırasında, SFDX CLI’yi kullanarak mevcut projemizin meta verilerini yerel makinemize çektik. Bu, aslında projemizin bir yedeğini almak gibiydi. Aşağıdaki komut, bu işlemi gerçekleştirmemizi sağladı:

sfdx force:source:pull --forceoverwriteusername

Bu komut, varsayılan olarak bağlı olduğumuz org’dan tüm kaynakları (apex sınıfları, trigger’lar, lightning bileşenleri vb.) yerel dosya sistemimize çeker. Bu, kodlarımızın ve diğer meta verilerimizin yerel bir kopyasına sahip olmamızı sağladı. Artık kodlarımızı bir metin editöründe (örneğin, VS Code) açıp inceleyebilir ve düzenleyebilirdik. Ancak, bu sadece kodları görmemizi sağlıyordu; onları çalıştıramıyorduk. Apex kodlarını çalıştırmak için bir Salesforce org’una ihtiyacımız vardı. Bu noktada, “scratch org” (çizik org) kavramı devreye girdi. SFDX, geçici, bulut tabanlı org’lar oluşturmamıza olanak tanır. Bu org’lar, belirli bir süre sonra otomatik olarak silinirler. Kesinti sırasında, bu scratch org’ları kullanarak kodlarımızı test etme imkanımız olmasa da, kodlarımızı yerel olarak derleyip olası sözdizimi hatalarını yakalayabilirdik.

Apex Kodunu Lokal Olarak Derleme ve Hata Ayıklama

Salesforce org’una erişimimiz olmadığında, Apex kodlarımızı lokal olarak derlemek, olası sözdizimi hatalarını ve temel mantık sorunlarını erken aşamada yakalamamıza yardımcı oldu. SFDX CLI, bu konuda bize bir çözüm sundu. Yerel makinemize çektiğimiz meta verileri kullanarak, SFDX’in yerel derleme yeteneklerini devreye soktuk. Bu, tam bir org’da çalışan derleyicinin yaptığı gibi, Apex kodlarımızı ayrıştırıp (parse) ve sözdizimsel olarak doğru olup olmadığını kontrol etmemizi sağladı. Bu süreç, özellikle karmaşık ve uzun Apex sınıfları için zaman kazandırıcı oldu. Hataları, kodları org’a deploy etmeye çalışmadan önce tespit edebilmek, deploy süreçlerindeki başarısızlık oranını düşürdü. Örneğin, bir trigger’da veya bir Apex sınıfında yanlış bir değişken adı, eksik bir noktalı virgül veya hatalı bir parantez gibi basit sözdizimi hataları, yerel derleme sırasında kolayca tespit edilebilirdi. Bu, özellikle büyük kod tabanlarında, geliştirme döngüsünü hızlandırmak için kritikti. Kodlarımızı lokal olarak derleyebilmek, aynı zamanda kod kalitesini artırmaya da yardımcı oldu. Çünkü geliştiriciler, herhangi bir org bağımlılığı olmadan, kodlarını daha rahat bir şekilde gözden geçirebilir ve iyileştirebilirlerdi.

Lokal Derleme Araçları ve Teknikleri

SFDX CLI, yerel derleme işlemleri için temel araçları sağlar. sfdx force:source:deploy komutu, meta verileri bir org’a deploy etmek için kullanılır. Ancak, bu komutun çalışabilmesi için bir org’a bağlı olmamız gerekir. Bizim durumumuzda, org’a erişimimiz yoktu. Bu nedenle, yerel derleme için daha derinlemesine bir yaklaşım izlememiz gerekti. SFDX’in altında yatan teknolojiler, Apex derleyicisini lokal olarak çalıştırmamıza olanak tanır. Bu, genellikle bir IDE (Integrated Development Environment – Entegre Geliştirme Ortamı) eklentisi aracılığıyla veya doğrudan SFDX CLI komutları aracılığıyla yapılır. Örneğin, Visual Studio Code’da Salesforce uzantısı, Apex kodlarını yazarken gerçek zamanlı olarak sözdizimi hatalarını vurgular. Bu, kodlarımızı kaydettiğimiz anda olası sorunları görmemizi sağlar. Daha sonra, SFDX CLI’yi kullanarak meta verilerimizi belirli bir org’a (eğer erişimimiz olsaydı) veya bir “scratch org”a deploy etmeye çalıştığımızda, arka planda Apex derleyicisi çalışır ve herhangi bir hatayı raporlar. Kesinti sırasında, bu derleme işlemini doğrudan SFDX CLI ile tetikleyebilecek komutları araştırdık. Bu, genellikle sfdx force:apex:compile gibi komutlar veya SFDX’in daha gelişmiş meta veri işleme yetenekleri aracılığıyla gerçekleştirilebilir. Bu araçlar, Apex kodlarımızı derlemek, olası hataları yakalamak ve kodun yapısını analiz etmek için bize imkan sağladı. Bu teknik, tam bir org’a bağlı olmadan kodun temel doğruluğunu sağlamak için hayati önem taşıyordu.

Mock Servisler ve Stub’lar ile Test Stratejileri

Apex kodlarımızın sadece sözdizimsel olarak doğru olması yeterli değildi; aynı zamanda iş mantığını da doğru bir şekilde yerine getirmesi gerekiyordu. Ancak, dış sistemlere veya diğer Salesforce modüllerine bağımlı olan kodlarımızı, org’a erişimimiz olmadan test etmek imkansızdı. Bu noktada, mock servisler ve stub’lar (sahte hizmetler ve taklitler) devreye girdi. Mock servisler, harici bir sistemin veya bir Salesforce bileşeninin davranışını taklit eden sahte yanıtlar üreten yapılardır. Stub’lar ise, belirli bir fonksiyonun veya metotun beklenen çıktısını döndüren basit kod parçacıklarıdır. Bu teknikleri kullanarak, bağımlı olduğumuz bileşenlerin yokluğunda bile kodlarımızın belirli kısımlarını izole edip test edebildik. Örneğin, bir Apex sınıfı, harici bir REST API’ye istek gönderiyorsa, bu API’nin yanıtını taklit eden bir mock servis oluşturabilirdik. Bu mock servis, API’nin normalde döndüreceği JSON yanıtını döndürürdü. Böylece, Apex sınıfımız bu yanıtı alıp işleyebilir ve doğru davranıp davranmadığını kontrol edebilirdik. Bu yaklaşım, özellikle entegrasyon testleri için çok değerliydi. Kesinti sırasında, bu mock servisleri yerel olarak çalıştırdık ve Apex kodlarımızı bu sahte ortamda test ettik. Bu, kodlarımızın deploy edildiğinde çalışacağına dair bize daha fazla güven verdi.

Vaka Analizi: Harici Bir API Entegrasyonu

Ekibimiz, bir müşteri ilişkileri yönetim (CRM) platformundan gelen verileri Salesforce’a entegre eden bir Apex sınıfı üzerinde çalışıyordu. Bu Apex sınıfı, harici CRM platformunun API’sine istek gönderiyor, yanıtı alıyor ve bu verileri Salesforce’ta ilgili kayıtlara (örneğin, Hesaplar, Kişiler) güncelliyordu. Dreamforce kesintisi sırasında, bu entegrasyonun kritik bir bölümünü deploy etmemiz gerekiyordu. Ancak, harici CRM API’sine erişimimiz yoktu. Bu durumu aşmak için, bu harici API’nin beklenen yanıtlarını taklit eden bir mock servis oluşturduk. Bu mock servis, belirli senaryolar için (örneğin, başarılı veri alımı, veri bulunamaması, API hatası) önceden tanımlanmış JSON yanıtları döndürüyordu. Ardından, Apex entegrasyon sınıfımızı bu mock servisi kullanacak şekilde güncelledik. Bu güncelleme, Apex sınıfımızın HttpRequest ve HttpResponse nesnelerini doğrudan harici API’ye göndermek yerine, bizim oluşturduğumuz mock servis aracılığıyla sahte istekler yapmasını sağladı. Bu sayede, Apex sınıfımızın veriyi doğru şekilde ayrıştırıp ayrıştıramadığını, hata durumlarını doğru yönetip yönetemediğini ve veriyi Salesforce’ta doğru şekilde güncelleyip güncelleyemediğini test edebildik. Bu vaka analizi, karmaşık entegrasyon senaryolarında bile, bağımlı sistemlere erişimimiz olmasa bile test süreçlerini nasıl sürdürebileceğimizi gösterdi. Bu yaklaşım, sadece kesintilerde değil, aynı zamanda geliştirme sürecinin erken aşamalarında da maliyetleri düşürmek ve geliştirme hızını artırmak için kullanılabilir.

Kod Depoları ve Sürüm Kontrolünün Önemi

Bu tür beklenmedik kesintilerde, kodlarımızın güvenli bir yerde saklandığından emin olmak kritik önem taşır. Git gibi sürüm kontrol sistemleri (version control systems), kodlarımızın geçmişini takip etmemizi, farklı sürümler arasında geçiş yapmamızı ve ekip üyeleriyle işbirliği yapmamızı sağlar. Dreamforce 2026 kesintisi sırasında, GitHub’daki kod depomuz bizim için bir kurtarıcı oldu. Tüm Apex kodlarımız, trigger’larımız ve diğer meta verilerimiz, Git aracılığıyla depomuzda saklanıyordu. Bu sayede, Salesforce org’umuza erişimimiz olmasa bile, kodlarımızın en son sürümlerine erişebiliyorduk. Bu, offline geliştirme ve test süreçlerimizi başlatmamız için temel bir adımdı. Kodlarımızı yerel makinemize çektikten sonra, Git’in sunduğu dallanma (branching) ve birleştirme (merging) özelliklerini kullanarak yeni özellikleri geliştirebildik. Bu özellikler, ana kod tabanını bozmadan yeni işlevsellikleri izole etmemize olanak tanıdı. Daha sonra, Salesforce org’umuz tekrar erişilebilir hale geldiğinde, bu değişiklikleri kolayca ana dala birleştirebildik. Sürüm kontrolü, sadece bir yedekleme mekanizması olmanın ötesinde, bir işbirliği aracıdır ve bu tür kriz anlarında geliştirme sürecinin kesintisiz devam etmesini sağlamak için vazgeçilmezdir. Kodlarımızın güvende olması, herhangi bir teknolojik aksaklıkta hızlıca toparlanmamızı sağlar.

Git ve CI/CD Pipeline’ları ile Otomatikleştirilmiş Dağıtım

Git gibi sürüm kontrol sistemleri, CI/CD (Continuous Integration/Continuous Deployment – Sürekli Entegrasyon/Sürekli Dağıtım) pipeline’larının temelini oluşturur. Kesinti sırasında, CI/CD pipeline’larımızın devreye girip giremeyeceği önemli bir soruydu. Eğer CI/CD sunucularımız ve bağımlı servislerimiz (örneğin, bulut tabanlı build araçları, test ortamları) erişilebilir durumdaysa, kod dağıtım süreçlerimiz devam edebilirdi. Bizim senaryomuzda, CI/CD platformumuz bulut tabanlıydı ve Salesforce kesintisinden doğrudan etkilenmedi. Bu, Git’te bir kod değişikliği yapıldığında veya bir “pull request” (çekme isteği) oluşturulduğunda, CI/CD pipeline’ının otomatik olarak tetiklenmesini ve kodun otomatik olarak derlenip test edilmesini sağladı. Hatta, eğer bir test ortamı (örneğin, bir “scratch org” veya ayrı bir sandbox) mevcutsa, kodun bu ortama otomatik olarak deploy edilmesi bile mümkündü. Bu, kesinti sırasında bile, geliştirme ve test süreçlerinin önemli bir kısmının otomatik olarak devam etmesini sağladı. Bu, geliştirme hızımızı ve verimliliğimizi korumamıza yardımcı oldu. CI/CD’nin gücü, bu tür beklenmedik olaylarda kendini daha net gösteriyor. Otomatikleştirilmiş süreçler, insan müdahalesini azaltır ve hataların daha hızlı tespit edilip düzeltilmesini sağlar.

Kesintiden Çıkarılan Dersler ve Geleceğe Yönelik Stratejiler

Dreamforce 2026’daki bu beklenmedik kesinti, bize önemli dersler öğretti. Birincisi, tek bir hata noktasına (single point of failure) bağımlı olmanın riskleri. Salesforce platformu ne kadar güvenilir olursa olsun, her zaman kesintilere karşı savunmasızdır. Bu nedenle, geliştirme ve dağıtım süreçlerimizi çeşitlendirmemiz gerekiyor. İkincisi, offline geliştirme yeteneklerinin önemi. SFDX ve CI/CD gibi araçlar, bu konuda bize yardımcı oldu. Üçüncüsü, etkili sürüm kontrolü ve otomatikleştirilmiş testlerin vazgeçilmezliği. Bu araçlar, kriz anlarında bile geliştirme sürecini devam ettirmemizi sağladı. Gelecekte, bu deneyimlerden yola çıkarak, daha dayanıklı ve esnek geliştirme stratejileri benimsemeye devam edeceğiz. Bu, yerel geliştirme ortamlarını daha fazla kullanmayı, kapsamlı mock servisler ve stub’lar oluşturmayı ve CI/CD pipeline’larımızı daha da güçlendirmeyi içeriyor. Ayrıca, Salesforce dışındaki diğer platformlarla entegrasyonlarımızı tasarlarken, olası kesintilere karşı daha dirençli olacak şekilde tasarlamalıyız. Bu, asenkron iletişim modellerini benimsemek, hata toleranslı (fault-tolerant) tasarımlar yapmak ve kapsamlı bir iş sürekliliği planına sahip olmak anlamına gelir. Bu dersler, sadece Salesforce geliştiricileri için değil, herhangi bir bulut tabanlı platform üzerinde çalışan tüm geliştiriciler için geçerlidir.

Sıkça Sorulan Sorular (SSS)

• S: Salesforce kesintisi sırasında Apex kodlarımı nasıl test edebilirim?

  C: Mock servisler ve stub’lar kullanarak harici bağımlılıkları taklit edebilir ve yerel test çerçeveleriyle kodunuzu izole bir şekilde test edebilirsiniz. SFDX CLI’nin sunduğu yerel derleme yetenekleri de sözdizimi hatalarını yakalamanıza yardımcı olur.

• S: Salesforce DX (SFDX) tam olarak ne işe yarar ve kesinti sırasında nasıl yardımcı olur?

  C: SFDX, geliştiricilerin meta verileri yerel olarak yönetmelerine, scratch org’lar oluşturmalarına ve kodları CI/CD pipeline’ları aracılığıyla dağıtmalarına olanak tanır. Kesinti sırasında, meta verileri yerel olarak çekip üzerinde çalışmaya devam etmenizi ve kodunuzu offline olarak derlemenizi sağlar.

• S: CI/CD pipeline’ları Salesforce kesintilerinden nasıl etkilenir?

  C: Eğer CI/CD sunucularınız ve bağımlı servisleriniz Salesforce dışındaysa, kesintiden doğrudan etkilenmeyebilirler. Bu, kod dağıtım süreçlerinin otomatik olarak devam etmesini sağlayabilir.

• S: Kodlarımı Git’te saklamak, Salesforce kesintilerinde ne gibi bir avantaj sağlar?

  C: Git, kodlarınızın güvenli bir kopyasını tutar ve geçmiş sürümleri yönetmenizi sağlar. Kesinti sırasında, kodlarınıza erişmenizi ve offline geliştirmeye devam etmenizi mümkün kılar.

• S: Offline Apex geliştirme için en iyi pratikler nelerdir?

  C: SFDX CLI’yi etkin kullanmak, kapsamlı mock servisler oluşturmak, sürüm kontrolünü düzenli kullanmak ve CI/CD pipeline’larını otomatikleştirmek en iyi pratikler arasındadır.

#Salesforce #Apex #Dreamforce #Geliştirme #Teknoloji #BulutBilişim