Commit'ten Üretime Lead Time Nasıl Azaltılır?

Birçok organizasyonda bir özellik canlıya çıkmadan günlerce kod-tamam halinde bekleyebilir; bir inceleme kuyruğunun, bir release train’in ya da kaçırdığı bir deploy slotunun arkasında takılı kalır. Bunu yakalayan metrik, değişiklikler için lead time’dır: bir değişikliğin commit edilmesinden üretimde çalışmasına kadar geçen süre; ve bu sürenin büyük kısmı programlama değil, süreçtir. Bir teknik liderin yapabileceği en faydalı hamle, lead time’ı birincil teslimat metriği olarak ele almak ve en büyük bekleme aşamasının üzerine yapısal olarak gitmektir. Sıra bellidir: parti boyutunu küçült, deploy ile release’i ayır, sonra güvenlik kapısını ve ekipler arası kapıyı kendi kendine işleyen guardrail’lere dönüştür.

Lead Time Saati#

Değişiklikler için lead time, “bir değişikliğin sürüm kontrolüne commit edilmesinden üretime deploy edilmesine kadar geçen süredir.” Saat kod-tamam noktasından başlar; ne inşa edileceğine karar verme süresini dışarıda bırakır. Bu çerçeveleme önemlidir çünkü bir teslimat sürecinin sahiplendiği kısmı yalıtır: “kod bitti” ile “kullanıcıların elinde” arasındaki bekleme.

Bu sürenin çoğu bekleme aşamasıdır. Bir değişiklik önce bir build/test kuyruğunda, sonra bir inceleme kuyruğunda, sonra bir güvenlik kapısında oturur; ardından bir release train’e toplanır, bir deploy penceresi bekler ve bazen önce başka bir ekibin deploy etmesini bekler. Aşağıdaki diyagram bu beklemeleri adlandırıyor; sonraki bölümler her birini tek tek ele alıyor.

Bu saati kısaltmanın dayanağı, DORA araştırma programının en kalıcı bulgusudur: hız ve istikrar bir trade-off değildir. On yılı aşkın süredir veriler şunu gösteriyor: “performansı iyileştirmek ile daha yüksek istikrar ve kalite seviyelerine ulaşmak arasında bir trade-off yoktur. Aksine, yüksek performanslılar her ikisinde de daha iyidir.” Bu sonuç 2015 analizinden bu yana geçerliliğini koruyor; yani lead time için optimize etmek daha fazla kesinti kabul etmek anlamına gelmez, aynı yapısal seçimler her ikisini birden iyileştirme eğilimindedir.

Hedefleri, onları zamansız bir yasa gibi ele almadan somutlaştırmak yardımcı olur. 2024 State of DevOps raporunda elite küme talep üzerine deploy eder; lead time bir günden az, değişiklik başarısızlık oranı yaklaşık %5 ve başarısız deploy kurtarma süresi bir saatten azdır; elite katılımcıların kabaca %19’uydu ve lead time’ı low kümesininkinden yaklaşık 127 kat daha hızlıydı. İki uyarı geçerli. Birincisi, bu bantlar DORA’nın her rapor yılında yeniden türettiği, katılımcıların kendi beyanına dayalı kümelerdir; yani sabit eşikler değildir (2022 raporunda yalnızca üç küme vardı ve elite katmanı yoktu). Herhangi bir bandı rapor yılına bağlayın. İkincisi, bir günden az rakamı lead time hedefidir; bir saatten az rakamı kurtarmadır. Bunlar farklı metriklerdir ve birbirine karıştırılması kolaydır.

Eski materyallerde geçtiği için bir adlandırma notu: bilinen “dört temel metrik” artık beştir. Dördüncü metrik 2023’te ortalama onarım süresinden (MTTR) başarısız deploy kurtarma süresine yeniden adlandırıldı ve model 2024’te genişledi. Fikirler sabit; etiketler değişiyor.

Küçük Partiler ve Sıkıcı Deploy#

İlk kaldıraç parti boyutudur, çünkü aşağıdaki her şeye bir tavan koyar. Küçük bir değişiklik build/test kuyruğunu daha hızlı geçer, daha hızlı incelenir ve başarısız olursa daha küçük bir etki alanı taşır. DORA temel ilkeyi doğrudan ifade eder: “teslimat sürecini hızlı ve istikrarlı kılmak için her değişikliği mümkün olduğunca küçük yapın,” ve deploy sıklığını parti boyutu için bir vekil olarak ele alır. Dolayısıyla hedef, o kadar rutin bir deploydur ki bir olay bile değildir.

