Ekip veya uygulamanın boyutu yayınlanma sürecini etkiler mi? Duruma göre değişir. Küçük bir ekipten oluşan bir startup hayal edelim. Bu durumda ekip genellikle bir özellik hazırlar ve ardından onu yayınlar. Şimdi, birçok ekibin üzerinde çalıştığı büyük bir projeyi, örneğin bir bankacılık uygulamasını hayal edelim.

Bu durumda muhtemelen bir süreç, yayın döngüleri ve belki de bir miktar bürokrasi olması gerekir. Bu olmazsa kaos olur.

Peki uygulamanız için böyle bir süreç kurmanın zamanı geldiği ne zaman belli oluyor?

Bu makalede, Dodo Pizza uygulaması (Android ve iOS) için Release Train'i uygulama deneyimimi ve ekibimizin Release Train'i uygulamasına neden olan karşılaştığımız sorunları paylaşacağım.

Hızla büyüyen bir Android veya iOS projesinin Takım Lideri/Teknik Lideri iseniz ve henüz yayınlanma sürecini yönetmediyseniz, deneyimlerimizin size yardımcı olacağını umuyorum.

Eskiden Nasıldı

2021 yılında ekiplerimizde zaten Trunk Tabanlı Geliştirme (TBD) yaklaşımını kullanıyorduk. Kodu, özellik geçişleri, ayrıştırılmış görevler ve çalıştırılan birim ve kullanıcı arayüzü testleri ile ele aldık. Özellik dallarımız uzun ömürlü olmadı ve CI çalışmamız vardı.

Yayınlama süreci çok basitti: Özelliğini kullanıma sunmaya hazır olan kişi, onu kullanıma sundu.

İdeal Senaryo

Şube iş akışımızın kabaca nasıl göründüğünü burada bulabilirsiniz. Birkaç ekip (gri, mavi, turuncu ve yeşil) farklı özellikler üzerinde çalıştı. TBD'ye göre çalıştığımız için her özellik birbirini takip eden birkaç dalda yaşayabiliyordu.

Örneğin gri takım 4 adımda, mavi ve turuncu takımlar 1 adımda, yeşil takım ise 2 adımda kendi özelliğini yaptı.

Bir ekip bir özelliği tamamladığında bir sürüm yayınlayabilir. Örneğin mavi takım bir filmi bitirirse bir yayın yapabilir. Ardından turuncu takım bir filmi bitirip başka bir yayın yapacaktı.

O zamanlar göründüğü gibi mükemmel bir akışa sahiptik. Bir noktaya kadar harika çalıştı ama her güzel şeyin bir sonu vardır.

Bir şeyler ters gitti: zorlu, kalabalık ve öngörülemez

Mamut

Karşılaştığımız ilk sorun, sürümlerin birçok özelliği biriktirmeye başlaması ve çok büyük hale gelmesiydi.

Ekipler her zaman özelliklerini hemen yayınlamak istemedi. Serbest bırakma ve gerileme süreci zaman alıcıydı ve 3-4 gün sürdü. Dolayısıyla, özelliğiniz küçükse ve acil değilse, onu her zaman kendiniz yayınlayamıyorsunuz çünkü muhtemelen başka bir ekip yakın zamanda bir sürüm yayınlayacak ve bu sürüme dahil edilecek. Kabaca şöyle görünüyordu:

Bu oldukça kırılgan bir düzenlemeydi, özellikle de takım sayısı artmaya başladığında. Birçok ekip birçok küçük özellik geliştirdi ve her yeni sürümdeki toplam yeni kod hacmi çok büyük hale geldi. Birisi büyük filmini yayınlayacağı zaman, onunla birlikte bütün bir mamutu da yayınlamak zorundaydı.

Devasa sürümler şunlarla sonuçlandı:

• gecikmiş regresyon;

• daha yüksek regresyon hatası riski;

• üretimde hata alma riski daha yüksektir.

Örnekteki mavi ve turuncu takım yayın yapmak istemese bile yayının bir şekilde yapılmasını sağlayacak şekilde bunu yapmamız gerekiyordu.

Darboğazlar

