ออกตัวก่อนว่า เราพึ่งได้มีโอกาสเข้ามาสัมผัสการพัฒนาระบบโดยการนำหลักการ CI/CD เข้ามาใช้งาน แล้วมีความรู้สึกว่ามันสะดวกและเร็วขึ้นมาก ช่วยส่งเสริมกับเรื่องการส่งมอบงานเป็นรอบและส่งให้ได้ไว เพื่อให้มีการ feedback เร็ว
ซึ่งเราอยู่ใน role QA เพื่อนๆคงคิดใช่มั้ยว่าแล้ว QA เรามีส่วนร่วม ทำ automated testing ในกระบวนการ CI/CD อย่างไรตอนไหนบ้าง งั้นเราทำความรู้จัก CI/CD กันก่อนดีกว่าว่าคืออะไรแล้วมีหลักการอย่างไรบ้าง
CI/CD คืออะไร?
Continuous Integration (CI) คือ กระบวนท่าที่ใช้สำหรับการรวบรวมซอฟแวร์ที่มีการพัฒนาแยกส่วนกันอย่างอัตโนมัติ อาจจะโดยหนึ่งหรือหลายนักพัฒนาก็ตามที สุดท้ายแล้วซอฟแวร์ที่พัฒนาชิ้นเล็กๆ ที่พัฒนาขึ้นมาจะต้องนำมารวมกันเป็นชิ้นใหญ่หนึ่งชิ้น จะทำอย่างไรให้มั่นใจได้ว่า ไม่มีชิ้นส่วนใดที่จะส่งผลให้ชิ้นส่วนอื่นๆ พังเสียหาย เนื่องจากเป็นการพัฒนาโดยโปรแกรมเมอร์หลายคน
ซึ่งเป็นไปได้ว่าจะมี bug หลุดมาจากส่วนใดส่วนหนึ่ง แล้วเราจะป้องกันได้อย่างไรละ ดังนั้นจึงต้องมีการเขียน script test ที่คอยทดสอบความเข้ากันได้ของแต่ละชิ้นส่วนโดยอัตโนมัตินั่นเอง โดยการ Testing จะเริ่มตั้งแต่ Unit Testing ซึ่งสร้างจากทีมพัฒนา และเป็นส่วนจะใช้ตรวจสอบว่าสิ่งที่ทีมพัฒนายังทำงานถูกต้องและจะใช้เวลาช่วงสั้น ๆ เท่านั้น
โดยในโลกของการพัฒนานั้น มักใช้ Build Server มาช่วยเพื่อให้เป้าหมายที่ตั้งไว้สำเร็จ กล่าวคือ จะเริ่มทำการ Integration กันตั้งแต่เมื่อมีการเปลี่ยนแปลง Source Code ที่ Repository กลาง ระบบจะทำการตรวจสอบ Code หลังจากการเปลี่ยนแปลงว่าทำงานร่วมกันได้หรือไม่ตั้งแต่ Compile, Testing
Continuous Delivery และ Continuous Deployment (CD) มักจะเกิดคำถามขึ้นมาเสมอว่า มันแตกต่างกันอย่างไร ? ทำไมต้องใช้ชื่อแตกต่างกันด้วยล่ะ ? ดังนั้นมาดูกันว่าแต่ละ คำคืออะไร และแตกต่างกันอย่างไร
Continuous Deployment คือ ในทุกๆ ขั้นตอนจนถึงการ deployment ขึ้น production จะทำแบบอัตโนมัติทั้งหมด
Continuous Delivery คือ การงานต่างๆ ใน deployment pipeline นั้น จะเริ่มต้นทำงานตั้งแต่การ compile, build ไปจนถึงขั้นตอนการทดสอบต่างๆ เช่น Acceptance test เป็นแบบอัตโนมัติทั้งหมด ส่วนในขั้นตอนการ deployment ขึ้น production นั้น จะต้องได้รับการอนุมัติหรือการตัดสินใจกันก่อนจากทาง Business ซึ่งเป็นการทำงานแบบ manual นั่นเอง หรืออาจจะเป็น One Click Deploy ก็ได้
ซึ่งในส่วนของที่ทีมเราใช้เป็นแบบ Continuous Delivery นั่นเองแต่ของเราทั้ง step deploy to Staging Environment และ deploy to Production Environment เป็น manual One Click Deploy ซึ่ง staging อำนาจการตัดสินใจอยู่ในมือ QA เป็นคน Click ส่วน Production ยกให้ Business เขาเลยจ้า
ซึ่งส่วนของการทำชุดทดสอบระบบนั้น QA เราจะทำการ เลือกชุด test case ที่เป็น Smoke test , Regression test ขึ้นมา สำหรับแต่ละ component หรือ service ย่อยๆ การเพิ่มเติมเขียน script automated testing เรา ใช้ Git ผ่าน Source Treeในการ จัดการ source code automated test case และ ใช้ Jenkins ในการ config ให้ Trigger สั่งให้ Run ชุดทดสอบ automated testing ในแต่ละ environment
แล้ว เรานำ Automated test ไปใช้ทดสอบในช่วงไหนของกระบวนการ CI/CD กันหล่ะ?
Automated testing ถูกนำไปใช้ใน Process ของ CI นั่นเอง..!!
กล่าวคือ ทุกการเปลี่ยนแปลงหนึ่งในนั้นคือ การทดสอบนั่นเอง แน่นอนว่า ต้องเป็นการทดสอบแบบอัตโนมัติอย่างแน่นอน (Automated testing) ไม่ว่าจะเป็น Unit testing, Integration testing และ Functional testing
ซึ่งขออธิบายตั้งแต่เรื่องพัฒนาของ Developer กันเลย
ทางทีมพัฒนาระบบของเราจะแบ่ง environment เป็น 4 ส่วนคือ Local , Alpha , Staging , Production มีขั้นตอนดังนี้
1. Developer เมื่อทำการพัฒนา feature เสร็จ จะทำการ build, test และ run บนเครื่องของตัวเอง (Local) เพื่อทำให้แน่ใจว่าระบบทำงานได้ถูกต้องและให้แน่ใจว่าสิ่งที่เปลี่ยนแปลงไม่กระทบส่วนอื่น ๆ
2. ทำการดึง source code ล่าสุดจาก Repository ของระบบ เพื่อตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่ถ้ามีการเปลี่ยนแปลงก็ให้ทำการรวม หรือ merge ที่เครื่องของ Devleoper ก่อน จากนั้นจึงทำการ build, test และ run อีกรอบ เมื่อทุกอย่างผ่านทั้งหมด ให้ทำการส่งการเปลี่ยนแปลงไปยัง Repository กลาง
3. เมื่อ Repository กลางมีการเปลี่ยนแปลง จะต้องมีระบบ CI ทำการ build, หลังจาก build จะส่งต่อไป run unit testing ก่อนถ้าผ่านหมดถึงจะส่งต่อไปยังระบบ Continuous Delivery เพื่อ deploy to alpha environment (:
4. เมื่อ source code ถูก deploy to alpha environment แล้วจะ trigger ไปสั่งให้ run job automated testing ใน level ของเทสเคส smoke test ซึ่งเป็นชุดเทสเคสย่อยๆไม่เยอะมากเฉพาะในส่วนของ feature code ที่ถูก deploy มาเท่านั้น
5. หลังจาก run smoke test เสร็จแล้วถ้าเกิดว่า run มีบางส่วนไม่ผ่านทั้งหมดจะไม่ส่งต่อไปยังระบบ Continuous Delivery เพื่อ deploy to staging environment QA จะทำการ investigate ว่าเกิดจากอะไร เป็นที่ระบบมี Bug เกิดขึ้นจริงหรือไม่ ถ้ามี bug ก็ให้ dev แก้ไข และ deploy มาใหม่ วน loop ใหม่
6. กรณีหลังจาก run smoke test ผ่านทั้งหมดจะส่งต่อไปยังระบบ Continuous Delivery เพื่อ deploy to Staging environment เมื่อ source code ถูก deploy to staging แล้ว จะ trigger ไปสั่งให้ run job automated testing ใน level ของเทสเคส regression test และ QA ก็ทำการทดสอบ Acceptance testing ไปด้วยพร้อมๆกันที่ Staging environment นี้ เมื่อมีการ deploy ซำ้ๆ เพื่อ fixed bug จากที่ QA เจอ หรือที่พบเจอจากการ run regression test แล้ว fail ก็จะเป็นการวน loop ตั้งแต่ต้นจนจบ จนกระทั้ง ทุกอย่างผ่านหมด Business ฟันธง!! มาว่าเอาขึ้น production ได้ เป็นการ confirm ว่าเราจะเอา code version สุดท้ายนี้ขึ้นไปที่ production environment
ข้อดี&ข้อเสียจากการ ใช้ automated testing มาใช้กับ CI/CD
ข้อดี สามารถทดสอบได้บ่อย ๆ รู้สถานะของระบบได้ตลอดเวลา และ ได้ feedback ของระบบอยู่อย่างเสมอ ไม่ว่าจะดีหรือร้าย ทำให้ทุกคนเห็นความคืบหน้าของการพัฒนา
ข้อเสีย ถ้าเขียน script test ไม่ดีก็อาจทำให้ block การ deploy ระบบได้ เช่น เมื่อ run test แล้ว fail แต่เป็นการ fail จากการเขียน script ผิด ไม่ได้เกี่ยวกับระบบมี Bug ก็จะทำให้ไปขั้นตอนต่อไปไม่ได้
สุดท้ายนี้ก็หวังว่าทั้งหมดนี้จะพอเป็น idea ให้เพื่อนๆเอาไปปรับใช้กับทีมหรือกระบวนการพัฒนาระบบของเพื่อนๆได้บ้างไม่มากก็น้อยนะคะ ผิดพลาดประการใดก็ขออภัยมา ณ ที่นี้ด้วยนะคะ อาจจะไม่ถูกต้องทั้งหมดก็ลองเอาไปประยุกต์ใช้ให้เข้ากับการทำงานของเพื่อนๆเอานะจ้า ลองไปสามารถศึกษาข้อมูลเพิ่มเติมได้จากที่นี้เลยจ้า
http://www.bogotobogo.com/DevOps/DevOps_CI_CD_Pipeline_Sample.php
http://www.somkiat.cc/continuous-delivery-vs-continuous-deployment
http://www.somkiat.cc/imrpove-quality-with-continuous-integration