Trunk-based development, küçük partileri varsayılan kılan iş akışıdır. Geliştiriciler tek bir dal üzerinde, trunk üzerinde işbirliği yapar ve uzun ömürlü feature dallarına direnir; release dalları, trunk deploy edilebilir kalsın diye tam zamanında kesilir. Zor durum, tek bir küçük commit’e sığmayan büyük bir refactor’dur. Branch by Abstraction bunu çözer: bir soyutlama katmanı ekle, çağıranları onun arkasında kademeli olarak taşı ve trunk’ı baştan sona gönderilebilir tut.

Aşağıdaki tablo, bir teknik liderin gerçekten tarttığı boyutlar üzerinden iki düzeni karşılaştırıyor.

Boyut	Küçük partiler (trunk-based)	Toplu release train
Lead time	Kısa; her değişiklik kendi başına akar	Uzun; değişiklik treni bekler
Etki alanı	Küçük; deploy başına bir değişiklik	Büyük; bir haftalık değişiklik birlikte çıkar
Deploy sıklığı	Yüksek; deploylar rutinleşir	Düşük; deploylar nadir ve yüksek riskli kalır
Geri alma maliyeti	Ucuz; tek değişikliği geri al	Pahalı; suçluyu bulmak için demeti çöz

Bir çekince: 2024 raporu ilk kez, medium kümesinin high kümesinden daha düşük bir değişiklik başarısızlık oranına sahip olduğunu buldu; DORA’nın kendisi bunu “olağandışı” olarak işaretledi. Elite’ten low’a temiz eğim hâlâ geçerlidir; bu yüzden hızdaki her adımın her küme çifti boyunca değişiklik başarısızlık oranını azalttığını fazla iddia etmeyin. Savunulabilir iddia kalıcı olandır: küçük partiler teslimat sürecini daha hızlı ve daha istikrarlı yapar, bir sonraki kaldıracı da mümkün kılar.

Release’i Deployment’tan Ayırmak#

Küçük partilerle bile, kodu deploy etmek onu kullanıcılara açma eylemiyle aynı kaldığı sürece bir deploy riskli kalır. İkinci kaldıraç bu iki olayı ayırır. Kod üretime karanlıkta, bir flag’in arkasında çıkar; davranışı release penceresinden bağımsız olarak bir flag çevirmesi açar. Pete Hodgson’ın anlatımında bu, “release’i deployment’tan ayırma şeklindeki Continuous Delivery ilkesini uygulamanın en yaygın yoludur”: release toggle’ları “tamamlanmamış ve test edilmemiş kod yollarını … gizli kod olarak” göndermenize izin verir.

Deploy ve release ayrıldıktan sonra release’in kendisi de toptan olmak yerine kademeli ilerleyebilir. Dark launching, yeni arka uç davranışını mevcut kullanıcılar için “kullanıcılar fark edemeden” çağırır; bu da bir arayüz değişikliğini kimse görmeden önce üretimde yük testi yapmanıza olanak tanır. Canary ve blue-green release’ler, önce trafiğin bir dilimine açarak etki alanını sınırlar. Bu ürünleştirilebilir: Argo Rollouts, bir AnalysisRun’ı bir AnalysisTemplate’e karşı çalıştırır ve bir canary’yi metrik eşiklerine göre otomatik terfi ettirir ya da otomatik durdurur; kimsenin bir panoyu izlemesi gerekmez. Bu aşamaları birbirine bağlayan somut pipeline (hangi kontrolün hangi CI tetikleyicisine ait olduğu) kendi kardeş yazısında: Hangi CI Adımı Hangi Tetikleyicide Çalışır.

Flag’ler bedava değildir; ekiplerin atladığı kısım da budur. Hodgson açıktır: “işini bilen ekipler kod tabanlarındaki Feature Toggle’ları, taşıma maliyeti olan bir envanter olarak görür” ve farklı toggle türleri farklı ele alış gerektirir. Dört kategori iki eksen üzerinde (ömür ve dinamiklik) sıralanır; yönetim sonucu ise her biri için farklıdır.

