กระบวนการ Deploy ของ Slack

• ทุก PR ต้องผ่าน code review และการทดสอบ

• โค้ดที่ merge แล้วจะถูก deploy เฉพาะในเวลาทำงานของอเมริกาเหนือเท่านั้น (เพื่อให้แก้ปัญหาได้หากเกิดเหตุ)

• มีการปล่อยเวอร์ชันตามรอบประมาณวันละ 12 ครั้ง

• แต่ละการ deploy จะมีผู้รับผิดชอบการ deploy ที่ถูกกำหนดไว้

1. สร้าง release branch

2. Deploy ไปยัง staging และทดสอบแบบ manual

3. Deploy ไปยัง Slack ภายในองค์กร (tier ที่ใช้ dogfooding) จากนั้นทำ Canary deploy (route เพียง 2% ของทราฟฟิกทั้งหมด)

4. ทำการ deploy แบบเป็นขั้นไปที่ 10, 25, 50, 75, 100 เปอร์เซ็นต์

เพื่อบริหารความเสี่ยง จะมีการฝึกผู้รับผิดชอบการ deploy ให้คอยกำกับทุกขั้นตอนและดูแลการสื่อสาร

ตรวจจับปัญหาให้เร็วที่สุด ระบุ PR ต้นเหตุ นำออก แล้ว deploy build ใหม่

หากเกิดปัญหาที่ตรวจไม่พบระหว่างทางจนขึ้น production แล้ว ให้ rollback กลับสภาพเดิมก่อน แล้วค่อยเริ่มการสืบสวน

ในช่วงแรกของบริษัท ตอนที่รันเพียง 10 EC2 instances การ deploy เป็นแค่การทำ rsync

ก่อน deploy production มีเพียงขั้น staging ขั้นเดียว

ทดสอบเสร็จแล้วก็ deploy ทันที

เมื่อมีลูกค้าเพิ่มขึ้นเรื่อย ๆ การใช้แค่ rsync ก็เริ่มไม่พอ

→ เปลี่ยนเป็นระบบ full parallel pull-based

แทนที่จะใส่ build ใหม่เข้าไปในเซิร์ฟเวอร์ด้วยสคริปต์ แต่ละเซิร์ฟเวอร์จะดึง build พร้อมกันเมื่อได้รับสัญญาณจากการเปลี่ยนคีย์ใน Consul

→ Atomic deploy ที่แยกโฟลเดอร์ Hot/Cold

ตอน deploy จะคัดลอกโค้ดใหม่ไปยังไดเรกทอรี Cold ที่ยังไม่ได้ใช้งาน ส่วนบริการเดิมจะยังเสิร์ฟจากไดเรกทอรี Hot

เมื่อไม่มี active process บนเซิร์ฟเวอร์ ก็จะสลับไดเรกทอรี Hot/Cold กัน ทำให้โค้ดใหม่เริ่มให้บริการได้ทันที

[xguru]

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

ดูเหมือนว่าน่าจะสลับแบบ Hot/Cold ได้ เพราะแบ็กเอนด์ของ Slack เป็น PHP/Hacklang ที่ทำงานบน HHVM

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