รู้จักกับ Commit Stage ใน Deployment Pipeline กัน

สวัสดีครับ ก่อนหน้านี้ผมได้เขียนบทความเกี่ยวกับ Deployment Pipeline ใน Continuous Delivery ไปแล้ว วันนี้ผมจะมาเขียนเกี่ยวกับ Commit Stage จุดแรกใน Deployment Pipeline ที่ Source Code ของเราจะถูกทดสอบครับ

ภาพตัวอย่าง Deployment Pipeline จากหนังสือ Continuous Delivery

The Commit Stage

เมื่อเกิดการเปลี่ยนแปลงของ Source Code จาก Version Control นี่คือด่านแรกที่จะต้องเจอก่อนผ่านไปยังส่วนต่อไป ซึ่งใน Concept ของ Commit Stage คือ ใช้เวลาตรวจสอบ Source Code ให้น้อยลงที่สุด ซึ่งตรงนี้รวมถึงการทดสอบด้วย (เรียกชุดการทดสอบนี้ว่า Commit Test Suite)เพื่อให้ได้ Feedback ที่เร็วที่สุด โดยเมื่อ Source Code ของเราผ่านการทดสอบที่ Commit Stage แล้วก็จะทำการส่ง Report , ไฟล์ Binary ที่มาจากการ Build และข้อมูลเกี่ยวกับ Build นี้ไปเก็บไว้ที่ Artifact Repository และดำเนินการต่อไปยังขั้นตอนต่อไปของ Pipeline

Commit Stage Principles and Practices

Provide Fast, Useful Feedback — ข้อผิดพลาดหากพบได้เร็ว ก็จะสามารถแก้ไขได้ง่าย ปัญหาไม่ว่าจะเป็นตั้งแต่ Syntax Error หรือ Test Case ที่ไม่ผ่าน ต้องถูกส่งไปยัง Developer ได้เร็วพร้อมกับสามารถบอกเหตุของข้อผิดพลาดได้

What Should Break the Commit Stage? — ไม่ได้มีเพียง Unit Test ที่ออกแบบมาเพื่อทดสอบ Function ที่ทำงานถูกต้องหรือไม่เท่านั้น ที่จะบอกว่า Commit Stage นี้จะผ่านหรือไม่ แต่อาจจะนำตัวชี้วัดอื่นมาใช้ได้ ตัวอย่างเช่น เลขของ Test Coverage ที่ต้องผ่านเกิน 80% , ผลที่ได้จาก Code Analysis เขียนได้ถูกตามหลักภาษาหรือ Coed Style

Tend the Commit Stage Carefully — ควรมีการจัดการกับ Script สำหรับ Commit Stage ให้ดี ซึ่งต้องมันใจว่าใน Script หากเกิดข้อผิดพลาดต้องสามารถหาและแก้ไขได้เร็ว โดยที่นี้แนะนำให้ทำ Script ให้อยู่ในรูปแบบ Modular

Give Developers Ownership — ให้ความเป็นเจ้าของใน Process นั้น ลดช่องว่างในการที่ทีมพัฒนาเข้ามาแก้ไขปัญหา ดูแล และช่วยให้ทีมเกิดความรับผิดชอบในส่วนนั้น มากกว่าที่จะมีตำแหน่งที่คอยดูแล Process อยู่ห่าง ๆ

Use a Build Master for Very Large Teams — ในทีมที่มีขนาดใหญ่มาก ๆ ควรจะมีบุคคลที่เป็นตำแหน่ง Build Master คอยติดตามและแก้ไขเมื่อการ Build เกิดข้อผิดพลาด แต่คนคนนั้นจะไม่เป็น Permanent Role ต้องคอยสับเปลี่ยนกันไปในทีม

The Commit Test Suit

Unit ที่อยู่ข้างล่างสุด จะสามารถทดสอบได้เร็ว และมีจำนวนมาก

ในหนังสือมีกฏที่น่าสนใจอยู่เกี่ยวกับลักษณะของ Commit Test ไว้
ผมขอเลือกข้อที่น่าสนใจมาบางข้อมาสรุปไว้ตรงนี้นะครับ

จะไม่มีการทดสอบร่วมกับการเชื่อมต่อ Database จริง แต่จะใช้เทคนิค Dependency Injection หรือใช้ In-Memory Database เพื่อทดสอบแทน

หลีกเลี่ยงการทดสอบที่เป็นแบบ Asynchronous เพราะว่าจะทำให้การทดสอบนั้นใหญ่และเริ่มยุ่งยากเกี่ยวกับการจัดการ Process การใช้ Asynchronous จะอยู่ในการทดสอบในขั้นอื่นเช่น Component Test ที่เป็นภาพใหญ่

ใช้เทคนิค Test Double สำหรับ Focus จุดที่เราทำการทดสอบ (ย้ำว่าต้องเป็นจุดเล็ก ๆ สำคัญที่ต้องกำหนด Scope ของชุดการทดสอบ)

ใช้เทคนิค Faking Time สำหรับการทดสอบที่เกี่ยวข้องกับเวลา เราจำเป็นต้องให้การทดสอบของเราได้ผลลัพธ์เหมือนเดิมเสมอ รวมถึงสามารถทดสอบซ้ำได้ทุกเวลา

อย่างที่พูดไปข้างต้นว่าใน Stage นี้เราต้องการ Feedback ที่เร็วที่สุด
( Rapid Feedback ) ชุดการทดสอบที่อยู่ใน Commit Test จึงจะมีขนาดเล็กและเป็นการทดสอบในระดับ Low-Level หรือใกล้เคียงกับภาษาของโปรแกรมมาก ๆ

ในการทำ Continuous Delivery หรือ Continuous Integration ตัว Deployment Pipeline นั้นจะตั้งอยู่บนข้อหลัก ๆ คือ Source Code บน Version Control นั้นต้องเป็น Releasable Software อยู่เสมอและหากเกิดข้อผิดพลาดบน Pipeline ไม่ว่าจากขั้นตอนใดก็ตามต้องได้รับ Feedback ที่เร็วและแก้ไขอย่างทันที

Reference : Continuous Delivery : Chapter 7 The Commit Stage