Toggle türü	Ömür	Dinamiklik	Yönetim sonucu
Release	Kısa	Statik (deploy anı)	Özellik tamamen açılır açılmaz emekliye ayır
Experiment	Kısa	Dinamik (istek başına)	Ömrü deneye bağla; sonuç çıkınca temizle
Ops	Uzun	Dinamik	Operatörlerce kill switch olarak sahiplenilir; düzenli gözden geçir
Permissioning	Uzun	Dinamik (kullanıcı başına)	Genellikle kalıcı bir ürün yeteneğidir; borç sayılmaz

Taşıma maliyeti gerçektir. Knight Capital’ın yaklaşık 460 milyon USD’lik işlem zararı, diğer şeylerin yanı sıra, yeniden kullanılan, emekliye ayrılmamış bir flag ile katlanan kötü giden bir deploy’un kanonik vakasıdır. Bu, yönetilmeyen flag envanteri hakkında bir uyarıdır; flag’lerin tehlikeli olduğunu kanıtlamaz. Çözüm bir son kullanma ve emeklilik sürecidir, ki yukarıdaki tablo da bunu desteklemek içindir.

Kuyruğa Sokmadan Güvenlik İncelemesi#

Zorunlu manuel bir güvenlik kapısı, lead time üzerindeki en yaygın gizli vergidir ve kaldırması en savunulabilir olandır; çünkü çözüm aynı zamanda güvenliği de iyileştirir. DORA, güvenlik inceleme süresini kasıtlı olarak azaltılacak bir lead time metriği olarak ele alır: “incelemenin eklediği süreyi” ölçün; bu süre “üzerinde anlaşılan bir asgariye ulaşana kadar azalmalı,” öyle ki “güvenlik inceleme süreci geliştirmeyi yavaşlatmasın.” Altta yatan ilke Deming’inkidir: “denetime bağımlılığa son verin … kaliteyi ürünün içine inşa edin” ve her değişikliği bir kişinin onayına bağlamak yerine denetçiler için “talep üzerine kanıt üretin.”

Yapısal olarak bu, birlikte çalışan üç şey demektir: pipeline’a sola kaydırılmış otomatik denetimler, tek tip bir kontrol listesi yerine riske dayalı yönlendirme ve güvenli yolu varsayılan kılan bir hazır yol (paved road). Kilit nokta yönlendirmedir, çünkü yüksek riskli manuel kapıyı gerçek riskten bağımsız olarak her değişikliğe uygulamak, kuyruğu yaratan şeydir.

Netflix bunu kapılar yerine guardrail’ler olarak çerçeveler: “varsayılan olarak güvenli merkezi platformlar” inşa edin çünkü “uygulama başına güvenlik değerlendirmeleri … ölçeklenmez”; “beyaz eldiven” insan incelemesini ise herkes yerine gerçekten yüksek riskli ekipler için saklayın. NIST’in Güvenli Yazılım Geliştirme Çerçevesi (SSDF), standart tarafından riske dayalı duruşu destekler: pratikleri “sonuç-odaklıdır” ve “SSDF’nin niyeti bir kontrol listesi oluşturmak değildir”; dört grupta (PO, PS, PW, RV) düzenlenmiştir. Otomasyonun da bir olgunluk merdiveni vardır. OWASP’ın DevSecOps Maturity Model’i seviye 2’de SAST, SCA ve DAST’ı otomatik raporlamayla CI’a koyar; seviye 3’te ise “pipeline’lar … önem eşiklerine göre başarısız olacak şekilde yapılandırılır”; böylece kapı build’in dayattığı bir eşik olur. Tedarik zinciri güvencesi de aynı şekilde kademeli olarak benimsenebilir: SLSA v1.2, build seviye 1’den (provenance) seviye 2’ye (barındırılan bir platformdan imzalı provenance) seviye 3’e (sertleştirilmiş bir platform) tırmanır; böylece bir ekip her şeyi yeniden inşa etmeden başlayabilir.