Her takım benzersizdir ve her özellik farklıdır. Bazen olaylar öyle oluyordu ki, birkaç takım aynı anda özelliklerini tamamlıyordu. Bu durumda, bir sürü "beni bekle, yarın sabah birleştireceğim, söz veriyorum!" etrafta dolaşmak.

Sonuçta bu tür darboğazlar şunlarla sonuçlandı:

• mamutlara dönüşen salınımlar;

• gecikmiş sürümler, özellikle herkesin ihtiyaçları karşılanıyorsa, yayınlayan ekibin planlarını olumsuz etkiler.

2 önemli değişiklik yapmamız gerekiyordu:

1. Yayınlayan ekibin kimseyi beklemesine gerek yok;

   
   

2. diğer tüm takımlar bir sonraki sürümün ne zaman beklendiğini bilmeli.

Tahmin Edilebilirlik Eksikliği

Düşünün, mavi takım küçük bir özellik yaptı ve turuncu takımın bunu yakında yayınlamasını bekliyordu. Ancak bir şeyler ters gitti ve turuncu takım da kendi sorunları nedeniyle sürümü yayınlamadı.

Sonuç olarak mavi ekip, işletmeye bu özelliğin yakında üretime geçeceğini söyledi ancak bunun yeterince yakında olmadığı ortaya çıktı. Sonuç olarak özelliğin ne zaman üretime geçeceğini tahmin etmek imkansız.

Bu, mavi takımın sorumsuz olduğu anlamına gelmiyor. Eğer çok önemli veya acil bir özellikleri varsa elbette bunu kendileri yayınlayacaklar. Ancak diğer durumlarda özelliğin kullanıcılara tam olarak ne zaman sunulacağını söylemenin bir yolu yoktur.

Tahmin edebileceğiniz gibi bu tür sorunları oldukça sık yaşıyorduk. Boyutuna veya aciliyetine bakılmaksızın müşterilerin bir özelliği üretimde ne zaman alacağını tam olarak söyleyebilmemiz gerekiyordu. Bu 3 sorunun tümü (devasa salınımlar, darboğazlar ve öngörülebilirlik eksikliği) birbiriyle yakından ilişkilidir ve birbirini tamamlar.

Ancak muhtemelen bunların en temel ve önemlisi öngörülebilirliğin olmayışıdır. Başka sorunlar yaratır.

Treni Serbest Bırak

Yeterince yaşadık; değişiklik yapmanın zamanı gelmişti. Yayın Treni'nin bunu yapmamıza yardım etmesi gerekiyordu.

Sürüm Treni terimi farklı anlamlara gelir: planlanmış bir sürüm süreci veya sürüm sürecini yöneten özel bir ekip . Burada, planlanan yayın sürecinden bahsedeceğiz.

