Ürün geliştirme kültürü: Yayın süreci

Ürün geliştirme ile ilgili olarak ilk yazımda ürün için çalışacak takımların nasıl olması gerektiğini anlatmıştım. Çeşitli ihtiyaçlara ve özelliklere göre belirlendikten sonra takımlar, sadece kendilerinin sorumlu oldukları alanda geliştirme yapıyorlar. Bu durumun bir çok avantajı ve dezavantajı var. Bu yazımda da bu şekilde çalışmanın en büyük dezavantajlarından birisi olan, yapılan geliştirmeleri yayına alma sürecinde karşılaşılan sorunları Spotify‘ın nasıl çözdüğünü incelemek istedim.

Deployment süreci yazılım şirketlerinde her zaman konuşulan, tartışılan bir konu. Çünkü her ekibin çalışma sistemine dayalı farklı deployment süreçleri bulunuyor. Bir proje üzerinde ekip olarak çalışmak, bireysel olarak çalışmaktan tahmin edemeyeceğiniz kadar zor bir durum. Ekip içerisinde farklı kişiler tarafından yazılmış kodların birleştirilmesi sırasında, kodların standartlara uygun olması için yapılan code review süreçlerinde sorunlar çıkabiliyor. Bir de bunu Spotify gibi yüzlerce farklı yazılımcının çalıştığı bir ürün üzerinde düşünecek olursanız, deploy sırasındaki zaman kaybının ne kadar fazla olduğunu tahmin edebilirsiniz.

Ürünlerin yeni versiyonları yayına çıkılacağı zaman genellikle izlenen yol tüm özelliklerin tamamlanıp son haliyle çıkılması yönünde oluyor. Farklı farklı yazılımcıların geliştirdiği tüm özellikler bir anda, tek seferde yayına alınıyor. Böyle söyleyince her ne kadar kulağa hoş gelse de, işin arka tarafında karşılaşabileceğiniz çok fazla sorun doğuruyor bu süreç. Geniş aralıklarla çıkılan yeni sürümler oldukça büyük boyutlu ve içerisinde çok değişiklik barındıran sürümlerdir. Böyle büyüklükte bir versiyonu çıktığınızda eğer iyi bir dökümanınız yoksa o versiyonun ilk günlerinde düşünülen fikirlerin ve yazılan kodların bile çoğunu unutmuş oluyorsunuz. Bu da eğer yeni versiyonunuzda bir hata bulunursa bugfix sürenizin olması gerekenden çok daha fazla uzun sürmesine sebep oluyor.

Spotify bu deployment sürecinin rutin olması gerektiğini söylüyor ve kendileri de olabildiğince sık sık yapılan tüm değişiklikleri ve geliştirmeleri deploy ettiklerini söylüyorlar. Bu sayede eğer bir hata bulunursa kısa sürede ve henüz kod unutulmamışken sağlıklı bir şekilde düzeltilebiliyor. En kaba tabiriyle koda ve versiyona müdahale edebilme esnekliğiniz artıyor.

Decoupled Releases

Yazıda asıl odaklanacağımız kısım burası değil. Asıl odaklanılması gereken kısım, ilk yazıda anlatılan farklı ekiplerin farklı özelliklerde çalışıp nasıl birlikte hareket edebileceğini çözebilme kısmı. Spotify bu sorunu inanılmaz bir radikal karar ile çözmüş. İlk desktop versiyonunda site tek bir parça ve bu parça içerisinde farklı özellikler bulunurken, sadece deploy sürecini iyileştirmek için daha sonraki versiyonlarda tüm siteyi özelliklere uygun şekilde parçalara bölmüşler. Bu sayede kendi ekibinizde bir özelliği yayınlamak istediğiniz zaman bu özelliği bir bütünün içine direk yollamak yerine, sadece kendi parçanızı etkileyecek şekilde yolluyorsunuz. Bu da sizin yaptığınız bir özelliğin bütünü bozma riskini oldukça azaltıyor. Eğer bu şekilde bir yol izlenmeseydi, onlarca farklı takımdan birisi kendi geliştirdiği özelliği bir bütüne gönderirken, o bütünü bozacak bir hata yapmış olabilirdi. Ya da bitirilen bir özelliği hemen yayına alıp, kullanıcılara sunmak yerine diğer ekiplerin kendi özelliklerini bitirmesini ve senkron şekilde hareket etmeyi bekleyeceklerdi.