Karşı bulguyu da aynı araştırma veriyor; bu kaldıracın bir sınırı olmasının nedeni de bu. 2024 DORA raporu, bir iç geliştirici platformu benimsemenin kısa vadede azalan iş hacmi (yaklaşık %8) ve azalan istikrarla (yaklaşık %14) ilişkilendirildiğini buldu. DORA bu düşüşü özellikle güvenlik adımlarına değil, eklenen el değiştirmelere bağladı. Ders kesindir: bir guardrail lead time’ı yalnızca hazır yol gerçekten kendi kendine işlediğinde kısaltır. Yeni bir el değiştirme ekleyen yarım inşa edilmiş bir platform lead time’ı kötüleştirebilir. Bağımlılık otomasyonunun “yaklaşık %40 daha az açık” sağladığı yönündeki yaygın istatistiğin birincil bir kaynağı yok; belgelenmiş kazanımlar daha mütevazı. GitHub’ın Octoverse 2025’ine göre kritik düzeltmeler %30 daha hızlı, 37 günden 26 güne iniyor; kritik uyarılı depolarda %26 azalma var. Bu kaldıracın tam işlenişi, güvenlik incelemesini kritik yoldan çıkarma üzerine kardeş yazıda.

Tek Başına Deploy Etmenizi Sağlayan Sözleşmeler#

Bir servisteki bir değişiklik, onu tüketen herkesle koordineli bir deploy’u zorunlu kıldığında, ekipler arası bekleme lead time’daki baskın terim olur. Bağımsız deploy edilebilirlik bunun çaresidir ve temelde bir sözleşme sorunudur: bir servisi tüketicileriyle koordine olmadan değiştirip deploy edebiliyorsanız, ekipler arası gecikmenin en büyük kaynağını ortadan kaldırmışsınızdır. Sam Newman’ın Building Microservices’ta tarif ettiği disiplin yararlı bir hedeftir; kitabın testini özetlersek: bir servisi değiştirip başka hiçbir şeyi değiştirmek zorunda kalmadan üretime deploy edebiliyor musunuz?

Sizi oraya üç mekanizma götürür. Birincisi bir sürümleme sözleşmesidir. Semantic versioning uyumluluğu sayının kendisine kodlar: MAJOR uyumsuz bir değişikliği, MINOR geriye dönük uyumlu bir eklemeyi, PATCH geriye dönük uyumlu bir düzeltmeyi işaret eder; hepsi beyan edilmiş bir public API’ye görelidir. İkincisi Parallel Change’tir, genişlet-taşı-daralt olarak da bilinir. Arayüzü hem eskiyi hem yeniyi destekleyecek şekilde genişletirsiniz, tüketicileri kendi hızlarında taşırsınız, sonra eski yolu daraltıp kaldırırsınız; üretici tüketici taşımasını beklemeden deploy eder. Aynı disiplin veritabanlarına da uygulanır; burada “her migration, çalışmakta olan uygulama koduyla geriye dönük uyumlu olmalıdır.” Maliyet gerçektir: taşıma aşamasında her iki sürümü de bakımda tutarsınız ve daralt aşamasını terk etmek sizi kalıcı olarak daha kötü durumda bırakır.

Üçüncü mekanizma sözleşmeyi yürütülebilir kılar. Tüketici güdümlü sözleşme testi (consumer-driven contract testing) gizli bağımlılığı kaldırır: “mevcut tüketiciler tarafından kullanılmayan herhangi bir sağlayıcı davranışı, testleri bozmadan değişmekte serbesttir.” Pact (açık kaynak proje, Pact Broker’ıyla) her tüketicinin gerçekte neye ihtiyaç duyduğunu kaydeder; PactFlow ise SmartBear’ın ticari barındırılan broker’ıdır ve onun çift yönlü modu, tam tüketici güdümlü testten farklı ve daha zayıf bir denetimdir. Kazanç deploy kapısıdır. Pact dokümanlarının eski moda darboğaz olarak tarif ettiği “önceden test edilmiş uygulama setlerini birlikte deploy etme” yaklaşımı yerine, bir can-i-deploy denetimi sözleşme matrisini inceler ve bu sürümün belirli bir ortama güvenle çıkarılıp çıkarılamayacağını yanıtlar:

pact-broker can-i-deploy --pacticipant Orders --version 1.4.2 --to-environment production

