Proses Deploy Slack

• Semua PR harus melalui code review dan lulus pengujian

• Kode yang sudah di-merge hanya di-deploy pada jam kerja Amerika Utara (agar bisa ditangani jika terjadi masalah)

• Ada sekitar 12 rilis terjadwal per hari

• Untuk setiap deploy, ditunjuk penanggung jawab deploy

1. Membuat release branch

2. Deploy ke staging dan melakukan pengujian manual

3. Deploy ke Slack internal (tier dogfooding), lalu canary deploy (hanya 2% dari total traffic yang diarahkan)

4. Melanjutkan deploy bertahap hingga 10, 25, 50, 75, dan 100 persen

Untuk manajemen risiko, penanggung jawab deploy dilatih, mengawasi semua tahap, dan bertugas menangani komunikasi.

Masalah dideteksi secepat mungkin, PR penyebabnya diidentifikasi, dikeluarkan, lalu build baru di-deploy.

Jika ada masalah yang tidak terdeteksi sampai masuk production, maka sebelum investigasi, langkah pertama adalah melakukan rollback terlebih dahulu.

Pada masa awal perusahaan, ketika hanya menjalankan 10 instance EC2, proses deploy cukup dengan rsync.

Sebelum deploy ke production, hanya ada satu tahap staging.

Setelah pengujian, deploy langsung dijalankan.

Seiring bertambahnya pelanggan, rsync saja makin tidak memadai.

→ Berubah ke sistem full parallel pull-based

Alih-alih memasukkan build baru ke server lewat skrip, setiap server mengambil build secara bersamaan saat menerima sinyal perubahan key Consul.

→ Atomic deploy dengan pemisahan folder Hot/Cold

Saat deploy, kode baru disalin ke direktori Cold yang belum digunakan oleh layanan, sementara layanan yang berjalan tetap melayani dari direktori Hot.

Ketika tidak ada proses aktif di server, direktori Hot/Cold ditukar sehingga kode baru langsung mulai dilayani.

[xguru]

Consul by Hashicorp https://www.consul.io/

Karena backend Slack adalah PHP/Hacklang yang berjalan di HHVM, sepertinya pertukaran Hot/Cold itu dimungkinkan.

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