Dreamforce, her y\u0131l binlerce Salesforce kullan\u0131c\u0131s\u0131n\u0131, geli\u015ftiricisini ve i\u015f orta\u011f\u0131n\u0131 bir araya getiren devasa bir etkinlik. Peki ya bu y\u0131l, tam da en kritik anlarda, Salesforce platformu eri\u015filemez hale gelirse ne olur? 2026 Dreamforce’da ya\u015fanan beklenmedik kesinti, tam da b\u00f6yle bir senaryoyu ger\u00e7e\u011fe d\u00f6n\u00fc\u015ft\u00fcrd\u00fc. Bu makalede, Salesforce org’umuza eri\u015fimimiz kesildi\u011finde bile Apex kodlar\u0131m\u0131z\u0131 nas\u0131l ba\u015far\u0131yla g\u00f6ndermeye devam etti\u011fimi, kar\u015f\u0131la\u015ft\u0131\u011f\u0131m zorluklar\u0131 ve bu durumdan \u00e7\u0131kard\u0131\u011f\u0131m dersleri ad\u0131m ad\u0131m anlataca\u011f\u0131m. Bu deneyim, da\u011f\u0131t\u0131k sistemlerin k\u0131r\u0131lganl\u0131\u011f\u0131n\u0131 ve alternatif stratejilerin \u00f6nemini bir kez daha g\u00f6zler \u00f6n\u00fcne serdi.<\/p>\n
Geli\u015ftiriciler olarak \u00e7o\u011fumuz, kodlar\u0131m\u0131z\u0131 test etmek, derlemek ve da\u011f\u0131tmak i\u00e7in do\u011frudan bir Salesforce org’una ba\u011f\u0131ml\u0131y\u0131z. Bu, en yayg\u0131n ve kabul g\u00f6ren y\u00f6ntemdir. Ancak, bu yakla\u015f\u0131m\u0131n \u00f6nemli bir zay\u0131fl\u0131\u011f\u0131 var: tek bir hata noktas\u0131na (single point of failure) maruz kalmak. Dreamforce gibi b\u00fcy\u00fck etkinlikler s\u0131ras\u0131nda veya genel bir Salesforce kesintisi ya\u015fand\u0131\u011f\u0131nda, bu ba\u011f\u0131ml\u0131l\u0131k geli\u015ftirme s\u00fcrecini tamamen durdurabilir. Bu durum, projelerin zaman \u00e7izelgelerini ciddi \u015fekilde etkileyebilir ve m\u00fc\u015fteri memnuniyetini d\u00fc\u015f\u00fcrebilir. \u00d6zellikle kritik zamanlarda, \u00f6rne\u011fin bir \u00fcr\u00fcn lansman\u0131ndan hemen \u00f6nce veya yo\u011fun bir sat\u0131\u015f d\u00f6nemi s\u0131ras\u0131nda b\u00f6yle bir kesinti ya\u015famak, felaketle sonu\u00e7lanabilir. Bu nedenle, sadece org’a ba\u011fl\u0131 kalmak yerine, alternatif da\u011f\u0131t\u0131m ve test stratejileri geli\u015ftirmek kritik \u00f6nem ta\u015f\u0131r. Bu stratejiler, beklenmedik kesintilere kar\u015f\u0131 bir tampon g\u00f6revi g\u00f6rerek geli\u015ftirme h\u0131z\u0131m\u0131z\u0131 ve s\u00fcrd\u00fcr\u00fclebilirli\u011fimizi korumam\u0131z\u0131 sa\u011flar.<\/p>\n
Salesforce ekosisteminde, org’a do\u011frudan ba\u011f\u0131ml\u0131 olmayan birka\u00e7 geli\u015ftirme ve da\u011f\u0131t\u0131m yakla\u015f\u0131m\u0131 mevcuttur. Bunlardan ilki, yerel geli\u015ftirme ortamlar\u0131 kurmakt\u0131r. Bu, Salesforce DX (SFDX) gibi ara\u00e7larla m\u00fcmk\u00fcn hale gelmi\u015ftir. SFDX, geli\u015ftiricilerin kodlar\u0131n\u0131 yerel makinelerinde yazmalar\u0131na, test etmelerine ve ard\u0131ndan meta verileri bir org’a deploy etmelerine olanak tan\u0131r. Ancak, tam bir org sim\u00fclasyonu olmadan, \u00f6zellikle karma\u015f\u0131k i\u015f mant\u0131\u011f\u0131 ve entegrasyon testleri yapmak zor olabilir. Di\u011fer bir yakla\u015f\u0131m ise, CI\/CD (Continuous Integration\/Continuous Deployment – S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) pipeline’lar\u0131 kullanmakt\u0131r. Bu pipeline’lar, kod de\u011fi\u015fikliklerini otomatik olarak alg\u0131lar, derler, test eder ve da\u011f\u0131t\u0131r. Kesinti an\u0131nda bile, e\u011fer CI\/CD sunucular\u0131m\u0131z ve ba\u011f\u0131ml\u0131 servislerimiz (\u00f6rne\u011fin, kod depolar\u0131, test ortamlar\u0131) eri\u015filebilir durumdaysa, da\u011f\u0131t\u0131m s\u00fcreci devam edebilir. Bu, \u00f6zellikle b\u00fcy\u00fck ve da\u011f\u0131t\u0131k ekipler i\u00e7in b\u00fcy\u00fck bir avantaj sa\u011flar. Son olarak, mock servisler ve stub’lar kullanarak belirli bile\u015fenlerin davran\u0131\u015flar\u0131n\u0131 sim\u00fcle etmek de m\u00fcmk\u00fcnd\u00fcr. Bu sayede, tam bir org’a ba\u011fl\u0131 kalmadan da kodunuzun belirli k\u0131s\u0131mlar\u0131n\u0131 test edebilirsiniz. Bu yakla\u015f\u0131mlar\u0131n her birinin kendine \u00f6zg\u00fc avantajlar\u0131 ve dezavantajlar\u0131 vard\u0131r ve en etkili \u00e7\u00f6z\u00fcm genellikle bu y\u00f6ntemlerin bir kombinasyonunu kullanmaktan ge\u00e7er.<\/p>\n
Dreamforce 2026’n\u0131n ikinci g\u00fcn\u00fcyd\u00fc. Konferans salonlar\u0131 doluydu, herkes yeni \u00f6zellikler ve stratejiler hakk\u0131nda bilgi al\u0131yordu. Tam da o s\u0131rada, beklenmedik bir \u015fey oldu. Salesforce platformuna eri\u015fim aniden kesildi. Ne bir uyar\u0131, ne de bir duyuru. Sadece “hata” mesajlar\u0131 ve bo\u015f ekranlar. Bu durum, sadece konferans kat\u0131l\u0131mc\u0131lar\u0131n\u0131 de\u011fil, d\u00fcnyan\u0131n d\u00f6rt bir yan\u0131ndaki geli\u015ftiricileri ve i\u015fletmeleri de etkiledi. Benim de i\u00e7inde bulundu\u011fum bir geli\u015ftirme ekibi, tam da kritik bir \u00f6zellik \u00fczerinde \u00e7al\u0131\u015f\u0131yordu ve o g\u00fcn deploy etmemiz gerekiyordu. Org’umuza eri\u015fimimiz olmad\u0131\u011f\u0131 i\u00e7in, t\u00fcm planlar\u0131m\u0131z alt\u00fcst olmu\u015ftu. Bu beklenmedik kesinti, teknolojiye olan ba\u011f\u0131ml\u0131l\u0131\u011f\u0131m\u0131z\u0131n ne kadar k\u0131r\u0131lgan olabilece\u011fini ac\u0131 bir \u015fekilde hat\u0131rlatt\u0131. Geli\u015ftirme s\u00fcre\u00e7lerimizin sadece teknoloji sa\u011flay\u0131c\u0131s\u0131n\u0131n altyap\u0131s\u0131na de\u011fil, ayn\u0131 zamanda o altyap\u0131n\u0131n eri\u015filebilirli\u011fine de ba\u011fl\u0131 oldu\u011funu g\u00f6rm\u00fc\u015f olduk. Bu t\u00fcr durumlar, i\u015f s\u00fcreklili\u011fi planlar\u0131n\u0131n ne kadar hayati oldu\u011funu vurguluyor.<\/p>\n
Kesintinin ya\u015fand\u0131\u011f\u0131 ilk anlarda panik havas\u0131 hakimdi. Ancak, bu durumun ge\u00e7ici olaca\u011f\u0131n\u0131 umarak, alternatif yollar aramaya ba\u015flad\u0131k. Temel sorunumuz, Apex kodlar\u0131m\u0131z\u0131 yaz\u0131p test edebilece\u011fimiz bir ortam\u0131n olmamas\u0131yd\u0131. Mevcut durumda, kodlar\u0131m\u0131z\u0131 do\u011frudan Salesforce org’umuzda yaz\u0131yor ve anonim Apex sayfas\u0131nda veya Developer Console’da \u00e7al\u0131\u015ft\u0131r\u0131yorduk. Bu, kesinlikle offline geli\u015ftirme i\u00e7in uygun bir y\u00f6ntem de\u011fildi. Bu noktada, Salesforce DX (SFDX) CLI’nin potansiyelini hat\u0131rlad\u0131k. SFDX, meta verileri yerel bir dosya sistemine \u00e7ekme ve buradan tekrar org’a deploy etme yetene\u011fine sahipti. Bu, bize bir nebze olsun umut verdi. \u0130lk ad\u0131m olarak, SFDX CLI’yi kullanarak mevcut projemizin meta verilerini yerel makinemize \u00e7ektik. Bu, kodlar\u0131m\u0131z\u0131n, trigger’lar\u0131m\u0131z\u0131n, Visualforce sayfalar\u0131m\u0131z\u0131n ve di\u011fer t\u00fcm bile\u015fenlerimizin yerel bir kopyas\u0131n\u0131 elde etmemizi sa\u011flad\u0131. Bu veriler, asl\u0131nda bir t\u00fcr “snapshot” (anl\u0131k g\u00f6r\u00fcnt\u00fc) idi ve bu sayede \u00fczerinde \u00e7al\u0131\u015fmaya devam edebilirdik. Ancak, bu sadece ba\u015flang\u0131\u00e7t\u0131; kodu \u00e7al\u0131\u015ft\u0131rmak ve test etmek hala b\u00fcy\u00fck bir sorundu.<\/p>\n
SFDX CLI, yerel geli\u015ftirme ortamlar\u0131 kurmam\u0131z i\u00e7in bize g\u00fc\u00e7l\u00fc bir ara\u00e7 seti sunar. Kesinti s\u0131ras\u0131nda, SFDX CLI’yi kullanarak mevcut projemizin meta verilerini yerel makinemize \u00e7ektik. Bu, asl\u0131nda projemizin bir yede\u011fini almak gibiydi. A\u015fa\u011f\u0131daki komut, bu i\u015flemi ger\u00e7ekle\u015ftirmemizi sa\u011flad\u0131:<\/p>\n
sfdx force:source:pull --forceoverwriteusername<\/code><\/pre>\n<\/p><\/div>\nBu komut, varsay\u0131lan olarak ba\u011fl\u0131 oldu\u011fumuz org’dan t\u00fcm kaynaklar\u0131 (apex s\u0131n\u0131flar\u0131, trigger’lar, lightning bile\u015fenleri vb.) yerel dosya sistemimize \u00e7eker. Bu, kodlar\u0131m\u0131z\u0131n ve di\u011fer meta verilerimizin yerel bir kopyas\u0131na sahip olmam\u0131z\u0131 sa\u011flad\u0131. Art\u0131k kodlar\u0131m\u0131z\u0131 bir metin edit\u00f6r\u00fcnde (\u00f6rne\u011fin, VS Code) a\u00e7\u0131p inceleyebilir ve d\u00fczenleyebilirdik. Ancak, bu sadece kodlar\u0131 g\u00f6rmemizi sa\u011fl\u0131yordu; onlar\u0131 \u00e7al\u0131\u015ft\u0131ram\u0131yorduk. Apex kodlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rmak i\u00e7in bir Salesforce org’una ihtiyac\u0131m\u0131z vard\u0131. Bu noktada, “scratch org” (\u00e7izik org) kavram\u0131 devreye girdi. SFDX, ge\u00e7ici, bulut tabanl\u0131 org’lar olu\u015fturmam\u0131za olanak tan\u0131r. Bu org’lar, belirli bir s\u00fcre sonra otomatik olarak silinirler. Kesinti s\u0131ras\u0131nda, bu scratch org’lar\u0131 kullanarak kodlar\u0131m\u0131z\u0131 test etme imkan\u0131m\u0131z olmasa da, kodlar\u0131m\u0131z\u0131 yerel olarak derleyip olas\u0131 s\u00f6zdizimi hatalar\u0131n\u0131 yakalayabilirdik.<\/p>\n
Apex Kodunu Lokal Olarak Derleme ve Hata Ay\u0131klama<\/h2>\n
Salesforce org’una eri\u015fimimiz olmad\u0131\u011f\u0131nda, Apex kodlar\u0131m\u0131z\u0131 lokal olarak derlemek, olas\u0131 s\u00f6zdizimi hatalar\u0131n\u0131 ve temel mant\u0131k sorunlar\u0131n\u0131 erken a\u015famada yakalamam\u0131za yard\u0131mc\u0131 oldu. SFDX CLI, bu konuda bize bir \u00e7\u00f6z\u00fcm sundu. Yerel makinemize \u00e7ekti\u011fimiz meta verileri kullanarak, SFDX’in yerel derleme yeteneklerini devreye soktuk. Bu, tam bir org’da \u00e7al\u0131\u015fan derleyicinin yapt\u0131\u011f\u0131 gibi, Apex kodlar\u0131m\u0131z\u0131 ayr\u0131\u015ft\u0131r\u0131p (parse) ve s\u00f6zdizimsel olarak do\u011fru olup olmad\u0131\u011f\u0131n\u0131 kontrol etmemizi sa\u011flad\u0131. Bu s\u00fcre\u00e7, \u00f6zellikle karma\u015f\u0131k ve uzun Apex s\u0131n\u0131flar\u0131 i\u00e7in zaman kazand\u0131r\u0131c\u0131 oldu. Hatalar\u0131, kodlar\u0131 org’a deploy etmeye \u00e7al\u0131\u015fmadan \u00f6nce tespit edebilmek, deploy s\u00fcre\u00e7lerindeki ba\u015far\u0131s\u0131zl\u0131k oran\u0131n\u0131 d\u00fc\u015f\u00fcrd\u00fc. \u00d6rne\u011fin, bir trigger’da veya bir Apex s\u0131n\u0131f\u0131nda yanl\u0131\u015f bir de\u011fi\u015fken ad\u0131, eksik bir noktal\u0131 virg\u00fcl veya hatal\u0131 bir parantez gibi basit s\u00f6zdizimi hatalar\u0131, yerel derleme s\u0131ras\u0131nda kolayca tespit edilebilirdi. Bu, \u00f6zellikle b\u00fcy\u00fck kod tabanlar\u0131nda, geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fc h\u0131zland\u0131rmak i\u00e7in kritikti. Kodlar\u0131m\u0131z\u0131 lokal olarak derleyebilmek, ayn\u0131 zamanda kod kalitesini art\u0131rmaya da yard\u0131mc\u0131 oldu. \u00c7\u00fcnk\u00fc geli\u015ftiriciler, herhangi bir org ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 olmadan, kodlar\u0131n\u0131 daha rahat bir \u015fekilde g\u00f6zden ge\u00e7irebilir ve iyile\u015ftirebilirlerdi.<\/p>\n
Lokal Derleme Ara\u00e7lar\u0131 ve Teknikleri<\/h3>\n
SFDX CLI, yerel derleme i\u015flemleri i\u00e7in temel ara\u00e7lar\u0131 sa\u011flar. sfdx force:source:deploy<\/code> komutu, meta verileri bir org’a deploy etmek i\u00e7in kullan\u0131l\u0131r. Ancak, bu komutun \u00e7al\u0131\u015fabilmesi i\u00e7in bir org’a ba\u011fl\u0131 olmam\u0131z gerekir. Bizim durumumuzda, org’a eri\u015fimimiz yoktu. Bu nedenle, yerel derleme i\u00e7in daha derinlemesine bir yakla\u015f\u0131m izlememiz gerekti. SFDX’in alt\u0131nda yatan teknolojiler, Apex derleyicisini lokal olarak \u00e7al\u0131\u015ft\u0131rmam\u0131za olanak tan\u0131r. Bu, genellikle bir IDE (Integrated Development Environment – Entegre Geli\u015ftirme Ortam\u0131) eklentisi arac\u0131l\u0131\u011f\u0131yla veya do\u011frudan SFDX CLI komutlar\u0131 arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r. \u00d6rne\u011fin, Visual Studio Code’da Salesforce uzant\u0131s\u0131, Apex kodlar\u0131n\u0131 yazarken ger\u00e7ek zamanl\u0131 olarak s\u00f6zdizimi hatalar\u0131n\u0131 vurgular. Bu, kodlar\u0131m\u0131z\u0131 kaydetti\u011fimiz anda olas\u0131 sorunlar\u0131 g\u00f6rmemizi sa\u011flar. Daha sonra, SFDX CLI’yi kullanarak meta verilerimizi belirli bir org’a (e\u011fer eri\u015fimimiz olsayd\u0131) veya bir “scratch org”a deploy etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131zda, arka planda Apex derleyicisi \u00e7al\u0131\u015f\u0131r ve herhangi bir hatay\u0131 raporlar. Kesinti s\u0131ras\u0131nda, bu derleme i\u015flemini do\u011frudan SFDX CLI ile tetikleyebilecek komutlar\u0131 ara\u015ft\u0131rd\u0131k. Bu, genellikle sfdx force:apex:compile<\/code> gibi komutlar veya SFDX’in daha geli\u015fmi\u015f meta veri i\u015fleme yetenekleri arac\u0131l\u0131\u011f\u0131yla ger\u00e7ekle\u015ftirilebilir. Bu ara\u00e7lar, Apex kodlar\u0131m\u0131z\u0131 derlemek, olas\u0131 hatalar\u0131 yakalamak ve kodun yap\u0131s\u0131n\u0131 analiz etmek i\u00e7in bize imkan sa\u011flad\u0131. Bu teknik, tam bir org’a ba\u011fl\u0131 olmadan kodun temel do\u011frulu\u011funu sa\u011flamak i\u00e7in hayati \u00f6nem ta\u015f\u0131yordu.<\/p>\nMock Servisler ve Stub’lar ile Test Stratejileri<\/h2>\n
Apex kodlar\u0131m\u0131z\u0131n sadece s\u00f6zdizimsel olarak do\u011fru olmas\u0131 yeterli de\u011fildi; ayn\u0131 zamanda i\u015f mant\u0131\u011f\u0131n\u0131 da do\u011fru bir \u015fekilde yerine getirmesi gerekiyordu. Ancak, d\u0131\u015f sistemlere veya di\u011fer Salesforce mod\u00fcllerine ba\u011f\u0131ml\u0131 olan kodlar\u0131m\u0131z\u0131, org’a eri\u015fimimiz olmadan test etmek imkans\u0131zd\u0131. Bu noktada, mock servisler ve stub’lar (sahte hizmetler ve taklitler) devreye girdi. Mock servisler, harici bir sistemin veya bir Salesforce bile\u015feninin davran\u0131\u015f\u0131n\u0131 taklit eden sahte yan\u0131tlar \u00fcreten yap\u0131lard\u0131r. Stub’lar ise, belirli bir fonksiyonun veya metotun beklenen \u00e7\u0131kt\u0131s\u0131n\u0131 d\u00f6nd\u00fcren basit kod par\u00e7ac\u0131klar\u0131d\u0131r. Bu teknikleri kullanarak, ba\u011f\u0131ml\u0131 oldu\u011fumuz bile\u015fenlerin yoklu\u011funda bile kodlar\u0131m\u0131z\u0131n belirli k\u0131s\u0131mlar\u0131n\u0131 izole edip test edebildik. \u00d6rne\u011fin, bir Apex s\u0131n\u0131f\u0131, harici bir REST API’ye istek g\u00f6nderiyorsa, bu API’nin yan\u0131t\u0131n\u0131 taklit eden bir mock servis olu\u015fturabilirdik. Bu mock servis, API’nin normalde d\u00f6nd\u00fcrece\u011fi JSON yan\u0131t\u0131n\u0131 d\u00f6nd\u00fcr\u00fcrd\u00fc. B\u00f6ylece, Apex s\u0131n\u0131f\u0131m\u0131z bu yan\u0131t\u0131 al\u0131p i\u015fleyebilir ve do\u011fru davran\u0131p davranmad\u0131\u011f\u0131n\u0131 kontrol edebilirdik. Bu yakla\u015f\u0131m, \u00f6zellikle entegrasyon testleri i\u00e7in \u00e7ok de\u011ferliydi. Kesinti s\u0131ras\u0131nda, bu mock servisleri yerel olarak \u00e7al\u0131\u015ft\u0131rd\u0131k ve Apex kodlar\u0131m\u0131z\u0131 bu sahte ortamda test ettik. Bu, kodlar\u0131m\u0131z\u0131n deploy edildi\u011finde \u00e7al\u0131\u015faca\u011f\u0131na dair bize daha fazla g\u00fcven verdi.<\/p>\n
Vaka Analizi: Harici Bir API Entegrasyonu<\/h3>\n
Ekibimiz, bir m\u00fc\u015fteri ili\u015fkileri y\u00f6netim (CRM) platformundan gelen verileri Salesforce’a entegre eden bir Apex s\u0131n\u0131f\u0131 \u00fczerinde \u00e7al\u0131\u015f\u0131yordu. Bu Apex s\u0131n\u0131f\u0131, harici CRM platformunun API’sine istek g\u00f6nderiyor, yan\u0131t\u0131 al\u0131yor ve bu verileri Salesforce’ta ilgili kay\u0131tlara (\u00f6rne\u011fin, Hesaplar, Ki\u015filer) g\u00fcncelliyordu. Dreamforce kesintisi s\u0131ras\u0131nda, bu entegrasyonun kritik bir b\u00f6l\u00fcm\u00fcn\u00fc deploy etmemiz gerekiyordu. Ancak, harici CRM API’sine eri\u015fimimiz yoktu. Bu durumu a\u015fmak i\u00e7in, bu harici API’nin beklenen yan\u0131tlar\u0131n\u0131 taklit eden bir mock servis olu\u015fturduk. Bu mock servis, belirli senaryolar i\u00e7in (\u00f6rne\u011fin, ba\u015far\u0131l\u0131 veri al\u0131m\u0131, veri bulunamamas\u0131, API hatas\u0131) \u00f6nceden tan\u0131mlanm\u0131\u015f JSON yan\u0131tlar\u0131 d\u00f6nd\u00fcr\u00fcyordu. Ard\u0131ndan, Apex entegrasyon s\u0131n\u0131f\u0131m\u0131z\u0131 bu mock servisi kullanacak \u015fekilde g\u00fcncelledik. Bu g\u00fcncelleme, Apex s\u0131n\u0131f\u0131m\u0131z\u0131n HttpRequest<\/code> ve HttpResponse<\/code> nesnelerini do\u011frudan harici API’ye g\u00f6ndermek yerine, bizim olu\u015fturdu\u011fumuz mock servis arac\u0131l\u0131\u011f\u0131yla sahte istekler yapmas\u0131n\u0131 sa\u011flad\u0131. Bu sayede, Apex s\u0131n\u0131f\u0131m\u0131z\u0131n veriyi do\u011fru \u015fekilde ayr\u0131\u015ft\u0131r\u0131p ayr\u0131\u015ft\u0131ramad\u0131\u011f\u0131n\u0131, hata durumlar\u0131n\u0131 do\u011fru y\u00f6netip y\u00f6netemedi\u011fini ve veriyi Salesforce’ta do\u011fru \u015fekilde g\u00fcncelleyip g\u00fcncelleyemedi\u011fini test edebildik. Bu vaka analizi, karma\u015f\u0131k entegrasyon senaryolar\u0131nda bile, ba\u011f\u0131ml\u0131 sistemlere eri\u015fimimiz olmasa bile test s\u00fcre\u00e7lerini nas\u0131l s\u00fcrd\u00fcrebilece\u011fimizi g\u00f6sterdi. Bu yakla\u015f\u0131m, sadece kesintilerde de\u011fil, ayn\u0131 zamanda geli\u015ftirme s\u00fcrecinin erken a\u015famalar\u0131nda da maliyetleri d\u00fc\u015f\u00fcrmek ve geli\u015ftirme h\u0131z\u0131n\u0131 art\u0131rmak i\u00e7in kullan\u0131labilir.<\/p>\nKod Depolar\u0131 ve S\u00fcr\u00fcm Kontrol\u00fcn\u00fcn \u00d6nemi<\/h2>\n
Bu t\u00fcr beklenmedik kesintilerde, kodlar\u0131m\u0131z\u0131n g\u00fcvenli bir yerde sakland\u0131\u011f\u0131ndan emin olmak kritik \u00f6nem ta\u015f\u0131r. Git gibi s\u00fcr\u00fcm kontrol sistemleri (version control systems), kodlar\u0131m\u0131z\u0131n ge\u00e7mi\u015fini takip etmemizi, farkl\u0131 s\u00fcr\u00fcmler aras\u0131nda ge\u00e7i\u015f yapmam\u0131z\u0131 ve ekip \u00fcyeleriyle i\u015fbirli\u011fi yapmam\u0131z\u0131 sa\u011flar. Dreamforce 2026 kesintisi s\u0131ras\u0131nda, GitHub’daki kod depomuz bizim i\u00e7in bir kurtar\u0131c\u0131 oldu. T\u00fcm Apex kodlar\u0131m\u0131z, trigger’lar\u0131m\u0131z ve di\u011fer meta verilerimiz, Git arac\u0131l\u0131\u011f\u0131yla depomuzda saklan\u0131yordu. Bu sayede, Salesforce org’umuza eri\u015fimimiz olmasa bile, kodlar\u0131m\u0131z\u0131n en son s\u00fcr\u00fcmlerine eri\u015febiliyorduk. Bu, offline geli\u015ftirme ve test s\u00fcre\u00e7lerimizi ba\u015flatmam\u0131z i\u00e7in temel bir ad\u0131md\u0131. Kodlar\u0131m\u0131z\u0131 yerel makinemize \u00e7ektikten sonra, Git’in sundu\u011fu dallanma (branching) ve birle\u015ftirme (merging) \u00f6zelliklerini kullanarak yeni \u00f6zellikleri geli\u015ftirebildik. Bu \u00f6zellikler, ana kod taban\u0131n\u0131 bozmadan yeni i\u015flevsellikleri izole etmemize olanak tan\u0131d\u0131. Daha sonra, Salesforce org’umuz tekrar eri\u015filebilir hale geldi\u011finde, bu de\u011fi\u015fiklikleri kolayca ana dala birle\u015ftirebildik. S\u00fcr\u00fcm kontrol\u00fc, sadece bir yedekleme mekanizmas\u0131 olman\u0131n \u00f6tesinde, bir i\u015fbirli\u011fi arac\u0131d\u0131r ve bu t\u00fcr kriz anlar\u0131nda geli\u015ftirme s\u00fcrecinin kesintisiz devam etmesini sa\u011flamak i\u00e7in vazge\u00e7ilmezdir. Kodlar\u0131m\u0131z\u0131n g\u00fcvende olmas\u0131, herhangi bir teknolojik aksakl\u0131kta h\u0131zl\u0131ca toparlanmam\u0131z\u0131 sa\u011flar.<\/p>\n
Git ve CI\/CD Pipeline’lar\u0131 ile Otomatikle\u015ftirilmi\u015f Da\u011f\u0131t\u0131m<\/h3>\n
Git gibi s\u00fcr\u00fcm kontrol sistemleri, CI\/CD (Continuous Integration\/Continuous Deployment – S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) pipeline’lar\u0131n\u0131n temelini olu\u015fturur. Kesinti s\u0131ras\u0131nda, CI\/CD pipeline’lar\u0131m\u0131z\u0131n devreye girip giremeyece\u011fi \u00f6nemli bir soruydu. E\u011fer CI\/CD sunucular\u0131m\u0131z ve ba\u011f\u0131ml\u0131 servislerimiz (\u00f6rne\u011fin, bulut tabanl\u0131 build ara\u00e7lar\u0131, test ortamlar\u0131) eri\u015filebilir durumdaysa, kod da\u011f\u0131t\u0131m s\u00fcre\u00e7lerimiz devam edebilirdi. Bizim senaryomuzda, CI\/CD platformumuz bulut tabanl\u0131yd\u0131 ve Salesforce kesintisinden do\u011frudan etkilenmedi. Bu, Git’te bir kod de\u011fi\u015fikli\u011fi yap\u0131ld\u0131\u011f\u0131nda veya bir “pull request” (\u00e7ekme iste\u011fi) olu\u015fturuldu\u011funda, CI\/CD pipeline’\u0131n\u0131n otomatik olarak tetiklenmesini ve kodun otomatik olarak derlenip test edilmesini sa\u011flad\u0131. Hatta, e\u011fer bir test ortam\u0131 (\u00f6rne\u011fin, bir “scratch org” veya ayr\u0131 bir sandbox) mevcutsa, kodun bu ortama otomatik olarak deploy edilmesi bile m\u00fcmk\u00fcnd\u00fc. Bu, kesinti s\u0131ras\u0131nda bile, geli\u015ftirme ve test s\u00fcre\u00e7lerinin \u00f6nemli bir k\u0131sm\u0131n\u0131n otomatik olarak devam etmesini sa\u011flad\u0131. Bu, geli\u015ftirme h\u0131z\u0131m\u0131z\u0131 ve verimlili\u011fimizi korumam\u0131za yard\u0131mc\u0131 oldu. CI\/CD’nin g\u00fcc\u00fc, bu t\u00fcr beklenmedik olaylarda kendini daha net g\u00f6steriyor. Otomatikle\u015ftirilmi\u015f s\u00fcre\u00e7ler, insan m\u00fcdahalesini azalt\u0131r ve hatalar\u0131n daha h\u0131zl\u0131 tespit edilip d\u00fczeltilmesini sa\u011flar.<\/p>\n
Kesintiden \u00c7\u0131kar\u0131lan Dersler ve Gelece\u011fe Y\u00f6nelik Stratejiler<\/h2>\n
Dreamforce 2026’daki bu beklenmedik kesinti, bize \u00f6nemli dersler \u00f6\u011fretti. Birincisi, tek bir hata noktas\u0131na (single point of failure) ba\u011f\u0131ml\u0131 olman\u0131n riskleri. Salesforce platformu ne kadar g\u00fcvenilir olursa olsun, her zaman kesintilere kar\u015f\u0131 savunmas\u0131zd\u0131r. Bu nedenle, geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerimizi \u00e7e\u015fitlendirmemiz gerekiyor. \u0130kincisi, offline geli\u015ftirme yeteneklerinin \u00f6nemi. SFDX ve CI\/CD gibi ara\u00e7lar, bu konuda bize yard\u0131mc\u0131 oldu. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, etkili s\u00fcr\u00fcm kontrol\u00fc ve otomatikle\u015ftirilmi\u015f testlerin vazge\u00e7ilmezli\u011fi. Bu ara\u00e7lar, kriz anlar\u0131nda bile geli\u015ftirme s\u00fcrecini devam ettirmemizi sa\u011flad\u0131. Gelecekte, bu deneyimlerden yola \u00e7\u0131karak, daha dayan\u0131kl\u0131 ve esnek geli\u015ftirme stratejileri benimsemeye devam edece\u011fiz. Bu, yerel geli\u015ftirme ortamlar\u0131n\u0131 daha fazla kullanmay\u0131, kapsaml\u0131 mock servisler ve stub’lar olu\u015fturmay\u0131 ve CI\/CD pipeline’lar\u0131m\u0131z\u0131 daha da g\u00fc\u00e7lendirmeyi i\u00e7eriyor. Ayr\u0131ca, Salesforce d\u0131\u015f\u0131ndaki di\u011fer platformlarla entegrasyonlar\u0131m\u0131z\u0131 tasarlarken, olas\u0131 kesintilere kar\u015f\u0131 daha diren\u00e7li olacak \u015fekilde tasarlamal\u0131y\u0131z. Bu, asenkron ileti\u015fim modellerini benimsemek, hata toleransl\u0131 (fault-tolerant) tasar\u0131mlar yapmak ve kapsaml\u0131 bir i\u015f s\u00fcreklili\u011fi plan\u0131na sahip olmak anlam\u0131na gelir. Bu dersler, sadece Salesforce geli\u015ftiricileri i\u00e7in de\u011fil, herhangi bir bulut tabanl\u0131 platform \u00fczerinde \u00e7al\u0131\u015fan t\u00fcm geli\u015ftiriciler i\u00e7in ge\u00e7erlidir.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n\n- \n S: Salesforce kesintisi s\u0131ras\u0131nda Apex kodlar\u0131m\u0131 nas\u0131l test edebilirim?<\/strong><\/p>\n
C: Mock servisler ve stub’lar kullanarak harici ba\u011f\u0131ml\u0131l\u0131klar\u0131 taklit edebilir ve yerel test \u00e7er\u00e7eveleriyle kodunuzu izole bir \u015fekilde test edebilirsiniz. SFDX CLI’nin sundu\u011fu yerel derleme yetenekleri de s\u00f6zdizimi hatalar\u0131n\u0131 yakalaman\u0131za yard\u0131mc\u0131 olur.<\/p>\n<\/li>\n
- \n S: Salesforce DX (SFDX) tam olarak ne i\u015fe yarar ve kesinti s\u0131ras\u0131nda nas\u0131l yard\u0131mc\u0131 olur?<\/strong><\/p>\n
C: SFDX, geli\u015ftiricilerin meta verileri yerel olarak y\u00f6netmelerine, scratch org’lar olu\u015fturmalar\u0131na ve kodlar\u0131 CI\/CD pipeline’lar\u0131 arac\u0131l\u0131\u011f\u0131yla da\u011f\u0131tmalar\u0131na olanak tan\u0131r. Kesinti s\u0131ras\u0131nda, meta verileri yerel olarak \u00e7ekip \u00fczerinde \u00e7al\u0131\u015fmaya devam etmenizi ve kodunuzu offline olarak derlemenizi sa\u011flar.<\/p>\n<\/li>\n
- \n S: CI\/CD pipeline’lar\u0131 Salesforce kesintilerinden nas\u0131l etkilenir?<\/strong><\/p>\n
C: E\u011fer CI\/CD sunucular\u0131n\u0131z ve ba\u011f\u0131ml\u0131 servisleriniz Salesforce d\u0131\u015f\u0131ndaysa, kesintiden do\u011frudan etkilenmeyebilirler. Bu, kod da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinin otomatik olarak devam etmesini sa\u011flayabilir.<\/p>\n<\/li>\n
- \n S: Kodlar\u0131m\u0131 Git’te saklamak, Salesforce kesintilerinde ne gibi bir avantaj sa\u011flar?<\/strong><\/p>\n
C: Git, kodlar\u0131n\u0131z\u0131n g\u00fcvenli bir kopyas\u0131n\u0131 tutar ve ge\u00e7mi\u015f s\u00fcr\u00fcmleri y\u00f6netmenizi sa\u011flar. Kesinti s\u0131ras\u0131nda, kodlar\u0131n\u0131za eri\u015fmenizi ve offline geli\u015ftirmeye devam etmenizi m\u00fcmk\u00fcn k\u0131lar.<\/p>\n<\/li>\n
- \n S: Offline Apex geli\u015ftirme i\u00e7in en iyi pratikler nelerdir?<\/strong><\/p>\n
C: SFDX CLI’yi etkin kullanmak, kapsaml\u0131 mock servisler olu\u015fturmak, s\u00fcr\u00fcm kontrol\u00fcn\u00fc d\u00fczenli kullanmak ve CI\/CD pipeline’lar\u0131n\u0131 otomatikle\u015ftirmek en iyi pratikler aras\u0131ndad\u0131r.<\/p>\n<\/li>\n<\/ul>\n
#Salesforce #Apex #Dreamforce #Geli\u015ftirme #Teknoloji #BulutBili\u015fim<\/p>\n