Deploy edilebilirse sıfır çıkış kodu, engellenmesi gerekiyorsa sıfırdan farklı bir kod döndürür; böylece ekipler arası koordinasyon pipeline’da otomatik bir denetim olarak işler. İki komşu uygulama sözleşmeyi pekiştirir. Tolerant Reader, tüketici tarafında Postel Yasası’nı uygular, “yaptığında tutucu, kabul ettiğinde esnek ol”; böylece tüketiciler eklemelerde kırılmak yerine bilinmeyen alanları görmezden gelir. Olay güdümlü sistemler için bir schema registry, uyumluluk modlarıyla deploy sırasını belirler; Confluent’ın şemasında BACKWARD (varsayılanı) önce tüketicileri yükselt demektir, FORWARD önce üreticileri demektir, FULL ve TRANSITIVE daha katı seçeneklerdir; ve bir alan silme yalnızca alan opsiyonel ya da varsayılanlı olduğunda güvenlidir. Stripe’ın public API’si eklemeli, tarih tabanlı evrimin temiz bir örneğidir: major release’ler kırıcı değişiklik taşır, aylık release’ler ise yalnızca geriye dönük uyumludur ve “mevcut kodun hiçbirini bozmadan … yükseltmesi güvenlidir.” Bunun yanında sık gündeme gelen monorepo-polyrepo sorusunun yetkili bir cevabı yoktur; gerçek bir trade-off’tur.

Geri Alamayacağınız İstemci#

Mobil, önceki bölümlerin varsaydığı simetriyi bozar. Bir sunucu deploy’u saniyeler içinde geri alınabilir; gönderilen bir binary geri alınamaz. Mağaza incelemesi ekibin kontrolü dışındadır. Bir iPhone, kullanıcı tarafından eski sürüme döndürülemez. Eski istemci sürümleri de bir release’den sonra haftalar ila aylar boyunca sahada kalır; yani bir binary’deki herhangi bir hata, kullanıcılar güncelleyene kadar canlıdır. Apple’ın kendi rakamı, ekibin sahip olmadığı kapı için temel beklentiyi belirler: “ortalama olarak, gönderimlerin %90’ı 24 saatten kısa sürede incelenir,” geri kalan için birkaç günlük bir kuyrukla. Büyük bir mobil işletim sistemi çıktıktan aylar sonra bile yükleme tabanının yalnızca yaklaşık üçte ikisine ulaşır; eski istemcilerin basitçe yok olmamasının nedeni de bu.

Kaldıraç, ürün karar verme işinin binary’nin izin vereceği kadar çoğunu sunucu tarafına taşımaktır; böylece yavaş istemci release’i günlük değişiklikler için kritik yolda olmaz. Backends For Frontends deseni bu ayrım noktasıdır. Bir BFF, kullanıcı deneyimi başına bir arka uçtur ve arayüzü geliştiren ekibe aittir; bu da “hem istemci hem sunucu bileşenlerinin release’ini hizalamayı” basitleştirir; kural şudur: “bir deneyim, bir BFF.” BFF sunucu ritmiyle deploy ettiği için ekip, binary mağazanın daha yavaş ritminde güncellenirken davranışı onun arkasında günlük değiştirebilir.

Bu yelpazenin agresif ucu sunucu güdümlü arayüzdür (server-driven UI); veriye ek olarak yerleşimi ve eylemleri de sunucu ritmine taşır. Airbnb’nin Ghost Platform’u, iOS, Android ve web genelinde yerleşim ve eylemleri geriye dönük uyumlu bölümlerle düzenleyen “birleşik, görüş sahibi, sunucu güdümlü bir arayüz sistemidir.” Maliyet gerçektir ve açıkça söylemeye değer, çünkü bu bir tedarikçi deneyimidir ve evrensel bir öneri sayılmaz: sunucu güdümlü arayüz, kod tabanında, performansta ve hata ayıklamada eklenen karmaşıklığın yanı sıra kalıcı bir geriye dönük uyumluluk yükümlülüğü taşır. Spotify, sunucu güdümlü yerleşimler için bileşen güdümlü (component-driven) bir arayüz çerçevesi olan HubFramework’ü inşa etti ve daha sonra kullanımdan kaldırdı. En kötü istemcileri güncellemeye zorlamak için asgari sürüm kapısı ve kill switch’ler yaygın uygulamadır, ama zorunlu güncellemeyi bir ürün ve politika kararı olarak ele alın; platform bunu garanti etmez. Savunulabilir varsayılan daha dardır: BFF’e sahip ol, kararları sunucu tarafına it ve tam sunucu güdümlü arayüze yalnızca varyasyon oranı bu vergiyi haklı çıkardığında geç. Mobil durum, istemciyi geri alamadığınızda ship etme üzerine kendi kardeş yazısında ele alınıyor.

Varsayılan Ne Zaman Geçerli ve Ne Zaman Aşılır#

