Waterfall'dan Agile'a ve DevOps'a: Geri Bildirim Döngüsü Neden Aylardan Saatlere İndi?
Geri bildirim döngüsü, deploy'un sabit maliyeti düştükçe kısaldı: maliyet düşünce batch küçüldü, küçük batch hem riski hem hatanın bulunma süresini azalttı. 1990'ların lightweight yöntemlerinden Agile Manifesto'ya, 2009'da DevOps'a ve Continuous Delivery'ye uzanan çizgiyi, DORA'nın beş metric'ini, shift-left'i ve sprint yapıp release'i hâlâ çeyrekte bir yapan water-scrum-fall tuzağını anlatıyoruz.
Sürüm notu: Bu yazı Agile Manifesto'nun (Şubat 2001) tarihçe sayfasını ve DORA'nın (DevOps Research and Assessment) Kasım 2026 itibarıyla yayında olan beş metric'lik modelini esas alır.
Önce Tahmin Et
Bookstore'un 2015'teki hâlini düşün: ekip üç ayda bir release yapıyor. Bir geliştirici Ocak'ın ilk haftasında kargo ücreti hesabına bir değişiklik ekliyor ve değişiklik bir yuvarlama hatası içeriyor. Bu hata production'da ne zaman görünür ve göründüğünde, geliştirici bu kodu yazarken ne düşündüğünü ne kadar hatırlar?
Şimdi aynı ekibi günde birkaç kez deploy ettiği bugünkü hâliyle düşün. Aynı hata kaç saatte görünür ve kaç commit'in arasından bulunur? İki cevap arasındaki fark, bu yazının konusu olan elli yılın özeti.
Kısa Tarihçe: 1970'ten Bugüne
SDLC (Software Development Life Cycle) serisinin önceki yazılarında Royce'un 1970 makalesini, sözleşmelerle kurumsallaşan sıralı modeli, V-Model'i ve Spiral'i gördük. 1990'larda bu ağır süreçlere tepki olarak bir grup "lightweight" yöntem ortaya çıktı: DSDM (Dynamic Systems Development Method) 1994'te bir konsorsiyumla, Scrum 1995'te Ken Schwaber ile Jeff Sutherland'in OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) konferansındaki sunumuyla, XP (Extreme Programming) Kent Beck'in 1996'da başladığı projeden ve 1999'daki kitabıyla, FDD (Feature-Driven Development) 1997'de Jeff De Luca'nın bir banka projesinden, Crystal yöntem ailesi Alistair Cockburn'ün çalışmalarından doğdu.
Şubat 2001'de bu yöntemlerin temsilcilerinden 17 kişi Utah'taki Snowbird'de bir araya geldi ve Agile Manifesto'yu yazdı. Manifesto'nun değerleri ve prensipleri ayrı bir serinin, Agile Mindset'in konusu; Agile'ın 2001 sonrası evrimi de o serinin son yazısında. Burada önemli olan çizgi şu: Agile, geri bildirim döngüsünü aylardan haftalara indirdi ama döngünün son halkası, yani production'a çıkış, birçok ekipte hâlâ yavaştı.
O halkayı kısaltan hareket 2009'da DevOps adını aldı. O yılın Haziran ayında John Allspaw ve Paul Hammond, Velocity konferansında Flickr'da geliştirme ve operasyon ekiplerinin birlikte nasıl günde ondan fazla deploy yaptığını anlattı. Ekim'de Patrick Debois, Belçika'nın Gent şehrinde ilk DevOpsDays etkinliğini düzenledi. 2010'da Jez Humble ve David Farley'nin "Continuous Delivery" kitabı, her commit'in otomatik bir deployment pipeline'ından geçip release edilebilir hâle gelmesi fikrini sistemleştirdi.
Asıl Değişken: Deploy Maliyeti ve Batch Size
Bu tarihçeyi yöntem adlarıyla okumak kolay, ama altta yatan değişken ekonomik. Bir değişikliği production'a çıkarmanın bir sabit maliyeti var: build, test, onay, deploy, geri alma planı. Bu maliyet yüksekken değişiklikleri biriktirip büyük paketler hâlinde çıkarmak mantıklı görünür. 1970'te bir sürüm manyetik bantla müşteriye gönderiliyor, 1990'larda kompakt disklerle dağıtılıyordu; bir release'in sabit maliyeti haftalarca süren bir işti.
Biriktirmenin de bir maliyeti var ve bu maliyet görünmez. Don Reinertsen'in "The Principles of Product Development Flow" (2009) kitabında anlattığı gibi, batch büyüdükçe bekleyen işin maliyeti, riski ve geri bildirim gecikmesi de büyür. Bookstore'un üç aylık release'inde 140 commit birlikte çıkıyorsa ve production'da bir şey bozulursa, soru "hangi commit?" olur ve cevap günler sürebilir. Günlük release'te aynı soru üç commit arasında, bir saat içinde cevaplanır. Hatayı yazan geliştirici de kodu hâlâ hatırlıyordur.
Deploy otomasyonu, bulut altyapısı, container'lar ve otomatik testler sabit maliyeti düşürdükçe, optimum batch küçüldü. Agile ve DevOps bu açıdan bir felsefe değişikliği olduğu kadar bir maliyet eğrisinin kaymasıdır. Figürdeki alt bant bunu gösteriyor: release aralığı yıllardan saatlere indi, çünkü bir release'in maliyeti indi.
Bookstore'da Döngünün Kısalması
Bookstore'un geçişini üç dönemde izleyelim. İlk dönemde release üç ayda bir, iki haftalık bir "stabilizasyon" haftasıyla birlikte yapılıyor; test ekibi o hafta bütün değişiklikleri birlikte deniyor. Geliştiricinin bir değişiklik için production'dan geri bildirim alma süresi ortalama altı haftaya yakın.
İkinci dönemde ekip Scrum'a geçiyor ve iki haftalık sprint'ler yapıyor. Ama release süreci değişmiyor: sprint'lerin çıktısı bir release branch'inde birikiyor ve yine üç ayda bir çıkıyor. Ekip "Agile'ız" diyor; müşterinin gördüğü döngü ise aynı. Tuzaklar bölümünde bu durumun adına döneceğiz.
Üçüncü dönemde ekip trunk-based geliştirmeye, CI (Continuous Integration) ve CD (Continuous Delivery) ilkeleriyle çalışan otomatik bir deployment pipeline'ına ve feature flag'lere geçiyor. Her merge, testlerden geçerse staging'e, onaydan sonra production'a gidiyor; tamamlanmamış feature'lar flag'in arkasında kapalı duruyor. Kargo ücreti hatası artık deploy'dan bir saat sonra bir alarmla görünüyor ve geri alma tek bir commit'in revert edilmesi. Branch stratejileri Git & GitHub serisinin "Git ile Ekip Çalışması: Branch Stratejileri, Rulesets ve Conventional Commits" yazısında, pipeline kurulumu ASP.NET Core Web API (Application Programming Interface) serisinin "ASP.NET Core Web API'yi Docker'a Almak ve GitHub Actions ile CI/CD Kurmak" yazısında.
SDLC'yi Ölçmek: DORA'nın Beş Metric'i
Döngünün gerçekten kısalıp kısalmadığını tahminle değil, ölçerek bilirsin. Google bünyesindeki DORA araştırma programı on yılı aşkın süredir yazılım teslim performansını ölçüyor. 2014'te dört metric'le başlayan model bugün beş metric'ten oluşuyor; beşincisi 2024 raporunda eklendi. Metric'ler iki grupta:
| Grup | Metric | Ne ölçer |
|---|---|---|
| Throughput | Change lead time | Bir değişikliğin commit edilmesinden production'a deploy edilmesine kadar geçen süre |
| Throughput | Deployment frequency | Belirli bir dönemde ne sıklıkla deploy edildiği |
| Throughput | Failed deployment recovery time | Acil müdahale gerektiren bir deploy'dan sonra toparlanma süresi |
| Instability | Change fail rate | Rollback ya da hotfix gibi acil müdahale gerektiren deploy'ların oranı |
| Instability | Deployment rework rate | Production'daki bir incident yüzünden yapılan plansız deploy'ların oranı |
DORA'nın en önemli bulgularından biri, hız ile istikrarın birbirinin karşıtı olmadığı: üst performanslı ekipler hem daha sık deploy ediyor hem de daha az hata yaşıyor. Bunun sebebi yine batch size; küçük değişiklik, küçük risk. Metric'lerin isimleri de zaman içinde değişti; örneğin eski adıyla MTTR (Mean Time to Restore), 2023'te yalnız deploy kaynaklı arızaları kapsayacak şekilde failed deployment recovery time oldu. Bu metric'lerin pipeline verisinden nasıl hesaplandığı CI/CD Temelleri serisinin "Pipeline'ı Ölçmek ve Hızlandırmak: DORA Metrikleri, Cache ve Paralellik" yazısında anlatılıyor.
Secure SDLC ve Shift-Left
Döngü kısaldıkça güvenliğin de döngünün içine girmesi gerekti. Üç ayda bir yapılan bir release'in sonuna bir güvenlik testi eklemek mümkündü; günde on deploy yapan bir ekipte güvenlik kontrolü pipeline'ın bir adımı olmak zorunda. Shift-left, kontrolleri yaşam döngüsünde sola, yani requirements, tasarım ve kodlama aşamalarına çekmek demek: tasarımda threat modeling, kodlarken statik analiz ve dependency taraması, pipeline'da secret taraması. Güvenlik açıklarının kendisi Web Güvenliği (OWASP Top 10) serisinde; bu kontrollerin pipeline'a nasıl ekleneceği ise ilerideki DevSecOps serisinin konusu.
Üretimde Dikkat
Önce bugünkü döngüyü ölç. Son on değişikliğin commit zamanını ve production'a çıktığı zamanı yan yana yazmak, change lead time için yeterli bir başlangıç. Çoğu ekip bu ölçümü ilk kez yaptığında, sürenin büyük kısmının kod yazmakta değil, review, onay ya da release penceresi beklemekte geçtiğini görür.
Batch'i küçültmenin en etkili aracı deploy ile release'i ayırmak. Feature flag'ler sayesinde kod her gün production'a gidebilir, ama kullanıcıya açılması ayrı bir karar olur. Bu ayrım, "bu feature hazır olmadan deploy edemeyiz" engelini kaldırır.
Hızlanmayı test otomasyonu olmadan zorlama. Testleri elle yapılan bir sistemde deploy sıklığını artırmak, change fail rate'i artırmaktan başka bir şey yapmaz. Sıra önemli: önce güvenilir bir pipeline, sonra sık deploy.
Sık Düşülen Tuzaklar
"Agile'a geçtik" deyip release'i hâlâ çeyrekte bir yapmak en yaygın tuzak. Forrester analisti Dave West'in 2011 tarihli raporuyla yaygınlaşan water-scrum-fall terimi tam olarak bunu anlatıyor: öncesinde Waterfall gibi bir planlama ve bütçe süreci, ortada Scrum sprint'leri, sonunda yine Waterfall gibi büyük bir release. Ekibin iç döngüsü kısalmış, ama müşterinin gördüğü döngü değişmemiştir.
İkincisi, DevOps'u bir ekip adı ya da bir araç sanmak. "DevOps ekibi" adıyla kurulan ve geliştiricilerin deploy işini devrettiği yeni bir ekip, geliştirme ile operasyon arasındaki duvarı kaldırmaz, sadece duvarın yerini değiştirir.
Üçüncüsü, DORA metric'lerini hedefe çevirmek. Deployment frequency bir performans hedefi yapılırsa, ekipler değişiklikleri anlamsız parçalara böler; metric iyileşir, döngü iyileşmez. Metric'ler bir ekibin kendi gelişimini görmesi için var, ekipleri birbiriyle karşılaştırmak için değil.
Küçük Bir Deneme
★☆☆ Ekibinin son on production deploy'u için change lead time'ı hesapla: commit zamanı ile deploy zamanı arasındaki farkın medyanı nedir? Sürenin en uzun beklediği aşama hangisi?
★★☆ Son çeyrekte production'da çıkan üç hatayı al. Her biri için, hatayı içeren değişiklik kaç başka değişiklikle birlikte çıktı ve hatanın kaynağını bulmak ne kadar sürdü?
★★★ Ekibinin bugünkü süreci water-scrum-fall'a benziyor mu? Planlama, geliştirme ve release aşamalarının her biri için geri bildirim döngüsünün süresini yaz ve en uzun olanı kısaltmak için tek bir somut değişiklik öner.
Elli yılın çizgisi belli: döngü kısaldı. Ama bu, her projenin aynı modeli kullanması gerektiği anlamına gelmiyor. Serinin son yazısında, requirements belirsizliği, regülasyon, sözleşme tipi ve deploy maliyeti gibi faktörlere bakarak bir proje için doğru SDLC modelinin nasıl seçileceğini konuşuyoruz.