Facebook mobil uygulamasını nasıl “deploy” ediyor?
Bu yazımı bir serinin ilk yazısı olacak şekilde planladım.
Facebook’un 2017 yılında yayınladığı “ Continuous Deployment of Mobile Software at Facebook” makalesinden aldığım notları ve kendi yorumlarımı paylaşacağım. Makale 12 sayfalık uzun bir makale ve özümsenerek okunması, çıkarımlar yapılması gerektiğine inanıyorum. Makale kapsamında Facebook’un mobil uygulaması için nasıl yazılım geliştirildiği, uygulamanın nasıl deploy edildiği ve nasıl test edildiği ayrı bölümlerde detaylı olarak anlatılmış. Ayrıca Facebook’un 8 senelik datası detaylı olarak incelenip, çıkarımlarda bulunulmuş.
Serinin ilk yazısında “deployment” başlığı altındaki makale notlarımı ve yorumları paylaşacağım. (Önemli not: Bu yazıdaki bütün bilgiler 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
Aklınıza şöyle bir soru gelebilir. 2017 yılındaki makaleyi neden şimdi inceliyorsun? Makaleyi farketmem Gokhan Topcu’nun twitleri sayesinde oldu. Bir yazılım mühendisi olarak Gökhan Topçu’yu twitterda takip etmenizi önerebilirim. Hem iş ahlakı hem de yazılım mühendisliği konularında ilgi çekici paylaşımlarda bulunuyor.
İlgili thread’e ulaşmak isteyenler için linki bırakıyorum:
Continuous Deployment Nedir?
Continuous Deployment, yazılıma eklediğimiz yeni özelliklerin otomatik bir şekilde sık sık son kullanıcıya ulaştırılması işlemidir. CD kısaltması söz konusu olduğunda akla gelen diğer bir kavram da “Continuous Delivery” oluyor. Continuous Delivery ile kullanıcıya dağıtılabilecek yazılım paketleri otomatik olarak hazırlanıyor ama kullanıcıya dağıtılmıyor. İkisi arasında kullanıcı ortamına dağıtma konusunda bir fark var. İkisi arasındaki farkı daha detaylı inceleyebilmek için aşağıda verdiğim linki inceleyebilirsiniz.
Büyük yazılım şirketleri “Continuous Deployment” yapabilmek için çokça mesai harcıyor, peki faydaları neler?
- Sık sık güncelleme çıkıldığı için daha küçük güncellemeler çıkabiliyoruz ve bu sayede risk azalmış oluyor. Çıkılan güncelleme paketleri küçük olduğu için hata durumunda back-up mekanizmaları da daha kolay uygulanabiliyor.
- Yazılım dünyasına aşina iseniz “Agile” kavramını duymuş hatta bir eğitim bile almışsınızdır:) “Agile” kavramının ana felsefesi müşterinin değişen isteklerine çevik bir şekilde cevap verebilmeye dayanıyor. Continuous Deployment ile son kullanıcıya sıklıkla güncelleme verildiği için kullanıcıdan geri bildirim almak hem daha sık hem de daha kolay oluyor. Bu sayede “fail” edeceksek kısa sürede etmiş oluyoruz ve kısa sürede hatamızdan ders alıp onu düzeltme şansımız oluyor (“Fail fast to learn fast”).
Mobil vs Bulut
Makalenin giriş kısmında “Continuous Deployment” kavramının mobil ve bulut ortamındaki farklarına değiniliyor. Aslında bu makalede Facebook daha önce (2016 yılında) yayınladıkları “Continuous Deployment at Facebook and OANDA” makalesine atıflarda bulunuyor ve mobil ortam ile bulut ortamı için deployment süreçlerinin farklılığından bahsediyor. (2016 yılında yayınlanan makalede Facebook ve OANDA şirketinin bulut ortamı için “continuous deployment” süreçleri anlatılıyor. )
2016 yılında yayınlanan ilgili makalenin linki (Ücretsiz olarak indirebilirsiniz): https://www.researchgate.net/publication/303296480_Continuous_deployment_at_Facebook_and_OANDA
(Not: Facebook uygulamasını bulut ortamında tuttuğu için bulut ortamından web uygulamasını, mobil ortamdan da telefonlarımızdaki mobil uygulamayı anlayabilirsiniz.)
Makalede değinilen mobil ortam ile bulut ortamı arasındaki farklar:
- Bulut ortamında kullanıcı rahatsız olmadığı için aslında hiç fark etmediği için çok sayıda küçük ve artırımlı (incremental) güncellemeler yapabiliyorsunuz.
- Bulut ortamı hatalı bir güncelleme paketinin risklerini yönetmek için çok sayıda özellik sunuyor. Bazılarını örnek vermek gerekirse
- Blue-green deployment ( https://martinfowler.com/bliki/BlueGreenDeployment.html)
2. Feature flags ( https://martinfowler.com/articles/feature-toggles.html)
- En kötü senaryoda, bulut ortamı güncellemenizi tamamen geri alarak bir önceki versiyona dönebilme şansını size sunuyor.
Mobil ortamda ise aşağıda anlatılan sebeplerden dolayı “continuous deployment” yapmak çok daha zor hâle geliyor.
- Güncellemeler kullanıcının göreceği ve yüklemek işin onay vereceği şekilde dağıtılıyor. Bu şartlar altında kullanıcıyı çok rahatsız etmemek için sık güncellemeler yapılamıyor.
- Yapılan güncellemeler, güncellemeyi sunduğunuz platform tarafından review edildiği için süreç uzayabiliyor. Örnek olarak iOS uygulamasında yaptığımız güncellemeleri Apple review ediyor.
- Güncellemeler küçük paketler hâlinde ve arttırımlı (incremental) olarak değil de tek büyük bir paket halinde yüklenmek zorunda. Bu da riski arttırıyor.
- Riski yönetebilmek için kullandığımız mekanizmalar sınırlı. Örnek olarak hotfix ve roll-back uygulamak için çok istisnai koşulların oluşması gerekiyor ve ancak platform sahibiyle iş birliği içinde bu mekanizmalar kullanılabiliyor.
- Mobil ortamdaki kullanıcılar güncellemeyi ne zaman yükleyeceklerine kendileri karar verdikleri için (yüklerlerse tabi) aynı anda birden çok versiyon canlı ortamda bulunabiliyor.
- Özellikle Android platformu için çok sayıda donanıma destek verilmesi gerektiği için gün geçtikçe deployment yapmanın riski artıyor çünkü basit bir kartezyen çarpımıyla uygulama versiyonları * (işletim sistemi tipi * versiyonu) * donanım platformu kadar olasılık oluşuyor.
Gatekeeper
Deployment sürecinin nasıl yönetildiğine geçmeden önce Facebook’un kendi içerisinde uygulanmasını teşvik ettiği bir kodlama prensibinden bahsetmek istiyorum.
“Gatekeeper” dedikleri mekanizma ile Facebook, mobil uygulaması için featureların erişilebilirliğini dinamik olarak yönetiyor. Bu mekanizma ile server-side tarafından mobil uygulamadaki featurelar açılıp kapatılabiliyor.
“Gatekeeper” sayesinde
- Herhangi bir özellik bekledikleri gibi davranmazsa özelliği kapatabiliyorlar.
- Hedefledikleri platformlarda istedikleri özellikleri açıp/kapatabiliyorlar. (Platformlar olarak yukarıda verilen kartezyen çarpımının değişkenlerini düşünebilirsiniz.)
- Alpha ve beta testleri yapabiliyorlar.
Deployment Süreçleri
Facebook içerisinde deployment süreçlerini yönetebilmek için “Release Engineering Team (RelEng)” adını verdikleri bir takım var. Bu takımda hedeflenen platformdan (iOS,Android) sorumlu olan proje yöneticileri var. RelEng takımı hangi konuların “launch blocking” olup olmadığına karar verebiliyor.
Facebook gibi dev bir mobil uygulamanın deployment süreçlerini yönettikleri için bu takımın çok sayıda kişiden oluştuğunu düşünebilirsiniz ama en azından makalenin yayınlandığı yıl (2017) itibariyle bu takım 10 kişiden oluşuyor. Böyle küçük bir takımla bu süreci yönetebilmelerinin sebebi olarak 2 noktaya değinmişler.
- Süreçteki otomasyon kullanımın yoğunluğu
- RelEng takımının yıllar içinde geliştirme (development) takımı ile kurduğu iyi iş birliği
RelEng takımı ile geliştirme takımı arasındaki iş birliğini geliştirebilmek için uyguladıkları bir pratikten bahsediyorlar. Bu pratiğe göre, geliştirme takımından “senior” geliştiriciler iki ayda bir “deployment” süreci yönetilirken RelEng takımına katılıyor. Bu sayede hem geliştirme takımı RelEng takımının bakış açısını daha iyi anlayabiliyor hem de RelEng takımı geliştirme takımını. Ek olarak da bu sayede geliştirme takımının RelEng takımının süreci daha iyi yönetebilmesi için, RelEng takımına otomasyon uygulamaları geliştirip deployment sürecini kolaylaştırdığını belirtiyorlar.
Facebook yaptığı iyileştirmeler ile 4 yıl içinde mobil uygulama için “release” sıklığını Android platformu için 8 haftadan 1 haftaya, iOS platformu için 2 haftaya düşürmüş.
Hem iOS hem de Android platformu için, Facebook mobil uygulamasını tarihleri belli olan çevrimlerle pipelinelı bir yapıda deploy ediyor.
iOS Platformu için Deployment
Mobil veya web ortamı farketmeksizin Facebook’da Master ve Feature branch şeklinde bir branch yapısı var. Master ortamından çıkan geliştiriciler oluşturdukları Feature branchlerde geliştirmelerini yapıyorlar ve daha sonra Master’a birleşebilmek için merge talebinde bulunuyorlar. Code review aşaması geçildikten sonra da yazılan kod parçası Master branchine birleşmiş oluyor.
- RelEng takımı 2 haftada bir Pazar günü öğleden sonra 6'da Master branchini kesip yeni bir Release branchi oluşturuyor.
- Release branchi oluşturulduktan sonraki 5 güne “stabilizayon” dönemi diyorlar. Bu dönemde karşılaşılan hataların bazıları düzeltiliyor ve “stabilizayon” güncellemeleri uygulanıyor.
- RelEng takımının “launch blocking” olarak kategorize ettiği hataların deployment sürecinden önce çözülmesi gerekiyor çünkü bu hatalar uygulamanın kullanıcıya ulaşmasına engel olacak hatalar.
- RelEng takımının ortaya koyduğu bütün konulardan geliştirici takımı sorunlu. Örnek olarak RelEng takımı bir hata bulursa sorumluluk geliştirici takımında oluyor.
- Hata durumlarında, geliştiriciler ilgili güncellemeleri yapıp Master branchine atıyor ve RelEng takımına değişikliğin Release branchine alınması için talepte bulunuyorlar.
- Release branchine güncelleme talebi yapıldıktan sonra RelEng takımı “cherry-picks” yaparak uygun gördüğü güncellemeleri Release branchi ile birleştiriyor. Yapılan güncelleme çok fazla bağımlılık içeriyorsa veya çok kritik kod parçalarında değişiklik yapıyorsa RelEng takımı tarafından reddedilebiliyor.
- “Stabilizasyon” sürecinde mobil uygulamadaki güncellemeler Facebook’un iç (internal) kullanıcı olarak tanımladığı kullanıcılara erişilebilir hâle geliyor. Bu süreçte iç kullanıcılara günde 3 defa güncelleme yapılıyor.
- 5 günlük “stabilizasyon” süreci bittikten sonra kod donduruluyor ve 3 günlük “soak” süreci başlıyor. Bu 3 günlük süreçte sadece “launch blocking” kategorisine giren hatalar için yapılan güncellemeler kabul edilebiliyor.
- 8 günlük süreç bittikten sonra, güncellemeler Apple platformuna deploy ediliyor. Apple güncellemeleri review ettikten sonra aynı hafta içinde, güncellemeler son kullanıcıya ulaşmış oluyor.
Android Platformu için Deployment
2 haftalık iOS deployment sürecinin 1 haftaya sıkıştırılmış hali olması dışında, Android platformunda da süreç aynı şekilde işliyor.
- Perşembe günleri Release branchi oluşturuluyor ve kod donduruluyor. Sadece “launch blocking” kabul edilen hatalar için merge talepleri kabul ediliyor.
- 1 haftalık sürecin ardından uygulama bir süreç şeklinde canlı ortama koyuluyor. Öncelikle “Play Store” kullanıcılarının %20'si daha sonra %50'si ve 3 günlük stabilizasyon süreci olumlu şekilde sonuçlanırsa kullanıcıların %100'ü ulaşacak şekilde parçalı bir deployment yapılıyor.
- Android ortamı için iOS ortamına ek olarak Alpha ve Beta testleri de yapılıyor. Alpha testi için Master branchinden günde bir defa olmak üzere 10000'lerle sınırlı kalacak sayıda kullanıcıya güncellemeler ulaştırılıyor. Beta testi için Release branchinden günde bir defa olmak üzere 3 milyon kullanıcıya ulaşabilecek bir şekilde güncellemeler ulaştırılıyor.
Sonuç
Bu yazıda Facebook tarafından yayınlanmış bir makaleden aldığım notları sizinle paylaştım. Bu yazı kapsamında
- Mobil ortam ile bulut ortamı arasında deployment kapsamında farklar olduğunu ve mobil ortamda “continuous deployment” yapmanın zorlu bir süreç olduğunu
- Facebook’un kendi geliştirdiği bir mekanizma olan “Gatekeeper” ile istediği özellikleri server tarafından açıp/kapatabildiğini veya sadece hedeflediği kullanıcılara bazı özellikleri dinamik olarak açabildiğini
- iOS ve Android ortamları için deployment sürecinin adım adım nasıl ilerlediğine değindik.
Bir sonraki yazımda aynı makaleden aldığım notlar kapsamında Facebook’un mobil uygulamasını nasıl test ettiği konusuna değineceğim.
Zaman ayırarak bu yazımı inceleyen ve geri bildirimleriyle destek olan Gokhan Topcu’ya teşekkür ederim.
Okuduğunuz için teşekkürler. Alkışlayarak ve paylaşarak destek olmayı unutmayın.