Ortak çizgi Team Topologies’tir: yukarıdaki her bekleme aşaması bir el değiştirmedir ve asıl iş, el değiştirmeleri kendi kendine işleyen akışa dönüştürmektir. Bir platform ekibi, güvenlik inceleme kuyruğunu, deploy adımını ve sözleşme matrisini, akış-hizalı ekiplerin kendilerinin işlettiği şeylere dönüştürür. Bunun özgün ifadesi Werner Vogels’ın “sen inşa edersin, sen çalıştırırsın” sözüdür. Continuous deployment’ın ölçeklendiği artık tartışma konusu değil: Google’ın monorepo’su “yazılım geliştiricilerinin %95’i tarafından kullanılır,” iş günü başına kabaca 16.000 insan kaynaklı ve 24.000 otomatik değişikliği işler. Meta’nın geçmişi de aynı seyri izler, ama iki pipeline’ı karıştırmamak gerekir: mobil release ritmi dört haftalık döngülerden haftalığa doğru sıkıştı, çalışanlar-%2-%100 şeklindeki kademeli açılım ise web akışına aittir.

Sınır, taşıma maliyetidir. Flag’ler envantere dönüşür ve bir emeklilik süreci gerektirir. Sözleşmeler taşıma aşamasında çift sürümlü bakım ekler. Bir hazır yol lead time’ı yalnızca gerçekten kendi kendine işlediğinde kısaltır; yarım inşa edilmiş bir platform bir el değiştirme ekler ve iş hacmini düşürebilir. Sunucu güdümlü arayüz kalıcı bir geriye dönük uyumluluk vergisi taşır. Bunların hiçbiri bedava değildir ve varsayılanı aşacağınız durumlar somuttur. Mobil asimetri, hangi kaldıracın öne geçtiğini değiştirir. Sınır denetimi ise, yani bir sonraki flag ya da sözleşme katmanının gerçekten kendi kendine işleyip işlemediğini sormak, yapı eklemeye ne zaman son verileceğine karar verir.

Sonraki adım ölçüm: commit’ten üretime giden saati enstrümante et, en büyük bekleme aşamasını bul ve ilk kaldıracı oraya yönelt.

Kaynaklar#

