Slack'in Deploy Süreci

• Tüm PR'ler kod incelemesinden geçmeli ve testleri başarıyla tamamlamalı

• Merge edilen kod, sorun çıkarsa müdahale edebilmek için yalnızca Kuzey Amerika çalışma saatlerinde deploy ediliyor

• Günde yaklaşık 12 düzenli dağıtım yapılıyor

• Her dağıtım için bir deploy sorumlusu atanıyor

1. Release branch oluşturma

2. Staging'e deploy edip manuel test yapma

3. Dahili Slack'e (dogfooding katmanına) deploy ettikten sonra Canary dağıtımı yapma (toplam trafiğin yalnızca %2'si yönlendiriliyor)

4. %10, %25, %50, %75 ve %100'e kadar aşamalı dağıtım yapma

Risk yönetimi için deploy sorumluları eğitiliyor; tüm adımları denetliyor ve iletişimi yönetiyorlar.

Sorunları mümkün olduğunca hızlı yakalayıp, soruna neden olan PR'yi belirliyor, onu çıkarıyor ve ardından yeni build'i deploy ediyorlar.

Eğer production'a kadar giderken fark edilmeyen bir sorun ortaya çıkarsa, incelemeye başlamadan önce önce rollback yapılıyor.

Şirketin ilk dönemlerinde yalnızca 10 EC2 instance çalıştırılırken deploy işlemi basitçe rsync yapmaktan ibaretti.

Production deploy'u öncesinde yalnızca tek bir staging aşaması vardı ve testten sonra doğrudan deploy yapılıyordu.

Müşteri sayısı arttıkça yalnızca rsync ile bunu sürdürmek zorlaştı.

→ Full parallel pull-based sisteme geçildi

Yeni build'i sunuculara script ile itmek yerine, her sunucu Consul anahtarındaki değişiklikten sinyal aldığında build'i aynı anda kendisi çekmeye başladı.

→ Hot/Cold klasörlerine ayrılmış Atomic Deploy

Deploy sırasında yeni kod, kullanılmayan Cold dizinine kopyalanıyor; mevcut servis ise Hot dizininden hizmet vermeye devam ediyor.

Sunucuda aktif proses kalmadığında Hot/Cold dizinleri yer değiştiriyor ve yeni kod anında servis edilmeye başlanıyor.

[xguru]

Hashicorp tarafından geliştirilen Consul https://www.consul.io/

Slack backend'i HHVM üzerinde çalışan PHP/Hacklang olduğu için o hot/cold değişimi mümkün gibi görünüyor.

https://www.quora.com/What-is-the-tech-stack-behind-Slack