Bu tip sorunları çözmek için Spotify aşağıdaki görselde görebileceğiniz gibi bir değişiklik yaptı. Sol tarafta versiyon çıkmak için tüm özelliklerin ve tüm ekiplerin beklendiği, ekiplerin kafasını karıştırabilecek ve geliştirme süresini yavaşlatabilecek tek parça uygulama mimarisine sahip bir Spotify var. Sağ tarafta ise ekiplerin diğer ekipler ile iletişim halinde olmalarına gerek olmadan kendi başlarına, kendi özelliklerini deploy edebileceği, sectionlara bölünmüş desktop versiyonu bulunuyor.

Görsel Spotify’dan alınmıştır.

Bu mimari değişim sayesinde ekipler birbirinden daha bağımsız ve daha esnek hareket edebiliyorlar. Bu mimari düzeni başarılı bir şekilde sürdürebilmek için sadece release işlemi ile uğraşacak bazı takımlar bulunuyor. Bu takımlar, özellikleri tamamlayan takımların daha efektif şekilde çalışması için yardımcı oluyorlar ve release işlemleri ile ilgili her konuda özellik bazlı takımlara destek oluyorlar.

Yayına çıkıyoruz

Şimdi yazının ana konusu olan, sürecin en kritik kısmına geldik. Spotify yayına alınacak özellikler için Release Trains adını verdiği bir sistem geliştirdi. Bu sistemin en inovatif çözümlerinden birisi ise Feature Toggles adını verdikleri çözüm. Feature Toggles sayesinde bir özelliği yayına alırken o özelliğin bitmiş olması gerekmiyor. Bir çoğunuz şu anda bu cümleyi okurken buna inanmasanız da gerçekten Spotify bitmemiş bir özelliği yayına alıyor. Yayına alıyor çünkü kullanıcıların bu özelliği görüp görmemeleri tamamiyle kendilerinin elinde. Bu sayede de bitmemiş bir özelliği yayına almalarında herhangi bir sakınca bulunmuyor çünkü bu özellik tamamlanana kadar zaten kullanıcılar özelliğin bu yarım kalmış halini görmemiş ve kullanmamış oluyorlar. Aynı zamanda bu özellik sayesinde, yeni özellikler A/B testleri için daha uyumlu bir hale geliyor. MVP olarak yayına alınmış bir özelliği çok kolay bir şekilde kullanıcılar üzerinde test edip, bu özellik ile ilgili tekrar bir çalışma yapabiliyorlar.

Görsel Spotify’dan alınmıştır.

Görselde de görebileceğiniz gibi deployment aralıkları oldukça kısa. Kısa süreli deploy ve Feature Toggles sayesinde tüm takımlar yaptıkları en küçük güncellemeleri bile yayına çıkabilecek esnekliğe sahip. Bu da hem zamandan tasarruf sağlıyor hem de sadece yolun sonunda değil, yolda giderken de özellikler ile ilgili hatalara anında müdahale edebiliyorlar. Bu müdahale sürecini ben erken teşhis‘e benzetiyorum. Doktor bir hastalığa ne kadar erken teşhis koyarsa, o kadar kısa sürede ve o kadar az risk ile o hastalığın üstesinden gelebilir. Yazılımcılar içinde bu geçerli. Erken teşhis edilen bir hatayı düzeltmeniz, aylar sonra keşfedilen bir hatayı düzeltmenizden katbekat daha kolay. Fakat bu kolaylığı yakalamanız için de aynı Spotify’da olduğu gibi esnek ve sizi destekleyen bir yapının olması gerekli.

Günün sonunda bu sistemden çıkaracağımız sonuçlardan bazıları;

  • Deployment aralıklarını kısa tutun! Haftalık rutin deploy zamanlarınız olsun.
  • Bir projeye başlarken mimarinizi deployment sürecini düşünerek kurgulayın.
  • Kullanıcıyı rahatsız etmeyecek ve uygulamanızı bozmayacak, arka tarafta yaptığınız değişikliklerinizi yayına almaktan çekinmeyin.
  • Kontrol mekanizmanız, güven mekanizmanızdan daha önemli bir sırada olmasın.
  • Her zaman olduğu gibi, asla ve asla hata yapmaktan korkmayın!

Yorum Gönderin

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir