İzlenebilir İş Kırılımı
Her uygulama görevi gevşekçe ilişkilendirilmiş bir özellik tanımına değil, belirli bir gereksinime veya kabul kriterine bağlıdır.
Geliştirme ve Entegrasyon · Adım 04 · Nasıl Çalışıyoruz
Spesifikasyon Yazılıma Dönüşür.
Çözüm Tasarımı test edilmiş bir spesifikasyon ve tanımlanmış kabul kriterleri üretir. Bu aşama, o spesifikasyonu çalışır durumda, doğrulanmış yazılıma dönüştürür — birlikte çalışacağı sistemlerle entegre edilip, geliştirme başlamadan önce belirlenen kriterlere göre doğrulanmış olur.
Buradaki geliştirme yorumlama değildir. Her uygulama kararı, tasarım sırasında oluşturulmuş bir spesifikasyona dayanır — geliştiricinin muhtemel niyetiyle ilgili varsayımlara değil.
Soru bu değil
"Kod çalışıyor mu?"
Bunun yerine şu soru
"Oluşturulan sistem, yalnızca izole değil gerçek entegrasyon koşullarında — işe başlamadan önce belirlediğimiz kabul kriterlerini karşılıyor mu?"
Uygulama · Doğrulama · Entegrasyon · İzlenebilirlik · Teslim Disiplini
Geliştirme Neden Tasarımı Takip Eder
Burada Hiçbir Şey Tahmine Dayalı Değil.
Bu aşamaya giren tüm girdiler Çözüm Tasarımı sırasında oluşturuldu: Çözüm Spesifikasyon Belgesi, Prototip Değerlendirme Raporu ve Kabul Kriterleri ile Test Planı. Test edilmemiş bir spesifikasyona göre geliştirme yapmak, prototiplemenin ortadan kaldırmayı amaçladığı riski üretim koduna geri taşımaktan başka bir şey değildir.
Çözüm Spesifikasyonu + Kabul Kriterleri → Doğrulanmış Uygulama
Teslim Disiplininin Önemi
Hız ve kararlılık birlikte ölçülür; biri diğerinin yerine feda edilemez.
Yazılım teslim performansı, bir ekibin yalnızca ne kadar hızlı kod yazdığıyla özetlenemez. Forsgren, Humble ve Kim'in — DORA programının yıllara yayılan, binlerce kuruluşu kapsayan araştırmasına dayanan ve Accelerate: The Science of Lean Software and DevOps (2018) kitabında yayımlanan — çalışması, birlikte ölçülmeleri gereken iki mühendislik performansı kategorisi belirledi: çıkış hızı (throughput) ve kararlılık.
Teslim Süresi
Doğrulanmış bir değişikliğin commit'ten dağıtıma hazır hale gelene kadar geçen süre.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps araştırması.
Değişiklik Hata Oranı
Düzeltme gerektiren bir hata oluşturan değişikliklerin yüzdesi.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps araştırması.
Araştırmaya göre hızlı ama sık sık hata üreten bir ekip iyi performans göstermiyor — aynı şekilde güvenli ama önemsiz derecede yavaş olan bir ekip de iyi sayılmaz. OpenQCore bu aşamada yalnızca hızı optimize etmek yerine her iki boyutu da göz önünde tutar.
Spesifikasyondan Uygulamaya
Yapılan her iş bir gereksinime izlenebilir.
Uygulama çalışmaları, tasarımın "neyi amaçladığı"na dair genel bir anlayıştan değil, doğrudan Çözüm Spesifikasyonu ve Kabul Kriterleri'nden ayrıştırılır.
Tamamlanma Kriteri
Bir görev yalnızca kod yazıldığında tamamlanmış sayılmaz. Test altında bağlı olduğu kabul kriterini karşıladığında tamamlanmış olur.
Spesifikasyon Sapması Kontrolü
Uygulama sırasında spesifikasyonda bir boşluk veya belirsizlik ortaya çıkarsa, spesifikasyon güncellenir ve gözden geçirilir — o gün kodu yazan kişinin sessizce yeniden yorumlamasına bırakılmaz.
Test Odaklı Doğrulama
Doğrulama sadece sonunda değil, her katmanda gerçekleşir.
OpenQCore doğrulamayı test piramidi'ne göre yapılandırır — Mike Cohn tarafından popülerleştirilen ve test kapsamını sistem katmanlarına dengeli olarak yaymayı, yavaş ve maliyetli uçtan uca testlere yüklenmemeyi amaçlayan yaygın bir çerçevedir.
Birim Testleri
Bireysel bileşenlerin belirtilen davranışlarına karşı hızlı, izole doğrulaması — geçersiz girişler altındaki davranışları da kapsar.
Entegrasyon Testleri
Çözüm tasarımında tanımlanan veri sözleşmelerine göre bileşenlerin doğru etkileşim kurduğunun doğrulanması.
Uçtan Uca Testler
Geliştirme başlamadan önce tanımlanan kabul kriterlerine göre tam iş akışlarının doğrulanması — en küçük ve en maliyetli test katmanı; yalnızca gerçekten gerektiğinde uygulanır.
Amaç mümkün olduğunca çok test yazmak değil; hedef, kabul kriterlerinin gerçekten karşılandığına, bunu kanıtlayabilecek en düşük maliyetli katmanda güven duymaktır.
Entegrasyon & Sözleşme Testleri
Bir API sözleşmesi yalnızca belgelendi diye gerçek sayılmaz; test edilirse gerçek olur.
Çözüm Tasarımı sırasında belirlenen veri ve API sözleşmeleri gayri resmi olarak izlenecek belgeler gibi ele alınmaz. OpenQCore, her entegrasyon noktasını entegrasyonun her iki tarafının da uyması gereken yürütülebilir bir sözleşmeye karşı doğrulayan tüketici odaklı sözleşme testi yaklaşımını — Pact gibi araçlarda biçimlendiği şekilde — uygular.
Bu, özellikle mevcut altyapıya bağlanması gereken sistemler için önem taşır: yalnızca elle incelemeyle kontrol edilen bir sözleşme, taraflardan biri değiştikçe sessizce sapabilir. Otomatik olarak test edilen bir sözleşme ise bu sapmayı engeller.
Kod İncelemesi & Statik Doğrulama
İkinci bir göz, yazarın göremediğini yakalar.
Eş düzey kod incelemeleri üzerine sıkça atıf yapılan araştırmalar — Cisco Systems'ta gerçekleştirilen çalışma ve Cohen ve ark.'nın Best Kept Secrets of Peer Code Review adlı çalışmasında popülerleşen bulgular da dahil — inceleme etkinliğinin hız ve kapsamdan büyük ölçüde etkilendiğini gösteriyor: zaman baskısı olmadan, küçük ve sık yapılan incelemeler, hızlıca gerçekleştirilen büyük incelemelere kıyasla çok daha fazla hatayı yakalıyor.
OpenQCore, yapılandırılmış kod incelemesini otomatik statik analizle — stil, karmaşıklık ve bilinen güvenlik açıklarının taranması — birlikte sürekli bir doğrulama katmanı olarak uygular; bu, birleştirmeden önce yapılan isteğe bağlı bir nezaket kontrolü değildir.
Sürekli Entegrasyon Pipeline'ı
Her değişiklik aynı şekilde ve otomatik olarak doğrulanır.
Commit → Otomatik Derleme → Birim & Entegrasyon Testleri → Statik & Güvenlik Analizi → Sözleşme Doğrulaması → Dağıtıma Hazır.
Elle ve tutarsız yapılan doğrulama ölçeklenmez ve bir değişikliğin gerçekten güvenli olup olmadığına dair güvenilir bir gösterge vermez — bu karar bir sonraki aşama olan Dağıtım & Etkinleştirme'de verilir. Bu aşamanın garanti ettiği, bu kapıya ulaşan bir değişikliğin ondan önceki tüm değişikliklerle aynı otomatik standartlara göre doğrulanmış olduğudur.
Güvenli Geliştirme Uygulamaları
Güvenlik, geliştirme sırasında doğrulanır; sonradan yapılan denetimlere bırakılmaz.
OpenQCore'un geliştirme uygulamaları, NIST'in Secure Software Development Framework (SP 800-218) dokümanında tanımlanan yapıyla uyumludur — güvenlik faaliyetlerini kuruluşu hazırlama, yazılımı koruma, güvenli yazılım üretme ve güvenlik açıklarına yanıt verme etrafında düzenler.
Bağımlılık ve Güvenlik Açığı Taraması
Standart pipeline'ın bir parçası olarak üçüncü taraf bağımlılıklarının bilinen güvenlik açıkları açısından otomatik taranması; aralıklı elle yapılan denetimlerin yerine geçer.
Tehdit Modellemesi
Çözüm tasarımında tanımlanan hata modlarından hareketle, bir bileşenin nasıl kötüye veya yanlış kullanılabileceğinin yapılandırılmış olarak değerlendirilmesi.
En Az Ayrıcalık Uygulaması
Erişim ve izin kapsamları, kullanışlı olduğu için en geniş düzeyde değil, gereksinimleri karşılayan en dar düzeyde uygulanır.
Entegrasyon Doğrulama Geçidi
Bir build'in yalnızca derlenmiş olması, onun hazır olduğu anlamına gelmez.
Her değişiklik, dağıtıma alınmadan önce tanımlı bir doğrulama geçidinden geçer.
Dağıtıma Hazır
Tüm kabul kriterleri karşılanmış; bu durum otomatik testler, sözleşme kontrolleri ve güvenlik taramalarıyla doğrulanmıştır.
Düzeltme İçin İade
Bu değişikliğe devam edilebilmesi için tespit edilen belirli kusurların giderilmesi gerekir.
Tasarım Aşamasına İade
Uygulama, spesifikasyonun gerçek koşullarda geçerli olmadığını gösterdi — doğru yaklaşım kodla etrafından dönmek değil, spesifikasyonu revize etmektir.
Riskin Üst Makama Taşınması
Geliştirme ekibinin yetkisinin üzerinde bir karar gerektiren güvenlik, uyumluluk veya mimari risk tespit edildi.
Sürekli olarak "deploy için hazır" durumuna ulaşan bir pipeline aslında hiçbir şeyi doğrulamıyor demektir.
Bu Aşamanın Çıktıları
Dağıtım Kararı İçin Hazır Yazılım — Henüz Dağıtılmadı.
İş kapsamına bağlı olarak bu aşama şunları üretebilir:
Doğrulanmış Kod Tabanı
Spesifikasyona izlenebilen, tanımlı tüm doğrulama katmanlarını geçen uygulama.
Test Kapsam Raporu
Birim, entegrasyon ve uçtan uca test sonuçlarının kabul kriterleriyle eşlenmiş hali.
Sözleşme Test Seti
Çözüm tasarımında tanımlanan her entegrasyon noktasının çalıştırılabilir doğrulaması.
Kod İnceleme Kayıtları
Dokümante edilmiş inceleme geçmişi ve ortaya çıkan sorunların çözümü.
Güvenlik Tarama Sonuçları
Bağımlılık, açık ve statik analiz bulguları ile bunların çözümü.
CI Pipeline Dokümantasyonu
Bu değişikliğe uygulanan ve sonrasında yapılacak her değişiklikte kullanılan otomatik doğrulama pipeline'ı.
Geliştirmeden Dağıtım ve Kullanıma Alma'ya
Doğrulanmış Yazılım Henüz Canlı Yazılım Değildir.
Geliştirme ve Entegrasyon, spesifikasyona karşı doğrulanmış yazılım üretir — ancak bu, yayımlanmış, izlenen veya gerçek üretim yükü altında kararlılığı kanıtlanmış yazılım anlamına gelmez. Sonraki aşama, bu yazılımın üretime nasıl, ne zaman ve ne şekilde güvenli bir şekilde geçeceğini düzenler.
Çözüm Spesifikasyonu → Doğrulanmış Uygulama → Dağıtım ve Kullanıma Alma
Adım 05
Dağıtım ve Kullanıma Alma
Doğrulanmış yazılımı güvenli ve planlı biçimde, geri alma yolu tanımlı olarak üretime alın.
Araştırma ve Yöntemsel Kaynaklar
Forsgren, N., Humble, J. ve Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA State of DevOps research
Yukarıda bahsedilen teslimat performansı metriklerinin kaynağı.
Cohn, M. — Succeeding with Agile (2009)
Test odaklı doğrulamada bahsedilen test piramidi kavramının kaynağı.
Cohen, J. ve diğerleri — Best Kept Secrets of Peer Code Review (SmartBear, Cisco Systems'teki araştırmaya dayanır)
Yukarıda söz edilen kod inceleme etkinliğine ilişkin bulguların kaynağı.
Pact / Tüketici Odaklı Sözleşmeler
Entegrasyon testi bölümünde geçen; yürütülebilir ve otomatik doğrulanan entegrasyon sözleşmeleri için yerleşik bir yaklaşım.
NIST — Secure Software Development Framework, SP 800-218
Yukarıda güvenli geliştirme uygulamalarında bahsedilen yapının kaynağı.