• DORA - A history of DORA’s software delivery metrics (yeni sekmede açılır) - 2015’teki ‘trade-off yok’ bulgusu, 2023’teki başarısız deploy kurtarma süresi yeniden adlandırması ve 2024 genişlemesi; bantların her yıl neden değiştiğine dair en iyi kaynak.
• Are you an Elite DevOps performer? - Google Cloud (Four Keys) (yeni sekmede açılır) - Sade metrik tanımları, commit’ten deploy’a lead time ölçümü ve 2022’nin üç küme kullandığı notu.
• Accelerate: The Science of Lean Software and DevOps (Forsgren, Humble, Kim) (yeni sekmede açılır) - “Hız ve istikrar bir trade-off değildir; yüksek performanslılar her ikisinde de daha iyidir” bulgusunun arkasındaki araştırma kitabı.
• DORA 2024 Accelerate State of DevOps Report (yeni sekmede açılır) - 2024 küme değerleri ve incelikleri, ayrıca platform mühendisliği iş hacmi ve istikrar karşı ağırlığı.
• Octopus - 2024 DevOps performance clusters (yeni sekmede açılır) - Burada kullanılan 2024 elite referans değerlerinin özeti.
• Trunk Based Development (yeni sekmede açılır) - Trunk’ı deploy edilebilir tutan tek-trunk disiplini ve tam zamanında release dalları.
• Branch by Abstraction - Martin Fowler (yeni sekmede açılır) - Büyük bir refactor sırasında trunk’ı deploy edilebilir tutmak.
• DORA - DORA metrics guide (yeni sekmede açılır) - Küçük parti ilkesi ve parti boyutu için vekil olarak deploy sıklığı.
• Feature Toggles (aka Feature Flags) - Pete Hodgson / Martin Fowler (yeni sekmede açılır) - Dört toggle kategorisi, release’i deployment’tan ayırma, taşıma maliyeti ve Knight Capital uyarısı.
• Dark Launching - Martin Fowler (yeni sekmede açılır) - Yeni davranışı mevcut kullanıcılar için sessizce çağırmak.
• Argo Rollouts - Analysis (yeni sekmede açılır) - AnalysisRun ve AnalysisTemplate ile ürünleştirilmiş metrik kapılı canary.
• DORA - Capabilities: Pervasive security (yeni sekmede açılır) - Güvenlik inceleme süresini bir lead time metriği olarak ele almak ve Deming’in “kaliteyi içine inşa et” argümanı.
• Scaling Appsec at Netflix - Netflix Technology Blog (yeni sekmede açılır) - Kapılar yerine guardrail’ler, varsayılan güvenli platformlar ve yüksek riskli ekipler için saklanan beyaz eldiven incelemesi.
• NIST Secure Software Development Framework (SSDF), SP 800-218 (yeni sekmede açılır) - Kontrol listesi yerine dört grupta (PO, PS, PW, RV) sonuç-odaklı, riske dayalı pratikler.
• OWASP DevSecOps Maturity Model (yeni sekmede açılır) - Olgunluk seviyesi 2 ve 3’te önem eşiğine dayalı pipeline kapıları.
• SLSA v1.2 - Build track basics (yeni sekmede açılır) - Kademeli olarak benimsenebilir tedarik zinciri build seviyeleri.
• Semantic Versioning 2.0.0 (yeni sekmede açılır) - MAJOR/MINOR/PATCH uyumluluk kuralları ve public API ön koşulu.
• Parallel Change - Martin Fowler / Danilo Sato (yeni sekmede açılır) - Toplu bir geçiş olmadan geriye dönük uyumsuz değişiklikler için genişlet, taşı ve daralt.
• Expand and Contract - Tim Wellhausen (yeni sekmede açılır) - Aynı disiplinin sıfır kesintili veritabanı şema migration’larına uygulanması.
• Can I Deploy - Pact Docs (yeni sekmede açılır) - Önceden test edilmiş uygulama setlerini birlikte deploy etmenin yerini alan matris ve can-i-deploy kapısı.
• Pact - Documentation (yeni sekmede açılır) - Tüketici güdümlü sözleşme testi: tüketicilerin kullanmadığı sağlayıcı davranışı değişmekte serbesttir.
• Tolerant Reader - Martin Fowler (yeni sekmede açılır) - Tüketici tarafında Postel Yasası: bilinmeyen alanları görmezden gel.
• Confluent - Schema evolution and compatibility (yeni sekmede açılır) - Deploy sırasını belirleyen BACKWARD, FORWARD, FULL ve TRANSITIVE uyumluluk modları.
• Stripe API versioning (yeni sekmede açılır) - Tarih tabanlı eklemeli evrim; major’a karşı geriye dönük uyumlu aylık release’ler.
• Building Microservices, 2nd ed. (Sam Newman) (yeni sekmede açılır) - Bağımsız deploy edilebilirlik testinin kaynağı.
• Apple - App Review (yeni sekmede açılır) - Güncel “ortalama 24 saatte %90” inceleme süresi rakamı.
• iOS adoption statistics - MacRumors (yeni sekmede açılır) - Büyük bir mobil işletim sisteminin yükleme tabanının yalnızca yaklaşık üçte ikisine ulaştığına dair kanıt.
• Backends For Frontends - Sam Newman (yeni sekmede açılır) - Arayüz ekibinin sahip olduğu, kullanıcı deneyimi başına bir arka uç olarak BFF; geri alınamayan istemciler için sunucu tarafındaki ayrım noktası.
• API Gateway pattern - Microservices.io (yeni sekmede açılır) - Her istemci türü için ayrı bir API gateway.
• A deep dive into Airbnb’s server-driven UI system - Airbnb Engineering (yeni sekmede açılır) - Geriye dönük uyumlu bölümlere sahip Ghost Platform sunucu güdümlü arayüz sistemi.
• Team Topologies - Martin Fowler (yeni sekmede açılır) - Akış-hizalı ekipler ve el değiştirmeleri kendi kendine işlemeye dönüştüren platform.
• You build it, you run it (Werner Vogels) - ACM Queue (yeni sekmede açılır) - İnşa-ettiğini-sen-çalıştır ilkesinin kökeni.
• New platform engineering research - Google Cloud (yeni sekmede açılır) - Platform olgunluğu ve pazara çıkış süresi üzerine tedarikçi destekli anket.
• Software Engineering at Google, Ch. 16 (yeni sekmede açılır) - Monorepo ölçeğinde continuous deployment: geliştiricilerin %95’i ve günlük değişiklik hacmi.
• Rapid release at massive scale - Meta Engineering (yeni sekmede açılır) - Web release akışı; Android ritim değişiminden ayrıdır.