Release Train'in Martin Fowler tarafından “ Kaynak Kodu Dallarını Yönetme Modelleri ” makalesinde anlatılma şeklini ve Thinkworks'ün teknoloji radarında verdiği tanımı (belki de Martin'e aittir) beğendim.

Release Train'i kendimiz için şu şekilde tanımladık:

Yayın Treni, yayınların ekipler arasında koordine edilmesi sürecidir. Tüm sürümler, özelliklerin hazır olup olmamasına bakılmaksızın sabit bir programa göre gerçekleşir. Tren kimseyi beklemiyor. Geç kalırsanız bir sonrakini beklemek zorundasınız.

Renk kodlu ekiplerimizi kullanarak birkaç örnekle konuyu detaylandıralım.

Mamut Sorununu Çözmek

Sürüm Treni programa uygun olarak gerçekleşir ve kimin neyi ana şubeyle birleştirdiğine bağlı değildir. Aşağıdaki örnekte mavi ve turuncu takımların özellikleri yayınlanacaktır. Geri kalanlar bir sonraki treni bekleyecek. Biraz daha bekleyebilirdik ama sonra bir mamut elde ederiz.

Darboğazları Çözme

Release Train aynı zamanda işimizi daha verimli planlamamıza da yardımcı oluyor. Diyelim ki mavi takım başlangıçta bir filmi daha sonra bitirmeyi planladı. Ancak çıkış tarihini herkes bildiği için özelliği erken bitirmek için planlarını biraz yeniden düzenleyebilirler.

Ya da tam tersi bir sonraki trene kesinlikle zamanında yetişemeyeceklerini anlayıp, tüm tarifeyi bildikleri için bu özelliği güvenli bir şekilde bitirebilirler.

Aşağıdaki örnekte mavi takım, sürüme ulaşmak ve tüm değişikliklerini sürümden önce birleştirmek istiyordu. Aksi taktirde darboğaz yaşanabilir.

En önemlisi, Release Train bize tasarım açısından öngörülebilirlik kazandırdı .

Bu örnekler bazılarına çok açık gelebilir ama biz sorunları ortaya çıktıkça çözdük. Sürümlerde herhangi bir sorun olmadığında Release Train'i kullanma zahmetine girmedik. Sorunlar birikince zamanın geldiğini anladık.

Sürüm Trenini Ekibinize Nasıl Uygulayabilirsiniz?

Yaptığımız ilk şey bir RFC yazmaktı. RFC, hem sürecin kendisini hem de birçok şirketin bir proje üzerinde çalışmaya başlamadan önce kullandığı tasarım belgesini ifade eder. Bazıları RFC'leri özel olarak kullanır, bazıları ADR'leri kullanır ve bazıları bunları daha genel bir terim olan Tasarım Belgesi olarak adlandırır.

Dodo Mühendislik olarak hem RFC'leri hem de ADR'leri kullanıyoruz.

RFC sürecimiz şöyle görünüyordu:

1. Bir RFC belgesi taslağı hazırladık;

   
   

2. bunu küçük bir grupta tartıştık, yorumları topladık ve düzeltmeler yaptık;

   
   

3. daha sonra RFC daha geniş bir gruba iletildi;

   
   

4. sonra bunu uyguladık;

   
   

5. sonrasında geri bildirim topladık, ölçümleri takip ettik ve sonuçları değerlendirdik.

Yayın Trenimiz için RFC belgesinin yapısı aşağıdaki gibidir:

• Yayın Treni sürecinin açıklaması;

• hangi ekipler katılıyor, ne yapıyorlar;

• programın ne olacağı;

• Metrikler.

RFC taslağını hazırlarken diğer şirketlerin deneyimlerinden yararlandık:

• SkyScanner
• ses bulutu
• Monzo
• Facebook

İlk Uygulama

Öncelikle şu süreci belirledik:

• her hafta yayınlayın;

• Çarşamba sabahı bir sürüm şubesi oluşturun;

• gerilemeyi tamamlayın ve uygulamayı Cuma günü incelenmek üzere gönderin;

• Pazartesi günü sürümü yayınlamaya başlayın.

• Yayın ekibi:

  • Özellik ekiplerinden birinden 1 iOS ve 1 Android geliştiricisi;

  • 2 kalite kontrol mühendisi.

    
    

• Çarşamba günü yeni bir sürüm şubesi oluşturun;

• Her takımın serbest bırakma sırasının ne zaman geldiğini belirten bir çeyrek ileriye bir program yapın. Üç ay sonra bir araya gelin ve programı uzatın.

Şematik olarak Yayın Trenimiz şuna benziyordu:

Her şey yolunda gitmedi

Bir ay sonra, ilk deneyimin harika hissettirmesine rağmen,

• Her hafta bir gerileme yapıp Cuma gününe kadar bitirmek gerçekten zordu;

• düzeltmeler için zaman yoktu ve bunlar bazen oluyordu.

2021 yılında regresyon testimiz ortalama 3-4 gün sürüyordu. 2022'de bu süreyi 2-3 güne indirmeyi başardık ama bazen bu süreyi aşıyordu. Regresyon vakalarını e2e testleriyle ele almaya devam ettik ancak henüz %100 kapsamı elde edemedik. Her platformda regresyon vakalarının sırasıyla yaklaşık %70 ve %60'ını kapsıyorduk.

Bundan çıkarılacak sonuç , tamamlanması birkaç gün süren regresyon testleriniz olduğu sürece, her hafta bir sürüm döngüsü çalıştırmanın muhtemelen rahatsız edici olacağıdır.

Son Cevap

Sonunda 2 haftalık sürüm döngülerine geçtik ve Sürüm Treni artık şu şekilde görünüyor:

• her 2 haftada bir yayınlanır;
• Çarşamba sabahı bir sürüm şubesi oluşturun;
• gerileme ve uygulamayı Cuma günü incelenmek üzere gönderme;
• Pazartesi günü sürümü yayınlamaya başlayın.

• Yayın ekibi:

  • Özellik ekiplerinden birinden 1 iOS ve 1 Android geliştiricisi;

  • 2 kalite kontrol mühendisi.

    
    

• Her takımın serbest bırakma sırasının ne zaman geldiğini belirten bir çeyrek ileriye bir program yapın. Üç aylık dönemden sonra bir araya gelin ve programı uzatın.
• sürümü kademeli olarak yayınlayın;
• gerekirse düzeltmeleri şimdi, vaktimiz olduğunda yapın;
• bir hafta sonra Çarşamba günü yeni bir sürüm şubesi oluşturun.

Her şey planlandığı gibi giderse süreç şöyle görünür:

Potansiyel düzeltmeler için yeterli zamanın kalması dışında her şey haftalık bir döngüye benziyor. Genişletilmiş regresyon testleri durumunda şöyle görünecektir:

Önemli de değil; düzeltmeler için bile hala zaman var.

Yeni Süreç Öngörülebilirliği Nasıl Etkiledi?

Bizim için asıl amaç öngörülebilirliği artırmaktı . İki parçaya ayrılabilir:

1. Uygulama ne zaman yayınlanacak;
2. Özelliğim hangi sürümde yer alacak?

“Ne zaman yayınlanacak?” sorusunu yanıtladık. Sürüm Treni sürecini uygulayarak. Artık her takım "özelliğim hangi sürümde yer alacak?" sorusuna cevap verebilecek. özelliği planlayıp değerlendirdikleri anda bağımsız olarak.

Daha önce kesin olarak söylemek imkansızdı çünkü yayını başka bir ekip yapabilir ya da yapmayabilir. Artık her şey o takımın kendi planlamasına bağlı.

Bunu daha da doğrulamak için mobil geliştiriciler, QA ve ürün yöneticileri arasında anketler düzenledik ve diğer sorularla birlikte şunları sorduk:

• Bir sonraki sürüm ne zaman? (Bu soruyu %100 yanıtladı).

• Release Train ekip çalışmanızı planlamanıza yardımcı oldu mu? (%75'i olumlu yanıt verdi, ancak bazıları Yayın Treni olmadan bile çalışmalarını mükemmel bir şekilde tahmin etti).

Release Train ayrıca kod donmaları ve sürüm donmaları konusunda da bize yardımcı oldu. Yılbaşı gecesine ek olarak bunlardan birkaçı da vardı (örneğin, 1 Eylül ve bazı tatiller). Artık Sürüm Treni ile sürüm dalları oluşturarak, regresyon testleri vb. yaparak bu tarihlere uyum sağlamamıza gerek yok. Çalışmayı programa uygun olarak yayınlar; bunları daha sonra mağazalarda açıyoruz.

Metrikler Üzerindeki Etki

Sorun çözmenin ötesinde metrikleri de ölçtük. Başlıcalarına bir göz atalım.

Kurşun zamanı

Ölçtüğümüz ilk önemli ölçüm , yayınlamaya yönelik Teslimat Süresi taahhüdüydü .

Grafik böyle görünüyor. Sürüm Treni sürecini başlattığımız noktayı okla işaretledim.

Grafik, Teslim Süresinin yaklaşık altı güne düştüğünü gösteriyor. Altı gün uzun bir süre mi yoksa kısa bir süre mi?

Google Karşılaştırmaları

Var bu metrik için Google'ın karşılaştırmaları , ancak çoğunlukla arka uç içindir. Ölçeklerine göre aşağıdaki grupları ayırt ediyorlar:

• Elit: bir saatten az
• Yüksek: 1 saatten 1 haftaya kadar
• Orta: 1 haftadan 6 aya kadar
• Düşük: 6 ay veya daha fazla

Standart mobil uygulamalar için teslim süresinin ideal olarak sürüm döngüsünün yarısını hedeflemesi gerektiğine inanıyorum. Bu, her gün bir görevi ana dalda birleştirmeye eşdeğerdir. Bununla birlikte, yayın döngüsü 14 gün ise Teslim Süresinin 7 günü hedeflemesi gerekir .

Regresyon Başına Hatalar

Takip ettiğimiz bir diğer ölçüm ise regresyon başına hata sayısıdır. Sürüm adayının ne kadar kararlı olduğunu açıklar. Önceki sürüm uzun zaman önceyse, muhtemelen çok sayıda hata içerebilecek çok sayıda yeni kod oluşturduk ve regresyon ve düzeltmelere daha fazla zaman harcayabilirdik.

Bir noktada bu ölçüm üç hataya düştü. Spesifik rakamlar o kadar önemli değil, ancak genel olarak trendin düştüğünü görebilirsiniz.

Daha Fazla Metrik

Sürüm Treni'nin bir parçası olarak hangi ölçümlerin de izlendiğini kısaca tartışacağım.

• Kilitlenmesiz. Bu ölçüme her zaman dikkat ediyoruz. Gerilemeyi daha sıkı bir zaman dilimine sığdırma çabalarımız nedeniyle düşeceğine dair bir hipotez vardı. Neyse herhangi bir düşüş olmadı.

• Sık (haftalık) sürümlerin, müşteri kaybı ve uygulamanın silinmesi üzerinde bir etkisi olup olmayacağını merak ettik. Sonuç olarak herhangi bir etki tespit etmedik.

Uygula, İyileştir

Hedeflerine ulaştığını düşündüğümüz için mevcut süreci beğeniyoruz. Bunu nasıl daha da geliştirebileceğimizi de biliyoruz:

• Regresyon işlemini daha basit ve daha hızlı hale getirmek için otomatikleştirme üzerinde çalışmaya devam ediyoruz.

• Şimdiye kadar iş otomasyonu (dallanma komut dosyaları) kısmını dışarıda bıraktık, ancak bu aynı zamanda gelecekte büyük bir büyüme noktası olacaktır.

• Uygulamamız 20 ülkede çalışıyor ve uygulamayı birçok farklı dile çevirmemiz gerekiyor. Bunun için dahili bir hizmet var ancak geliştiricilerin yine de yayınlanmadan önce bu sürece manuel olarak katılmaları gerekiyor. Bu sürecin otomatikleştirilmesi, sürüm döngüsünü daha da iyileştirebilir.

Özet

Nispeten küçük olsak da Yayın Trenine ihtiyacımız yoktu. Sürümleri, boyutlarını ve sayısını tahmin edemediğimiz gerçeğiyle karşı karşıya kaldığımızda Sürüm Trenini uygulamaya karar verdik. İlk başta haftalık sürüm döngülerini denedik ancak zaman alan gerilemeler nedeniyle iki haftalık sürüm döngülerine geçmek zorunda kaldık. O zamandan beri bu şekilde yaşıyoruz.

Artık yayınların öngörülebilirliği var ve ölçümler olumlu dinamikler gösteriyor. E2e testleri ile regresyon vakalarının kapsamını artırmayı, şubelerle çalışma sürecini otomatikleştirmeyi ve çeviri sürecini optimize etmeyi planlıyoruz.

Bu makalenin ve deneyimlerimizin size yardımcı olacağını umuyorum, özellikle de benzer sorunlarla zaten karşılaştıysanız ve sürüm süreci hakkında düşünmenizi sağladıysa.

Makalemi okuduğunuz için çok teşekkür ederim. Umarım keyif almışsınızdır. Herhangi bir sorunuz veya öneriniz varsa, yorumlara bana bir satır bırakın; mutlaka okuyacağım!

Ve beni Twitter'da takip et . Genellikle genel olarak Android geliştirme ve yazılım mühendisliği hakkında paylaşımlar yapıyorum.

Burada da yayınlandı