Release sıklığı yazılım kalitesini etkilemiyor!
Facebook mobil uygulaması hakkında yazılan “ Continuous Deployment of Mobile Software at Facebook” makalesini incelediğim serinin üçüncü ve son yazısına hoş geldiniz.
Serinin ilk yazısında Facebook mobil uygulamasının “deployment” süreçlerine değindik.
Serinin ikinci yazısında Facebook mobil uygulamasının test uygulamalarından ve süreçlerinden bahsettik.
Bu yazıda Facebook’un 8 senelik süre zarfında (2009–2016) topladığı datalardan çıkardığı analizleri inceleyeceğiz. Eminim ki analizleri gördüğünüz zaman şaşıracaksınız çünkü genel inanışın aksine çok fazla tespit var.
Önemli not: Bu yazıdaki bütün bilgiler ve grafikler aşağıda linki verilen makaleden alınmıştır.
Makaleye ulaşmak isteyenler şu linki kullanabilir: https://research.fb.com/wp-content/uploads/2017/02/fse-rossi.pdf
1. Toplanan Data
Yapılan analizleri daha iyi anlayabilmek için öncelikle hangi dataların bu 8 senelik süreçte toplandığını anlamamız gerekiyor.
- Revision Kontrol Sistemi Kayıtları
Her commit ve push için yapılan değişikliğin detayları, büyüklüğü ve değişikliği yapan geliştirici bu sisteme kaydediliyor. - Crash veri tabanı
- Mobil uygulamada herhangi bir crash olduğunda otomatik olarak crash raporu gönderiliyor ve veri tabanında kaydediliyor.
- Crash oranı belirli bir eşik değerinin üzerine çıkarsa otomatik olarak task veri tabanında “launch-blocker” issue açılıyor.
3. Flytrop veri tabanı:
- Bu veri tabanında iç veya dış kullanıcılardan gelen issue’lar tutuluyor.
- Issue FB çalışanları tarafından açıldıysa otomatik olarak bu veri tabanına ekleniyor. Kullanıcılar tarafından eklenen issue’lar belirli bir eşik değeri aştıktan sonra veri tabanına ekleniyor.
2. Çıkarımlar
2009–2012 aralığındaki datalar çok fazla gürültü içerdiği için analiz ve çıkarım yapmak daha zor. Bu sebeple daha çok 2012–2016 aralığındaki datalar kullanılmış. (Bu dataların ölçüldüğü zaman aralığında mobil uygulama için çalışan kişi sayısı 15 katına çıkarak 100'den 1500'e çıkmış)
Üretkenlik
Genel olarak yazılım sektöründe üretkenliği ölçmek başlı başına bir problem olduğu için, makale kapsamında kişi başına günlük geliştirilen kod satır sayısı ve kişi başına günlük yapılan push sayısı üretkenlik ölçümlerinde kullanılmış.
iOS ve Android platformları için ortalama olarak bir kişinin günlük olarak geliştirdiği kod satır sayısı 70. Facebook’un diğer yazılımları için bu sayı 64 olarak ölçülmüş.
Günlük kişi başı ortalama push sayısı ise Android için 0.7 iOS için 0.8 olarak ölçülmüş. Aynı miktarlarda kod geliştirilmesine rağmen Android için daha az push olması Android platformu için değişiklik paketlerinin daha büyük olduğunu gösteriyor.
Çıkarım 1: Codebase üzerinde çalışan geliştirici sayısı 15 kat arttırılsa bile üretkenlik sabit kalıyor.
Çıkarım 2: Facebook’un kullandığı continuous deployment süreçleri sayesinde, organizasyon 15 kat büyümesine rağmen üretkenlik olumsuz olarak etkilenmemiş.
Kalite
Facebook uygulamasında herhangi bir sorun olması durumunda bu sorun “Production Issues Database” adı verilen veri tabanına “kritik”, “orta-seviye” veya “düşük-seviye” olarak seviyelendirilip kaydediliyor.
Yazılım kalitesini ölçmek için yoğunlukla bu veri tabanındaki kayıtlar kullanılıyor.
Çıkarım 3: Üründeki kritik hataların sayısı deployment sayısından bağımsız olarak sabit seyrediyor.
Aşağıdaki grafikte 2011 Mart ayı ile 2016 Mayıs ayı arasındaki ay başına yapılan push miktarı ile production ortamında karşılan hata sayısı gösterilmiş.
Bu grafikten de görülebileceği üzere kritik hata sayısı (kırmızı) yapılan push sayısından bağımsız olarak sabit seyrediyor. Makalede bunun 2 nedeni olabileceğinden bahsediliyor:
- Kritik hataların büyük çoğunluğunun test aşamasında yakalanması
- Kritik bir hata ortaya çıkması durumunda hatanın iyi analiz edilip, “root cause” analizi yapılması ve benzer hataların ileride önlenebilmesi için değerlendirme yapılması
“Orta” ve “düşük seviyeli” hatalar push sayısıyla orantılı olarak artış içerisine giriyor. Burada da Android ortamında artış hızının daha yüksek olduğu gözlemleniyor. Bunun potansiyel sebebi olarak Android platformunun çok fazla sayıda değişik donanımda çalıştırılması gösteriliyor.
Facebook şirketinin diğer ürünleriyle karşılaştırıldığı zaman mobil ürünlerdeki hata artış hızının daha yavaş seyrettiği gözlemleniyor. Bu veriye dayanarak Facebook mobil uygulama test süreçlerinin efektif olduğuna karar veriyor.
Çıkarım 4: Deployment çevriminin sıklığı cherry-pick ve launch-blocker sayısını değiştirmiyor.
Facebook ilk başlarda 8 hafta olan deployment çevriminin sıklığını önce 4 haftaya daha sonra 2 haftaya kadar düşüyüror. (Android ortamı için 1 hafta)
Bu çıkarımı yapabilmek için bir deployment kapsamında gün başına düşen “cherry-pick” ve “launch-blocker” sayısı ölçülmüş.
Yukarıdaki grafikte 2 ortam için de deployment sıklığı arttırılmasına rağmen cherry-pick ve launch-blocker sayılarında ciddi bir atış veya azalış olduğu gözlemlenemiyor.
Hangi hatanın “launch-blocker” olarak kategorize edileceği sübjektif bir değerlendirme. Bu kategorizasyon daha önceki yazılarda yazdığımız üzere Release Engineering (RelEng) takımı tarafından yapılıyor. RelEng takımı zaman içinde mobil uygulamanın çokça kullanılmasından ötürü ve takımın da paralel olarak tecrübesinin artmasıyla “launch-blocker” kategorizasyonunun bir standarta kavuştuğunu gözlemliyor.
Ayrıca 2015 ve 2016 yıllarında çok sayıda test tool’unun geliştirildiğini ve bu tool’lar sayesinde yazılım kalitesinin arttığını bu sebeple daha fazla “cherry-pick” yapmaya gerek olmadığını makaleden öğreniyoruz.
Çıkarım 5: Release sıklığının arttırılması kullanıcıların yaşadığı “crash” sayısında bir değişiklik yaratmıyor.
Benim için en ilginç çıkarım bu madde oldu. Genel kanının aksine Facebook release sıklığı ile ürün kalitesi arasında bir ilişki olmadığını gözlemliyor.
Aşağıdaki grafiğe baktığımızda release sıklığının arttırılmasının ortalama olarak kullanıcıların yaşadığı crash sayısına olumlu bir etki yaptığını gözlemleyemiyoruz. (Grafiğin y-ekseni crash ile karşılaşan kullanıcıların toplam aktif kullanıcılara oranının gösteriyor)
Özellikle 2015'in ilk yarısında crash yüzdesinde artış gözlemleniyor ama burada şöyle bir anomali var. O tarihten itibaren Android ortamı için “Java” platformundan kaynaklanan hatalar da crash listesine eklenmeye başlanmış.
Mobil uygulamanın test edilmesinde Facebook içindeki kullanıcıların “dog-fooding” diye adlandırılan süreç kapsamında yaptıkları testler ve geri bildirimleri çok faydalı olmuş. Fakat çalışanların çoğunluğu iOS ortamını kullandıkları için Android ortamı için bu destek sınırlı kalmış. Bu sebeple Android ortamı için Alpha ve Beta release süreçlerine daha çok önem verilmiş.
Alpha sürecinde oluşan crash sayısının bu süreçlerin sonunda son kullanıcıya ulaştığında 10'da 1'ine indiği gözlemlenmiş.
Son Gün Etkisi
Daha önceki yazılarda anlattığımız üzere belirli günlerde Master Branch’inden yeni bir Release Branch’i çıkılıyor. Bu belirli günlerde yapılan push sayısının ciddi manada arttığı gözlemlenmiş.
Çıkarım 6: Son gün yapılan commitlerin kalitesi diğer günlere kıyasla daha düşük oluyor.
Push sayısının artmasıyla birlikte son gün yapılan commitlerin cherry-pick oranının da daha yüksek olduğu gözlemlenmiş.
Bu sebeple daha önce Perşembe olarak belirlenen son gün Pazar gününe çekilmiş. Geliştiriciler hafta sonu daha az commit yapacağı için bu sıkıntının azalacağını düşünmüşler ve bekledikleri gibi olmuş.
Yazılım Kalitesini Etkileyen Faktörler
Yazının buraya kadarki kalite kısmını özetlersek:
- Son gün yapılan commitlerin kalitesi daha düşük oluyor.
- Release sıklığı, geliştirici takımının büyüklüğü ve push sayısının yazılım kalitesine herhangi bir etkisi gözlemlenemiyor.
Bunlara ek olarak aşağıdaki iki maddenin de yazılım kalitesine herhangi bir etkisi gözlemlenemiyor.
- Push kapsamında yapılan değişikliğin büyüklüğü (değiştirilen kod satır sayısı)
- Değiştirilen dosyaların büyüklüğü
Fakat çok daha ilginç bir faktör bulunuyor.
Çıkarım 7: Bir dosya üzerinde aynı release için değişiklik yapan yazılımcı sayısı arttıkça o dosya için yazılım kalitesi düşüyor.
Bir dosyanın kalitesi o dosya üzerinde yapılan cherry-pick sayısı ile ölçülüyor. Aynı dosya üzerinde değişiklik yapan kişi sayısı arttıkça cherry-pick sayısının neredeyse doğru orantılı olarak arttığını gözlemleyebiliyoruz.
Bu çıkarıma bağlı olarak üzerinde çok kişinin değişiklik yapmasını gerektiren dosyaları bölüp daha basit dosyalar haline getirmeyi düşünebiliriz.
Sonuçlar
3 yazılık serimizin sonuna geldik. Sonuç kısmında 3 yazımızdan çıkardığımız sonuçları özetlersek:
- Release sıklığının arttırılması markete daha çabuk çıkabilme, müşteri geri bildirimlerine daha çabuk cevap verebilme gibi avantajlar sağlıyor.
Aynı zamanda bu durum organizasyonu süreçleri otomatikleştirmeye ve kullanılan toolları iyileştirmeye zorluyor. - Yaygın kanının aksine, continuous deployment süreçlerinin üretkenlik ve kalite alanlarında bir etkisi olmadığı gözlemleniyor.
- Mobil uygulama release etmek diğer platformlara göre daha zor çünkü muhtemel hata durumlarında geri almak mümkün değil. Bu sebeple feature flag gibi mekanizmalar kullanılıyor.
Aynı zamanda son kullanıcıya ulaşan hata sayısını azaltmak için Alpha ve Beta release süreçleri efektif bir şekilde işliyor. - Release branch’inin çıkacağı gün aceleyle yapılan commitlerin kalitesi diğer günlere oranla daha düşük kalıyor. Release sıklığının arttırılması bu sıkıntının daha azalmasına yardımcı oluyor.
Bir dosya üzerinde aynı anda çalışan kişi sayısının artışının yazılım kalitesine kötü etkileri gözlemleniyor. Bu sebeple böyle kompleks dosyalar bölünerek daha basit dosyalar haline getirilebilir.
Bu yazıyı yazmama vesile olan Gökhan Topçu’ya teşekkürlerimi sunarım.
Okuduğunuz için teşekkürler. Alkışlayarak ve paylaşarak destek olmayı unutmayın:)
