Kesintisiz teslimat dışında sihirli değnek yok mu?
Aslında “gümüş mermi” yok. Ancak sürekli teslimat o kadar çok fayda vaat ediyor ki sihirli değnek olabilir. Öyleyse doğru olan nedir: Var mı, yoksa sürekli teslimat abartılıyor mu?
“Gümüş mermi” terimi, Frederick Brooks’un 1986 tarihli bir makalesinden gelir. IBM’in OS/360 işletim sisteminin gelişimini bildiren “The Mythical Man-Month” kitabının yazarıdır. Bu projeye öncülük etti. 5 milyar dolarlık bir bütçesi vardı ve sadece 1960’larda aya inişle cüce kaldı. Kitap, bugün hala geçerli olan içgörüler içeriyor; örneğin, bir proje birden fazla kişiye verilirse başlangıçta yavaşlar, çünkü insanların önce kendilerini tanımaları gerekir.
gümüş mermi
Gümüş mermiler aslında kurtadamları avlamak için kullanılır. Brooks, birçok BT projesinin sonunda bir canavara dönüştüğünü, bu nedenle sihirli değneklere ihtiyacımız olduğunu savunuyor. Ancak hiç yok: Ona göre, on yıl içinde tek bir gelişme bile daha iyi verimlilik, güvenilirlik veya basitlik vaat etmiyor. Bir büyüklük sırası 10’luk bir faktördür.
Brooks, teknik karmaşıklık etkenlerinin zaten ortadan kaldırıldığını savunuyor. Bununla birlikte, karmaşıklığın çoğu artık gereksinimlerden, projelerden ve testlerden gelse de, karmaşıklığı çözmenin basit bir yolu yoktur. Kendi başınıza bir şey inşa etmek yerine satın almakta, daha iyi gereksinim yönetiminde, artımlı geliştirme yoluyla yazılımın “yetiştirilmesinde” ve sonunda iyi tasarımcılarda umut vaat ediyor.
sürekli teslimat
Sürekli teslimat, yazılımın sürekli teslimatını tanımlar. Daha yüksek dağıtım sıklığı ile üretimi değiştirmek için gereken sürenin azaldığı açıktır. Artık daha fazla etki gösteren bir çalışma (“2018 State of DevOps Report”) var. Gerektiğinde günde birkaç kez görev yapan “seçkin uygulayıcılar” ile haftada bir ila ayda bir kez konuşlanan “düşük düzeyde uygulayıcılar” arasında ayrım yapar. Dolayısıyla, üç ayda bir yayınlanan takımlar da “düşük performans” göstermiyor.
Seçkin sanatçılar mantıksal olarak düzenlemelerin üretime aktarıldığı daha yüksek bir hıza ulaşır:
- Dağıtım sıklığı 46 kat daha fazladır.
- Bir değişikliğin üretime girmesinden önceki süre 2555 kat azalır.
- Dağıtımların başarısız olma olasılığı yedi kat daha azdır.
- Bir hizmet hatasından sonra 2604 kat daha hızlı yeniden başlatma.
- Ekstra çalışma süresinin 2/3’ü yeni özelliklere harcanabilir.
- Son kullanıcılar tarafından bildirilen güvenlik sorunları veya kusurlar için harcanan sürenin yarısı.
- Müşteri desteği için zamanın üçte birini alır.
Ama gümüş kurşunlar?
Bir açıklama, Brooks’un hatalı olduğu olabilir. Prensip olarak, bir şeyin var olmadığını kanıtlamak zordur. Makalesi kanıt sağlamaz, ancak esasen yazarın görüşünü yansıtır. O şimdi 30 yaşında, yani bu arada belki bir şeyler değişmiştir.
Öte yandan, Brooks çok deneyimli ve yazılım geliştirme sahnesindeki en önemli insanlardan biri. Dolayısıyla belge kolayca göz ardı edilemez.
Kesintisiz teslimat: sadece reklam mı?
Bu çalışma bile kusurlu olabilir. Çalışmanın arkasında, diğerlerinin yanı sıra DevOps kılavuzunu ve Phoenix projesiyle ilgili kitabı yazan Gene Kim var. Sürekli Teslimatı olumlu gören her iki kitap. Çalışmanın bir başka kahramanı da ilk sürekli teslimat kitabının yazarlarından biri olan Jez Humble. Bu insanlar, sürekli teslimatın her şeye rağmen önemli faydalar sağlamadığını gösteren bir çalışma yazsalar harika olur.
Ancak grubun üçüncü yazarı bilim adamı Dr. Nicola Forsgren’dir. Bu nedenle, çalışmanın bilimsel incelemeye dayanacağından ve bilimsel standartlara göre değerlendirildiğinden emin olabilirsiniz. Son olarak, çalışma büyük bir veri tabanına sahiptir: buna toplam 30.000 kişi katılmıştır. Kapsamlı bir veri tabanı ve profesyonel veri değerlendirmesi aslında önemli sonuçlara yol açar.
Her ikisi de doğru mu?
Bence çelişki yok. Hem stüdyo hem de Brooks haklı.
Bunun birden fazla nedeni var:
- Dağıtım hızını artırmak “tek bir gelişme” değildir. Dağıtımın hızlandırılması, yapılandırma yönetiminin, testin, dağıtımın ve değişiklik onaylarının otomatikleştirilmesini gerektirir. Araştırma da bunu kanıtlıyor. Değişiklikler genellikle mimariye kadar gider. Mikro hizmetler gibi yalnızca küçük, ayrı olarak dağıtılabilen birimler gerçekçi bir şekilde günde birden çok kez dağıtılabilir. Bu nedenle, daha hızlı uygulama hızı, daha da hızlı uygulamak için çözülmesi gereken zorlukları gösterebilir. Ancak bu “tek bir gelişme” değil, çok sayıda önlem gerektiriyor.
- Brooks, üretkenlik, güvenilirlik veya basitlikte bir büyüklük sırasına göre gelişmeyi reddediyor. Bununla birlikte, çalışma “yalnızca” çalışma saatlerini yeni özellikler için bir ölçü olarak kullanırken verimlilikte 2/3’lük bir gelişme görüyor. Güvenilirlik söz konusu olduğunda, hata ayıklamak için gereken adam saatlerini düşündüğünüzde bu iki faktördür. Bir dağılımın hatayla sonuçlanma olasılığı altı kat azalır, ancak bu bile bir büyüklük sırası değildir.
- Son olarak Sürekli Teslimat, Brooks’un tavsiye ettiği yazılım “yetiştirme” yöntemini uygular: yazılım daha sık üretime alınır. Böylece ekipler daha küçük adımlarla ilerliyor. Bu, geri bildirim döngülerini teşvik eder: üretim sonuçları doğrudan geliştirmeye akabilir ve projenin karmaşık bir plana göre tamamlanması yerine adım adım büyümesine olanak tanır.
Kesintisiz teslimatın aslında pek çok belirgin faydası vardır. Çalışma bunu açıkça ve çok iyi belgelenmiş olarak göstermektedir. Bu, sürekli teslimatın faydalarını açıkça göstermeye yardımcı olur. Bununla birlikte, sürekli teslimat da muhtemelen sihirli değnek değildir. Bununla birlikte, sürekli teslimatın faydaları, yazılımın ve yeni özelliklerin hızlı teslimatının çok ötesine geçer. Bu nedenle, özellikler üretime daha hızlı getirilmeyecek olsa bile, bu alana yatırım yapmaya değer çünkü üretkenlik ve güvenilirlik de önemli ölçüde artacaktır.
tl; doktor
Gümüş mermilerin yazılım geliştirmeyi en azından bir kat geliştirmesi gerekiyor, ancak ne yazık ki hiç yok. Bununla birlikte, sürekli teslimatın güvenilirlik ve üretkenlik açısından da kanıtlanabilir önemli faydaları vardır.
()
Haberin Sonu