Yavaş Dağıtımın Yol Açtığı Toplantılar (2015)

Yavaş Dağıtımın Toplantı Yaratması

• Yazılım tasarımı insan ilişkilerini geliştirmenin bir pratiğidir. Yazılım geliştirmede kullandığımız diğer teknikler de böyledir.
• "Kodu dağıtamayacak kadar toplantı var" şeklindeki bir mühendisin şikâyeti, dağıtım kapasitesinin sınırına bağlı olarak ortaya çıkabilir.
• Chuck Rossi, Facebook’ta bir dağıtıma uygulanabilecek değişiklik sayısının sabit olduğunu gözlemlemiş. Daha fazla değişiklik istiyorsanız, bunun için daha fazla dağıtım yapmanız gerekir.
• Facebook, son 5 yılda dağıtım hızını haftalıktan günlük dağıtıma, ardından günde üç defaya çıkardı; mobil uygulama dağıtım döngüsü de 6 haftadan 4 haftaya, sonra 2 haftaya indi.
• "Dağıtıma göre değişiklik sayısı" esnek olmayan bir metriktir; iyileştirilebilir ama zaman alır. Mevcut eşiğin üstüne çıkarsa değişiklik sayısını düşürmek gerekir.
• Kurumsal yük artışı, olumlu bir geri besleme döngüsünü başlatır: iş yükü azalır → baskı artar → hatalar artar → dağıtıma başına düşen değişiklik azalır → yük artar → iş yükü azalır.
• Daha fazla değişiklik işlemek için dağıtım kapasitenizi artırmanız gerekir. Ya dağıtım döngüsünü kısaltmalı ya da dağıtıma düşen değişiklik sayısını yükseltmelisiniz.
• Yükü azaltma çabası sonuçta toplantılara dönüşebilir. Bu da bir seferde çok fazla kod dağıtma girişimini engeller.

Yazılım Tasarımı: Tidy First?

• Yazılım tasarımı insan ilişkilerini geliştirmenin bir pratiğidir. Yetenekleri geliştirmek bu ilişkileri geliştirmek için bir yol olarak görülebilir.

[roxie]

Bu yorum çok iyi.

[GN⁺]

Hacker News Yorumları

• Dağıtım riskini azaltmak için testleri ve organizasyonel özellikleri geliştirmek önemli ama tek başına tek yaklaşım değil

  • Dağıtım başına değişiklik sayısını azaltmak daha etkilidir
  • Küçük değişiklikleri sık sık dağıtmak değeri daha hızlı iletmenizi ve küçük hatalarla karşılaşmanızı sağlar
  • Canary dağıtımı ve kademeli rollout ile birleştirildiğinde dağıtım artık büyük bir risk olmuyor
  • DORA araştırması, Accelerate, The Phoenix Project ve The Goal’da bu yaklaşımı destekliyor

• "Yazılım okuryazarlığı" kavramını açıklamaya çalışıyor

  • Şirketin kodla çalıştırılabilme yeteneğini ifade eder
  • Tüm karar vericiler kodla iş yapmıyorsa, o şirket yazılım okuryazarlığına sahip değildir
  • Şirket yeni bir kavramla işletilebilir olmalıdır

• CI hattında test süresi uzayınca, toparlanmaya odaklanmaya karar verdiler

  • Testleri sadeleştirip toparlanmaya odaklanarak dağıtım stratejisi olarak canary kullandılar
  • Bu yaklaşım taze bir deneyimdi

• Organizasyonlar dağıtım iyileştirmeye engel olabilir

  • Bureaucracy (bürokrasi) ile savaşmak çoğu organizasyonda imkânsız
  • Yavaş dağıtım bir sorundur ama tek sorun değildir

• Büyük değişikliklerden korkulduğunda test artar

  • Toplantıların hedef haline gelme eğilimi vardır
  • Teknik olmayan yöneticiler için teknik değişimi nasıl yöneteceklerine dair tavsiyeye ihtiyaç var

• CloudFormation’ın neden bu kadar yavaş olduğu konusundaki soru

• Mikroservisler dağıtım sıklığını yatayda ölçeklendirmeyi mümkün kılar

• Yazılım performansı, yani insan performansı önemlidir

  • Hızlı yineleme ve risk azaltımı için hızlı test otomasyonu gerekir

• Hızlı dağıtım, olay müdahale toplantılarını tetikler