Yeni bir proje sürümünün üretime alınması, dağıtım hızı ile çözüm güvenilirliği arasında dikkatli bir denge kurulmasını gerektirir. Slack, hızlı yinelemelere, kısa geri bildirim döngülerine ve kullanıcı isteklerine anında yanıt verilmesine değer verir. Ayrıca şirkette mümkün olduğunca üretken olmaya çalışan yüzlerce programcı bulunmaktadır.
Bugün tercümesini yayınladığımız materyalin yazarları, bu değerlere bağlı kalmaya çalışan ve aynı zamanda büyüyen bir şirketin proje dağıtım sistemini sürekli iyileştirmesi gerektiğini söylüyor. Şirketin iş süreçlerinin şeffaflığına ve güvenilirliğine yatırım yapması ve bunu bu süreçlerin projenin ölçeğine uygun olmasını sağlamak için yapması gerekiyor. Burada Slack'te gelişen iş akışlarından ve şirketi bugün var olan proje dağıtım sistemini kullanmaya yönlendiren bazı kararlardan bahsedeceğiz.
Proje dağıtım süreçleri günümüzde nasıl işliyor?
Slack'teki her PR (çekme isteği) kod incelemesine tabi olmalı ve tüm testleri başarıyla geçmelidir. Ancak bu koşullar karşılandıktan sonra programcı kodunu projenin ana dalıyla birleştirebilir. Ancak bu kod yalnızca Kuzey Amerika saatine göre çalışma saatlerinde dağıtılır. Sonuç olarak çalışanlarımızın işyerlerinde olmaları nedeniyle beklenmedik sorunları çözmeye tam anlamıyla hazırız.
Her gün yaklaşık 12 planlı konuşlandırma gerçekleştiriyoruz. Her dağıtım sırasında, dağıtım lideri olarak atanan programcı yeni yapının üretime alınmasından sorumludur. Bu, montajın sorunsuz bir şekilde üretime alınmasını sağlayan çok adımlı bir süreçtir. Bu yaklaşım sayesinde hataları tüm kullanıcılarımızı etkilemeden tespit edebiliyoruz. Çok fazla hata varsa derlemenin dağıtımı geri alınabilir. Yayınlandıktan sonra belirli bir sorun keşfedilirse, bunun için kolayca bir düzeltme yayınlanabilir.
Slack'te projeleri dağıtmak için kullanılan Checkpoint sisteminin arayüzü
Yeni bir sürümün üretime dağıtılması süreci dört adımdan oluştuğu düşünülebilir.
▍1. Yayın dalı oluşturma
Her sürüm, Git geçmişimizde bir nokta olan yeni bir sürüm dalıyla başlar. Bu, sürüme etiket atamanıza olanak tanır ve sürümü üretim sürümüne hazırlama sürecinde bulunan hatalar için canlı düzeltmeler yapabileceğiniz bir yer sağlar.
▍2. Hazırlama ortamında dağıtım
Bir sonraki adım, derlemeyi hazırlama sunucularına dağıtmak ve projenin genel performansı için otomatik bir test yürütmektir (duman testi). Hazırlama ortamı, harici trafik almayan bir üretim ortamıdır. Bu ortamda ek manuel testler gerçekleştiriyoruz. Bu bize değiştirilen projenin doğru şekilde çalıştığına dair ek güven verir. Otomatik testler tek başına bu düzeyde bir güven sağlamak için yeterli değildir.
▍3. Test sürümü ve kanarya ortamlarında dağıtım
Üretime dağıtım, dahili Slack çalışma alanlarımıza hizmet eden bir dizi ana bilgisayar tarafından temsil edilen bir test ortamıyla başlar. Çok aktif Slack kullanıcıları olduğumuz için bu yaklaşımı benimsemek, birçok hatayı dağıtımın erken safhalarında yakalamamıza yardımcı oldu. Sistemin temel işlevselliğinin bozulmadığından emin olduktan sonra montaj kanarya ortamında konuşlandırılır. Üretim trafiğinin yaklaşık %2'sini oluşturan sistemleri temsil eder.
▍4. Üretime kademeli geçiş
Yeni sürüme ilişkin izleme göstergeleri stabil çıkarsa ve projeyi kanarya ortamında dağıttıktan sonra herhangi bir şikayet almamışsak, üretim sunucularını kademeli olarak yeni sürüme aktarmaya devam ediyoruz. Dağıtım süreci şu aşamalara ayrılmıştır: %10, %25, %50, %75 ve %100. Sonuç olarak üretim trafiğini yavaş yavaş sistemin yeni sürümüne aktarabiliyoruz. Aynı zamanda herhangi bir anormallik tespit edilirse durumu araştırmak için zamanımız var.
▍Ya dağıtım sırasında bir şeyler ters giderse?
Kodda değişiklik yapmak her zaman risklidir. Ancak yeni bir sürümü üretime sokma sürecini yöneten, izleme göstergelerini izleyen ve kod yayınlayan programcıların çalışmalarını koordine eden iyi eğitimli "dağıtım liderlerinin" varlığı sayesinde bununla başa çıkıyoruz.
Gerçekten bir şeylerin ters gitmesi durumunda, sorunu mümkün olduğu kadar erken tespit etmeye çalışıyoruz. Sorunu araştırır, hatalara neden olan PR'yi bulur, geri alır, kapsamlı bir şekilde analiz eder ve yeni bir yapı oluştururuz. Doğru, bazen proje üretime geçene kadar sorun fark edilmiyor. Böyle bir durumda en önemli şey hizmeti geri yüklemektir. Bu nedenle, sorunu araştırmaya başlamadan önce hemen önceki çalışma yapısına geri dönüyoruz.
Dağıtım Sisteminin Yapı Taşları
Proje dağıtım sistemimizin temelini oluşturan teknolojilere bakalım.
▍Hızlı dağıtımlar
Yukarıda açıklanan iş akışı geriye dönüp bakıldığında oldukça açık görünebilir. Ancak konuşlandırma sistemimiz hemen bu hale gelmedi.
Şirket çok daha küçükken uygulamamızın tamamı 10 Amazon EC2 bulut sunucusu üzerinde çalışabiliyordu. Bu durumda projeyi dağıtmak, tüm sunucuları hızlı bir şekilde senkronize etmek için rsync'in kullanılması anlamına geliyordu. Daha önce yeni kod, bir hazırlama ortamıyla temsil edilen üretime yalnızca bir adım uzaklıktaydı. Montajlar böyle bir ortamda oluşturulup test edildi ve ardından doğrudan üretime geçildi. Böyle bir sistemi anlamak çok kolaydı; her programcının yazdığı kodu istediği zaman konuşlandırmasına olanak sağlıyordu.
Ancak müşterilerimizin sayısı arttıkça projeyi desteklemek için gereken altyapının boyutu da arttı. Sistemin sürekli büyümesi göz önüne alındığında, sunuculara yeni kod göndermeye dayanan dağıtım modelimiz kısa sürede işini yapamaz hale geldi. Yani, her yeni sunucunun eklenmesi, dağıtımın tamamlanması için gereken sürenin artması anlamına geliyordu. Rsync'in paralel kullanımına dayalı stratejilerin bile belirli sınırlamaları vardır.
Eski sistemden farklı tasarlanmış tamamen paralel bir dağıtım sistemine geçerek bu sorunu çözdük. Yani artık sunuculara senkronizasyon betiği kullanarak kod göndermedik. Artık her sunucu, Consul anahtarı değişikliğini izleyerek bunu yapması gerektiğini bilerek yeni derlemeyi bağımsız olarak indirdi. Sunucular kodu paralel olarak yükledi. Bu, sürekli sistem büyümesinin olduğu bir ortamda bile yüksek dağıtım hızını korumamıza olanak sağladı.
1. Üretim sunucuları Consul anahtarını izler. 2. Anahtar değişir; bu, sunuculara yeni kodu indirmeye başlamaları gerektiğini bildirir. 3. Sunucular uygulama kodunu içeren tarball dosyalarını indirir
▍Atom konuşlandırmaları
Çok katmanlı bir dağıtım sistemine ulaşmamıza yardımcı olan bir diğer çözüm de atomik dağıtımdı.
Atomik dağıtımları kullanmadan önce, her dağıtım çok sayıda hata mesajına neden olabilir. Gerçek şu ki, yeni dosyaları üretim sunucularına kopyalama süreci atomik değildi. Bu, yeni işlevler çağıran kodun, işlevler mevcut olmadan önce mevcut olduğu kısa bir zaman aralığıyla sonuçlandı. Böyle bir kod çağrıldığında, dahili hataların döndürülmesiyle sonuçlandı. Bu, başarısız API isteklerinde ve bozuk web sayfalarında kendini gösterdi.
Bu sorun üzerinde çalışan ekip, "sıcak" ve "soğuk" dizin kavramını tanıtarak sorunu çözdü. Etkin dizindeki kod, üretim trafiğinin işlenmesinden sorumludur. “Soğuk” dizinlerde ise kod sistem çalışırken sadece kullanıma hazırlanmaktadır. Dağıtım sırasında yeni kod kullanılmayan bir soğuk dizine kopyalanır. Daha sonra sunucuda aktif bir işlem kalmadığında anlık dizin değişimi gerçekleştirilir.
1. Uygulama kodunu “soğuk” bir dizine açmak. 2. Sistemin "soğuk" bir dizine geçirilmesi, bu dizinin "sıcak" hale gelmesi (atomik işlem)
Sonuçlar: güvenilirliğe verilen önemde değişiklik
2018 yılında proje o kadar büyüdü ki, çok hızlı dağıtım ürünün stabilitesine zarar vermeye başladı. Çok fazla zaman ve çaba harcadığımız çok gelişmiş bir dağıtım sistemimiz vardı. Tek yapmamız gereken dağıtım süreçlerimizi yeniden inşa etmek ve geliştirmekti. Kesintisiz iletişimi organize etmek ve önemli sorunları çözmek için tüm dünyada gelişmeleri kullanılan oldukça büyük bir şirket haline geldik. Bu nedenle güvenilirlik dikkatimizin odağı haline geldi.
Yeni Slack sürümlerini dağıtma sürecini daha güvenli hale getirmemiz gerekiyordu. Bu ihtiyaç bizi dağıtım sistemimizi geliştirmeye yöneltti. Aslında yukarıda bu geliştirilmiş sistemden bahsetmiştik. Sistemin derinliklerinde hızlı ve atomik konuşlandırma teknolojilerini kullanmaya devam ediyoruz. Dağıtımın yapılma şekli değişti. Yeni sistemimiz, yeni kodu farklı ortamlarda, farklı düzeylerde kademeli olarak dağıtacak şekilde tasarlanmıştır. Artık eskisinden daha gelişmiş destek araçları ve sistem izleme araçları kullanıyoruz. Bu bize, hataları son kullanıcıya ulaşma şansına sahip olmadan çok önce yakalayıp düzeltme olanağı sağlar.
Ama burada durmayacağız. Daha gelişmiş yardımcı araçlar ve iş otomasyonu araçları kullanarak bu sistemi sürekli geliştiriyoruz.
Sevgili okuyucular! Çalıştığınız yerde yeni proje sürümlerini dağıtma süreci nasıl işliyor?
Kaynak: habr.com