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ına yapısal olarak saldırmaktır. 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 koruma bantlarına dönüştür.

Bu bir öğretici değil, bir karar rehberidir. Koddan çok çerçeveleri ve trade-off’ları öne çıkarır. Buradaki her sayı, yayımlanmış araştırmalardan alınmış bir bulgudur; benim bir ölçümüm değildir.

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 fikirden değil, 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 iş değil, 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 birine tek tek saldırıyor.

Bu saati kısaltmanın izin belgesi, 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ümesinden yaklaşık 127 kat 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 kahramanlık gerektiren bir release değil; 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 işi haftalarca kayan bir dalda park etmek yerine 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

Dürüst bir incelik: 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 Treni Değil, Release Anahtarı

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ışı açan şey bir deploy penceresi değil, bir flag çevirmesidir. 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 değil, kademeli olabilir. 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; böylece yayılım kapısı bir panoyu izleyen bir insan değil, veridir. 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: “ferasetli 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 borç değil, kalıcı bir ürün yeteneği

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 envanter olarak flag’ler hakkında bir uyarıdır, flag’lerin tehlikeli olduğunun kanıtı değil; çö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 güvenliği zayıflatmaz, 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 arkasında kapı altında tutmak 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). Asıl kavrayış 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 koruma bantları 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 için değil, 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”; sabit bir kapı dizisi yerine 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ı bir toplantı değil, 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.

Burada dürüst bir karşı ağırlık var; bu kaldıracın bir sınırı olmasının asıl nedeni de bu. 2024 DORA raporu, bir iç geliştirici platformu benimsemenin kısa vadede azalan iş hacmi (yön olarak 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ı; bu yüzden güvenlik adımı okumasını DORA’nın bulgusu olarak değil, akla yatkın bir mekanizma olarak ele alın. Ders kesindir: bir koruma bandı 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. (Geniş çapta tekrarlanan bir istatistik, bağımlılık otomasyonunun “yaklaşık %40 daha az açık” sağladığı iddiası, kaynaksızdır; kullanmayın. Bağımlılık ritmi sizin durumunuz için önemliyse, GitHub’ın Octoverse 2025’i daha zayıf, gerçek rakamları bildirir: kritik düzeltmeler %30 daha hızlı, 37 günden 26 güne; kritik uyarılı depolarda ise %26 azalma.) Bu kaldıracın tam işlenişi, güvenlik incelemesini kritik yoldan çıkarma üzerine kardeş yazıda.

Tek Başına Göndermenizi 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 ve taşı ve 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 “önceden test edilmiş uygulama setlerini birlikte deploy etmenin” eski moda darboğazı olarak tarif ettiği “test edilmiş seti birlikte deploy et” 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 bir takvim olayı değil, otomatik bir denetim olur. İ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” (belirli sürüm dizesi zamanla ileri kayar, bu yüzden herhangi birini bir örnek olarak ele alın). Bunun yanında sık gelen monorepo’ya karşı polyrepo sorusunun yetkili bir cevabı yoktur; bir sayı değil, 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; bu da eski istemcilerin neden basitçe yok olmadığının arkasındaki yönsel gerçektir.

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 o dikiştir. Bir BFF, kullanıcı deneyimi başına bir arka uçtur ve arayüze sahip olan ekibin sahip olduğu bir şeydir; 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ş saatinde 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); yalnızca veriyi değil, 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, evrensel bir öneri değil: 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 emekliye ayı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 platformun verdiği bir garanti değil, bir ürün ve politika kararı olarak ele alın. 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ı vergisini haklı çıkardığında uzan. 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; bu, yeni bir bulgu değil, kökeni olarak anılmaya değer temel bir kaynaktı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 ve 24.000 otomatik değişikliği soğurur. Meta’nın mirası aynı yayı gösterir, ama iki pipeline’ı karıştırmamak gerekir: mobil release ritmi dört haftalık döngülerden haftalığa doğru sıkıştı, kademeli çalışanlar-%2-%100 rampası ise web akışına aittir.

Öyleyse öneri bir sırayla birlikte ayakta kalır: önce lead time saatini ölç, sonra en büyük bekleme aşamasına saldır; sırayla parti boyutu, ardından deploy-release ayrımı, ardından güvenlik ve ekipler arası kapılar. 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 aşma 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 başlamak yerine ne zaman durulacağına karar verir.

Tek sonraki adım araç değil, ölçümdür: saati commit’ten üretime kadar 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 - 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) - 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) - “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 - 2024 küme değerleri ve incelikleri, ayrıca platform mühendisliği iş hacmi ve istikrar karşı ağırlığı. Yayından önce güncelliğini doğrulayın.
• Octopus — 2024 DevOps performance clusters - Burada kullanılan 2024 elite referans değerlerinin özeti. Yayından önce güncelliğini doğrulayın.
• Trunk Based Development - Trunk’ı deploy edilebilir tutan tek-trunk disiplini ve tam zamanında release dalları.
• Branch by Abstraction — Martin Fowler - Büyük bir refactor sırasında trunk’ı deploy edilebilir tutmak.
• DORA — DORA metrics guide - Küçük parti ilkesi ve parti boyutu için vekil olarak deploy sıklığı.
• Feature Toggles (aka Feature Flags) — Pete Hodgson / Martin Fowler - Dört toggle kategorisi, release’i deployment’tan ayırma, taşıma maliyeti ve Knight Capital uyarısı.
• Dark Launching — Martin Fowler - Yeni davranışı mevcut kullanıcılar için sessizce çağırmak.
• Argo Rollouts — Analysis - AnalysisRun ve AnalysisTemplate ile ürünleştirilmiş metrik kapılı canary. Yayından önce güncelliğini doğrulayın.
• DORA — Capabilities: Pervasive security - 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 - Kapılar yerine koruma bantları, 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 - Kontrol listesi yerine dört grupta (PO, PS, PW, RV) sonuç-odaklı, riske dayalı pratikler.
• OWASP DevSecOps Maturity Model - Olgunluk seviyesi 2 ve 3’te önem eşiğine dayalı pipeline kapıları.
• SLSA v1.2 — Build track basics - Kademeli olarak benimsenebilir tedarik zinciri build seviyeleri. Yayından önce güncelliğini doğrulayın.
• Semantic Versioning 2.0.0 - MAJOR/MINOR/PATCH uyumluluk kuralları ve public API ön koşulu.
• Parallel Change — Martin Fowler / Danilo Sato - 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 - Aynı disiplinin sıfır kesintili veritabanı şema migration’larına uygulanması.
• Can I Deploy — Pact Docs - Önceden test edilmiş uygulama setlerini birlikte deploy etmenin yerini alan matris ve can-i-deploy kapısı.
• Pact — Documentation - Tüketici güdümlü sözleşme testi: tüketicilerin kullanmadığı sağlayıcı davranışı değişmekte serbesttir.
• Tolerant Reader — Martin Fowler - Tüketici tarafında Postel Yasası: bilinmeyen alanları görmezden gel.
• Confluent — Schema evolution and compatibility - Deploy sırasını belirleyen BACKWARD, FORWARD, FULL ve TRANSITIVE uyumluluk modları.
• Stripe API versioning - Tarih tabanlı eklemeli evrim; major’a karşı geriye dönük uyumlu aylık release’ler. Yayından önce güncelliğini doğrulayın.
• Building Microservices, 2nd ed. (Sam Newman) - Bağımsız deploy edilebilirlik testinin kaynağı (web kanonu olarak alıntılanmadan özetlenmiştir).
• Apple — App Review - Güncel “ortalama 24 saatte %90” inceleme süresi rakamı. Yayından önce güncelliğini doğrulayın.
• iOS adoption statistics — MacRumors - Büyük bir mobil işletim sisteminin yükleme tabanının yalnızca yaklaşık üçte ikisine ulaştığına dair yönsel kanıt. Yayından önce güncelliğini doğrulayın.
• Backends For Frontends — Sam Newman - Arayüz ekibinin sahip olduğu, kullanıcı deneyimi başına bir arka uç olarak BFF; geri alınamayan istemciler için sunucu tarafı dikiş.
• API Gateway pattern — Microservices.io - Her istemci türü için ayrı bir API gateway.
• A deep dive into Airbnb’s server-driven UI system — Airbnb Engineering - Geriye dönük uyumlu bölümlere sahip Ghost Platform sunucu güdümlü arayüz sistemi.
• Team Topologies — Martin Fowler - 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 - Çalıştırdığını-sen-inşa-et ilkesinin kökeni.
• New platform engineering research — Google Cloud - Platform olgunluğu ve pazara çıkış süresi üzerine tedarikçi destekli anket; öyle okuyun.
• Software Engineering at Google, Ch. 16 - 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 - Web release akışı; Android ritim değişiminden ayrıdır.