Release Process ที่ Facebook
What Do Release Engineers Care About? How Can They Control and Balance Between Feature, Quality and Schedule?
เมื่อวานเปิดดูการบรรยายเรื่อง Release Process โดย Chuck Rossi, Release Engineering Director ของ Facebook แล้วมีเรื่องน่าสนใจมาเล่าให้ฟังครับ
เนื้อหาที่คุณ Chuck พูดนั้นเน้นไปที่หลักการและกระบวนการที่ Facebook ใช้ในการ Release Software ทั้งที่เป็น Desktop Web และ Mobile … มาดูกันเลย
Fixed-Date Release Process
Facebook Mobile Apps ทั้งหลายใช้ Fixed-Date Release ครับ ความหมายที่เค้าอธิบายคือ
“มีสามเรื่องที่คุณต้องกังวลเวลาจะส่งมอบซอฟต์แวร์ นั่นคือ Feature, Quality และ Schedule ข่าวร้ายคือคุณเลือกได้แค่สองจากสาม และที่นี่ในฐานะ Release Engineer เราเลือก Quality และ Schedule”
ข้อดีของมันคือเราจะส่งมอบตรงเวลาเสมอ เพราะการ Release จะไม่รอ Feature ของคุณ ในทางกลับกันถ้า Feature คุณเสร็จ คุณก็ไม่ต้องรอ Feature ของคนอื่นที่ยังทำไม่เสร็จ คุณมั่นใจได้เลยว่า Feature ของคุณได้ Release แน่วันนี้
Do No Harm
Feature ที่จะถูก Release ต้องไม่ทำให้คุณภาพของซอฟต์แวร์แย่ลง Facebook Mobile Apps มี Key Metrics ที่ห้ามคะแนนตกสามตัวคือ Time To Interaction , Crash Rate และ Star Rating ถ้าการ Release ครั้งนี้ส่งผลกระทบในทางลบต่อสามค่านี้ จบ
นี่คือหลักการที่ Release Engineering Team ใช้ตัดสินทุก Code Commit ของ Developer
Just Check In Your Code to Master
หน้าที่ของ Developer ที่ Facebook คือแค่ Check In Code ของคุณมาที่ Master แค่นั้นจบ ที่เหลือเป็นเรื่องของ Release Engineer … เจ๋ง
Continuous Integration
คุณภาพเป็นเรื่องสำคัญ ดังนั้นที่ Facebook จึงมีกฎระเบียบในการ Check In ที่เข้มงวดทีเดียว
การ Check In มาที่ Master ทุกครั้งของ Developer ทุกคนต้องผ่านกระบวนการคัดกรองคุณภาพมาก่อนตามรูปข้างบน ไม่ว่าจะเป็น Build, Analysis หรือ Test ถ้าไม่ผ่านข้อใดข้อหนึ่งการ Check In ครั้งนั้นของคุณจะล้มเหลวนะจ๊ะ
Weekly Development Cycle for Desktop Web
Facebook กำหนด Development Cycle ของ Desktop Web ไว้ที่หนึ่งสัปดาห์ครับ ดังนั้นทุกวันอาทิตย์เย็นๆ ทีม Release Engineer จะตัด Code จาก Master ออกมาเป็น Release Branch แล้วเริ่มทำงานของพวกเค้า
หลังจากสร้าง Release Branch แล้วทีม Release Engineer ก็จะใช้เวลาประมาณสองวันเพื่อ Stabilize เจ้า Release นี้ด้วยการทำเทสเป็นการภายในเพื่อเอาให้ชัวร์ว่ามันจะ Do No Harm … ระหว่างนี้ไม่ต้องมาขอเพิ่ม Feature นะ ไม่อนุญาตเจ้าค่ะ
จากนั้นก็จะค่อยๆ Push Changes ซึ่งมีประมาณ 4,000–6,ooo ตัวขึ้น Production วันละสองครั้งตลอดทั้งสัปดาห์นั้น คุณ Chuck บอกว่ากระบวนการนี้ใช้ Release Engineer แค่สองคนเอง ในมุมมองของ Release Engineer คนสองคนดูแล Facebook.com ทั้งโลก … เวอร์มาก ฮ่าๆ
ป.ล. Facebook Mobile Apps ใช้ Development Cycle Time สี่สัปดาห์แต่กระบวนการและแนวคิดหลักๆก็เหมือนกับ Desktop Web ครับ
Cherry Picking
ระหว่างช่วงเวลาที่ใช้ในการ Stabilize Release Branch ทีม Release Engineer จะเลือกเข้าไปทำ Code Review และเทสอย่างหนักหน่วงใน Commit บางอันหรือ Feature บางตัว หลักการนี้เรียกว่า Cherry Picking โดย Release Engineer จะเลือกลูกเชอรี่จาก
- Diff: ความเปลี่ยนแปลงของโค๊ดก่อนและหลัง … ถ้า Commit ไหนมี Diff มากก็น่าจะมีความเสี่ยงมาก ต้องให้ความสนใจเป็นพิเศษหน่อย
- Discussion: ปริมาณการสนทนากันระหว่างทีมงานในแต่ละ Commit … ถ้า Commit ไหนมีการโต้เถียงกันในเรื่อง Design, Technical หรือ Testing มากให้สันนิษฐานได้เลยว่ามีความเสี่ยงมากเช่นกัน (Developer มักจะคุยกันผ่าน Comment Box ใน Source Control System พวก Git, Mercurial อะไรแบบนี้)
- Karma: Developer ทุกคนเริ่มด้วยด้วยการมี Karma = 4 ดาว ถ้าคนไหนทำงานไม่ดีมีปัญหาตอน Release เยอะทีม Release Engineer จะมีสิทธิกด Dislike ได้ บ่อยๆเข้าดาวของคนนั้นก็จะลดลง ใครมีดาวน้อยแปลว่ามีความเสี่ยงมาก ฮ่าๆๆ โหดหน่อยตรงที่ทุกครั้งที่กด Dislike หัวหน้าคุณจะได้รับข้อมูลนี้ไปด้วย … ไม่ถึงขนาดโดนไล่ออกหรอก แต่ว่าก็เป็นข้อมูลในการปรับปรุงการทำงานในอนาคตอะนะ ** อัพเดท วันที่ 8 ธ.ค. 57: คนไหนมี Karma น้อยกว่าหรือเท่ากับ 2 ทีม Release Engineer จะไม่จัดการกับ Change ของเค้า มันส์ ฮ่าๆ **
No Hot Fix
ข้อนี้ชอบเป็นพิเศษ ใจความของมันคือ
“ถ้าของคุณเจ๊งหรือยังทำไม่เสร็จ คุณโดนเตะตกรถแน่นอน ไม่มีการมาขอแก้กลางทาง เราไม่อนุญาติ เราเชื่อมั่นว่ามันจะปลอดภัยกว่าถ้าเรา Revert แทนที่จะ Fix Forward แบบเร่งรีบ”
ฮ่าๆ ทุกคนคงเห็นอยู่ในสถานการณ์นี้นะครับ ต้อง Release คืนนี้ 6 โมงเย็นเทสไม่ผ่าน Developer รีบๆแก้ส่งของมาให้ใหม่ เทสตรงนี้ผ่านแต่ไปพังที่อื่นต่อ Developer ก็ยังไม่ลดละความพยายามขอแก้อีก … เลิกเหอะ ยิ่งจะทำให้อะไรมันเละไปกว่าเดิม ผมชอบคุณ Chuck พูดถึงสถานการณ์นี้แบบนี้ครับ
“No. You are done. You are on the next train. Get out of here. I got more stuffs to worry about … ไม่ คุณจบแล้ว คุณไปรอรถขบวนถัดไปเลย ออกไปได้ล่ะ ผมมีอย่างอื่นที่ต้องทำอีกเยอะ” ฮ่าๆ
Not Just The Code
Facebook ก็มี Definition of Done เหมือนกันและแน่นอนมันไม่ใช่แค่เรื่องของโค๊ดอย่างเดียว ทีมงานทุกคนต้องใส่ใจเรื่องพวกนี้ด้วย
สุดท้ายคุณ Chuck ฝากข้อคิดที่น่าสนใจในเรื่อง Release Engineering / Process ไว้ว่า
- Release Engineer มีหน้าที่ป้องกันและจัดการกับความเสี่ยงต่างๆ … “Room full of developers = Room full of risks” ฮ่าๆ ดังนั้นเราต้องมีจุดยืนและยึดมั่นในหลักการอย่างไม่ย่อท้อ
- เมื่อมี Release Engineer แล้ว คนที่ทำหน้าที่อื่นก็ต้องให้ความเคารพในความคิด หลักการ และกฎเกณ์ของ Release Engineer ด้วย เมื่อเราบอกว่าผ่านคือผ่าน ไม่ผ่านคือไม่ผ่าน … ข้อนี้ยากเลย แฮ่ๆ
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
