Quy trình deploy của Slack

• Mọi PR đều cần code review và phải vượt qua kiểm thử

• Mã đã merge chỉ được deploy trong giờ làm việc ở Bắc Mỹ (để có thể xử lý nếu phát sinh sự cố)

• Mỗi ngày có khoảng 12 đợt phát hành định kỳ

• Mỗi đợt phát hành đều có một người phụ trách deploy được chỉ định

1. Tạo release branch

2. Deploy lên staging và kiểm thử thủ công

3. Deploy lên Slack nội bộ (dogfooding tier), sau đó deploy Canary (chỉ route 2% tổng lưu lượng)

4. Tiến hành deploy theo từng bước lên các mức 10, 25, 50, 75, 100 phần trăm

Để quản lý rủi ro, họ đào tạo người phụ trách deploy, để người này giám sát mọi bước và phụ trách giao tiếp.

Cố gắng phát hiện sự cố càng sớm càng tốt, xác định PR là nguyên nhân, loại nó ra, rồi deploy bản build mới.

Nếu có vấn đề không bị phát hiện cho đến khi đã lên production, thì trước khi điều tra sẽ ưu tiên rollback ngay.

Thời kỳ đầu của công ty, khi chỉ vận hành 10 EC2 instance, việc deploy đơn giản chỉ là rsync.

Trước khi deploy lên production chỉ có đúng một bước staging.

Sau khi kiểm thử xong thì tiến hành deploy ngay.

Khi số lượng khách hàng dần tăng lên, chỉ dùng rsync trở nên không còn đủ.

→ Chuyển sang hệ thống full parallel pull-based

Thay vì dùng script để đưa bản build mới vào server, mỗi server sẽ đồng thời tự tải bản build khi nhận tín hiệu từ thay đổi khóa Consul.

→ Atomic deploy với thư mục Hot/Cold tách biệt

Khi deploy, mã mới được sao chép vào thư mục Cold chưa được dùng; dịch vụ hiện tại vẫn phục vụ từ thư mục Hot.

Khi server không còn process đang hoạt động, hai thư mục Hot/Cold sẽ được hoán đổi cho nhau để mã mới được phục vụ ngay lập tức.

[xguru]

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

Có vẻ việc hoán đổi Hot/Cold đó khả thi là vì backend của Slack là PHP/Hacklang chạy trên HHVM.

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