Gümüş mermi yok – teslimat devam ediyor mu?
Gerçekte “gümüş mermi” yoktur. Ancak sürekli teslimat, bu gümüş merminin olabileceği birçok avantaj vaat ediyor. Peki, doğru olan nedir: var mı yoksa sürekli bir teslimat mı?
“Gümüş mermi” ifadesi Frederick Brooks'un 1986 kartından geliyor. Bu, IBMS OS/360 işletim sisteminin geliştirilmesi hakkında rapor veren “Mit Men-Month” kitabının yazarıdır. Bu projeyi yönetti. 5 milyar dolarlık bir bütçesi vardı ve sadece 1960'larda ayın inişi tarafından gölgeye konuldu. Kitap, bugün hala önemli olan sonuçları içeriyor, örneğin, bir proje başlangıçta projeye daha fazla insana güvendiğinde daha yavaş hale geliyor çünkü insanlar önce kendinizi tanımak zorundadır.
Gümüş Toplar
Gümüş toplar aslında kurt adamı avlamak için kullanılır. Brooks, birçok BT projesinin bir noktada bir canavarda hareket ettiğini ve bu nedenle gümüş toplara ihtiyacımız olduğunu iddia ediyor. Bununla birlikte, türden bir şey yoktur: ona göre, tek bir gelişme on yıl içinde büyüklük, güvenilirlik veya sadelik emrini vaat etmez. Boyut 10 faktördür.
Brooks, teknik karmaşıklık sürücülerinin zaten ortadan kaldırıldığını iddia ediyor. Bununla birlikte, karmaşıklığın çoğu artık gereksinimlerden, projelerden ve testlerden kaynaklanıyorsa, karmaşıklık basit bir makyajla çözülemez. Yalnız bir şey inşa etmek yerine, bunu vaat ediyor, gereksinimlerin daha iyi yönetimi, artımlı gelişim ve nihayet iyi tasarımcılar yoluyla “üreme” yazılımı.
Sürekli Teslimat
Sürekli dağıtım, yazılımın sürekli olarak verilmesini açıklar. Daha yüksek bir dağılım frekansı nedeniyle, üretim değişikliği olana kadar zamanın azaldığı açıktır. Şimdi daha fazla etkiyi gösteren bir çalışma (“DevOps 2018 eyaleti raporu) var. Kendisini günde birkaç kez uygulayan” seçkin sanatçıyı “ve haftada bir ve ayda bir kez dağıtılan” Basso sanatçısı “. Üç aylık versiyonu olan takımlar düşük performans gösteriyor.
Elit sanatçılar, değişikliklerin üretimde yapıldığı daha yüksek hızlar elde eder:
- Dağıtım frekansı daha yüksek 46 faktördür.
- Üretimde değişiklik zamanı 2555 daha azdır.
- Dağılımların başarısız olma olasılığı yedi kat daha düşüktür.
- Bir hizmetin başarısızlığından sonra 2604 kez daha hızlı.
- Yeni özellikler için 2/3 saatlik çalışma daha harcanabilir.
- Çalışma süresinin yarısı, son kullanıcılar tarafından bildirilen güvenlik sorunlarına veya kusurlara harcanmalıdır.
- Müşteri desteği için zamanın sadece üçte birine ihtiyacınız var.
Ama gümüş toplar?
Bir açıklama, Brooks'un doğru olmaması olabilir. Prensip olarak, bir şeyin var olmadığını göstermek zordur. Belgesi herhangi bir belge çağırmaz, ancak esasen yazarın görüşünü yansıtır. Şimdi 30 yaşında, bu yüzden şimdi biraz değişti.
Öte yandan, Brooks çok deneyimli ve yazılım geliştirme sahnesindeki en önemli insanlardan biri. Böylece kartı kolayca görmezden gelemezsiniz.
Sürekli Teslimat – Sadece bir istiridye?
Yukarıda belirtilen çalışma da yanlış olabilir. Çalışmanın arkasında, diğer şeylerin yanı sıra DevOps Kılavuzu ve Phoenix projesi kitabını yazan Gene Kim var. Sürekli teslimat yapan her iki kitap da olumlu görüyor. Çalışmanın bir başka kahramanı da ilk sürekli teslimat kitabının yazarlarından Jez Humble. Bu kişilerin sürekli teslimatın önemli avantajlar sunmadığını gösteren bir çalışma yazması şaşırtıcı olacaktır.
Ancak grubun üçüncü yazarı bilim adamı Dr. Nicole Forsgren. Böylece çalışmanın bilimsel bir revizyona direnebileceğinden ve bilimsel standartlara göre değerlendirildiğinden emin olabilirsiniz. Son olarak, çalışma büyük bir veritabanı gösterebilir: toplam 30.000 kişi bunun bir parçası oldu. Büyük bir veritabanı ve verilerin profesyonel değerlendirmesi aslında önemli sonuçlara yol açar.
İkisi de doğru mu?
Bence çelişki yok. Çalışma ve akarsuların ikisi de doğru.
Bunun birkaç nedeni var:
- Dağıtım hızının arttırılması “bireysel bir gelişme” değildir. Dağıtımını hızlandırarak yapılandırma yönetimi, testler, dağılımlar ve değişikliklerin onaylanması otomatikleştirilmelidir. Çalışma da bunu gösteriyor. Değişiklikler genellikle mimariye gider. Mikro hizmetler gibi sadece küçük ayrı dağıtım üniteleri günde birkaç kez dağıtılır. Bu nedenle daha fazla dağıtım hızı, daha da hızlı dağıtmak için çözülmesi gereken zorlukları gösterebilir. Ancak bu “bireysel gelişim” değildir, ancak çeşitli önlemler gerektirir.
- Brooks, verimlilik, güvenilirlik veya sadelikte bir iyileşme içermez. Bununla birlikte, yeni özellikler için çalışma saatleri kullanıyorsanız, çalışma 2/3 verimliliğin iyileştirilmesini “sadece” görüyor. Güvenilirlik ile, hataları kaldırmak için gereken çalışma saatlerine bakarsanız iki faktördür. Bir dağılımın bir hataya yol açma olasılığı daha düşük bir faktördür, ancak büyüklük sırasına göre bile değildir.
- Son olarak, sürekli teslimat Brooks tarafından önerilen yazılımın üremesini uygular: Yazılım daha sık üretime alınır. Bu nedenle, takımlar daha küçük pasajlara gidiyor. Bu, geri bildirim döngülerini destekler: Üretim sonuçları derhal kalkınmaya akabilir ve bu nedenle proje karmaşık bir plana göre tamamlanmak yerine yavaş yavaş büyüyebilir.
Sürekli teslimatın aslında birçok önemli avantajı vardır. Çalışma bunu açıkça ve çok iyi göstermektedir. Bu, sürekli teslimatın avantajlarını açıkça sunmaya yardımcı olur. Bununla birlikte, sürekli teslimat muhtemelen gümüş mermi değildir. Bununla birlikte, sürekli teslimatın avantajları, yazılımın ve yeni özelliklerin hızlı bir şekilde teslim edilmesinin çok ötesine geçer. Bu nedenle, üretkenlik ve güvenilirlik de önemli ölçüde daha iyi hale geldiği için özellikler daha hızlı üretime girmemesi gerekse bile, bu sektöre yatırım yapmaya değer.
TL; Dr.
Gümüş mermiler en az bir boyutta yazılım gelişimini geliştirmelidir, ancak maalesef orada değiller. Bununla birlikte, sürekli teslimatın güvenilirlik ve üretkenlik için gösterilebilir önemli avantajları vardır.
()