Screen Shot 2558-06-24 at 5.30.18 PM
ทีมพัฒนาระบบ Payment ของ LinkedIn
ทำการเขียนบทความอธิบายขั้นตอนการพัฒนาไว้ที่
Getting Code to Production With Less Friction and High Quality

โดยหัวใจของบทความนี้คือ

  • Release ระบบให้บ่อยๆ
  • แต่ละ Release ต้องมีคุณภาพที่สูง

ดังนั้น เรามาดูกันว่าเขาทำอย่างไรบ้าง ?

ทุกสิ่งอย่างมันเริ่มมาจากปัญหาเสมอ

สิ่งที่คิดว่าทุกคนพบเจอในการพัฒนา software ก็คือ
รอบของการ release ที่ช้า หรือ นานมาก
ซึ่งมันส่งผลกระทบต่อการส่งมอบ และ พัฒนา feature ใหม่ๆ ออกไป
โดยปัญหาเหล่านี้ ทาง LinkedIn ก็โดนเช่นเดียวกัน

ดังนั้นจึงเริ่มหาแนวคิด แนวทางใหม่ๆ เพื่อทำให้
สามารถ release feature ใหม่ๆ ได้อย่างรวดเร็ว
พร้อมกับคุณภาพที่สูงด้วย

ปัญหาของทาง LinkedIn

เมื่อจะทำการ deploy อะไรใหม่ๆ บน production server หรือ release feature ออกไปนั้น
จะต้องผ่านกระบวนการทดสอบมากมาย
เมื่อเจอ error ก็ต้องมาค้นหาและแก้ไข
จากนั้นต้องทำการ re-test และ regression
ทำแบบนี้ไปเรื่อยๆ จนกว่าจะแก้ไข error ต่างๆ ทั้งหมด
ส่งผลให้การ release แต่ละ feature มันช้ามากๆ

ดังนั้นจึงได้ลองวิธีการใหม่ๆ กับระบบ Payment
มีเป้าหมายหลักเพื่อ ให้ทำการ release ได้บ่อยๆ พร้อมกับคุณภาพที่สูง
โดยระบบนี้ประกอบด้วยสองส่วนการทำงานหลัก คือ

  1. ส่วนของ Front End คือ User Interface สำหรับการ checkout
  2. ระบบ Back End

มาดูการเดินทางของ LinkedIn กันครับ

เริ่มต้นด้วย End-to-End Testing

สำหรับทุกๆ feature และ service จะทำการทดสอบแบบ End-to-End test เสมอ
โดยจะประกอบไปด้วย

  • การทดสอบผ่าน Web browser ซึ่งเป็น User Interface 70%
  • การทดสอบส่วนอื่นๆ ที่ไม่ใช่ User Interface 30%

แสดงดังรูป
InitialState-Fun

ปัญหาที่พบเจอจากแนวทางนี้ ประกอบไปด้วย

  • End-to-End test มันใช้เวลาการทดสอบนานมาก
  • End-to-End test นั้นมันพังบ่อย ไม่น่าเชื่อถือ ดังนั้นแทนที่จะมีประโยชน์กลับเป็นโทษอีกต่างหาก

และมันส่งผลต่อรอบในการ release ที่ใช้เวลาสูงขึ้น

ดังนั้นจึงปรับปรุงวิธีการด้วยวิธีการใหม่ดังนี้

1. ในแต่ละส่วนการทำงาน เช่น service จะต้องมี test เสมอ

แทนที่จะใช้เพียง end-to-End test แย่างเดียวเท่านั้น
ก็ทำการแยกการทดสอบย่อยๆ ออกไปยังส่วนการทำงานต่างๆ ซะเลย เช่น

  • Unit testing
  • Integration testing
  • Functional testing
  • Service testing

มันจะทำให้เวลาในการทดสอบเร็วขึ้น
และทำให้เรามั่นใจในการทดสอบมากยิ่งขึ้น

2. การทดสอบต้องอยู่ในกระบวนการพัฒนา และ ทำการทดสอบให้เร็ว และ บ่อยสุดๆ

การทดสอบแบบเดิมนั้น จะทดสอบหลังจากการพัฒนาเสร็จสิ้น
ซึ่งทำให้เรารู้ว่าระบบมีข้อผิดพลาดช้ามาก
และค่าใช้จ่ายในการแก้ไขสูงมากๆ
นั่นคือเรื่อง feedback loop ที่ช้า

ดังนั้น จึงทำการเปลี่ยนแปลงให้
ทำการทดสอบในทุกๆ ส่วนของการพัฒนา
จากนั้นแต่ละส่วนจะทำการ integrate ผ่านระบบ Continuous Integration (CI)
เพื่อทำให้มั่นใจว่าระบบงานยังทำงานได้อย่างถูกต้องตามที่คาดหวัง

มาดูกันว่าทาง LinkedIn ทำการทดสอบเมื่อไรบ้าง เพื่อทำให้เราค้นพบปัญหา และ แก้ไขได้อย่างรวดเร็ว

  • ก่อนทำการ commit
  • หลังจากการ commit เสร็จสิ้น
  • เมื่อทำการ build ในแต่ละส่วนเสร็จ เช่นเมื่อ unit testing เสร็จสิ้น จะทำการทดสอบ integration test ต่อไป
  • ทำการทดสอบหลังจากที่ deploy บนเครื่อง statging เรียบร้อย
  • ทำการทดสอบหลังจากที่ deploy บนเครื่อง production เรียบร้อย

3. ทีมพัฒนาต้องเป็นคนดูแลหลักเรื่องคุณภาพ

ทุกๆ คนภายในทีมต้องมีหน้าที่ในการควบคุมคุณภาพของ software นะ
ไม่ใช่ส่งหน้าที่นี้ไปให้ทีมอื่นๆ

ผลที่ได้จากการปรับปรุงครั้งนี้

ทีมพัฒนาระบบ Payment นั้น สามารถ release feature ได้เร็ว และบ่อยขึ้น
รวมทั้งมีความเชื่อมั่นต่อสิ่งที่ release ออกไปด้วย หรือ มีคุณภาพนั่นเอง
โดยแบ่งออกเป็นดังนี้

  • ในส่วนของ Front End จากใช้เวลาในการ release จากประมาณ 1.5 วัน ลงมาเหลือ 45 นาที ลดลงมา 90%
  • ในส่วนของ Back End จากใช้เวลาในการ release จากประมาณ 1.5 วัน ลงมาเหลือ 2 ชั่วโมง ลดลงมา 83%

ซึ่งผลที่ออกมาจากการปรับปรุงกระบวนการ release นี้มันชัดเจนมากมาย

แล้วคุณล่ะ
ทำการปรับปรุงกระบวนการพัฒนา software กันบ้างหรือไม่ ?