Trick ! “หลักการพัฒนา CI – Continuous Integration”

Continuous Integration คนส่วนใหญ่จะเรียกว่า  CI  คือ การบูรณาการอย่างต่อเนื่อง

        แต่ก่อนจะพูดถึง CI  เราต้องพูดถึงหลักการของ Waterfall Model คือ ต้นแบบของกระบวนการพัฒนาซอฟต์แวร์ ซึ่ง CI ใช้หลักการของ

Waterfall Model มาพัฒนาโปรแกรม ซึ่งมีกระบวนการทำงานดังนี้

 

1

 

ข้อดี  การทำงานเข้าใจง่าย จะทำจากบนลงล่างตามลำดับ และ มีการกำหนด Product ที่ต้องส่งมอบในแต่ละงานอย่างชัดเจน

ข้อเสีย  ลูกค้าเห็นและทดลองใช้ Software ก็ต่อเมื่อถึงขั้นตอนสุดท้าย หากมีบางอย่างที่ไม่ตรงกับความต้องการของลูกค้า ไม่สามารถแก้ไขได้การแก้ไขจำเป็นต้องเริ่มรอบใหม่ทั้งหมด


 

CI – Continuous Integration คืออะไร !?

           คนส่วนใหญ่จะเข้าใจกันผิด ๆ คิดว่า CI มันเป็นเครื่องมือ แต่จริง ๆ แลัวมันเป็น แนวความคิด ทัศนคติ ของการทำงานเป็นทีม และมีหลักการพัฒนาซอฟต์แวร์เป็นส่วนหนึ่งของ  Agile ซึ่งสมาชิกทุกคนในทีมจะต้อง Check-in-Code ไปยัง repository ทุก ๆ ชั่วโมง หรือ ทุก ๆ การเปลี่ยนแปลงยิ่งทำบ่อยยิ่งดี เพราะว่าการ Check-in มันจะทำให้เกิดการพูดคุยภายในทีมอยู่เสมอ ในส่วนการทำงาน Automated Test ตรงนี้จะช่วยให้เราเจอข้อผิดพลาดของระบบได้เร็วที่สุดที่จะเป็นไปได้ และ CI ถูกสร้างขึ้นมาเพื่อลดปัญหารวมส่วนต่างๆ ของระบบเพื่อทำงานร่วมกัน Integration

โดยในโลกของการพัฒนานั้น มักใช้ Build Server มาช่วยเพื่อให้เป้าหมายที่ตั้งไว้สำเร็จ กล่าวคือ จะเริ่มทำการ Integration กันตั้งแต่เมื่อมีการเปลี่ยนแปลง Source Code ที่ Repository กลาง ระบบจะทำการตรวจสอบ Code หลังจากการเปลี่ยนแปลงว่าทำงานร่วมกันได้หรือไม่ตั้งแต่ Compile, Testing

77

         โดยการ Testing จะเริ่มตั้งแต่ Unit Testing  ซึ่งสร้างจากทีมพัฒนา และเป็นส่วนจะใช้ตรวจสอบว่าสิ่งที่ทีมพัฒนายังทำงานถูกต้องและจะใช้เวลาช่วงสั้น ๆ เท่านั้น ทีมพัฒนาจะได้ Feedback กลับมาอย่างรวดเร็ว ต่อมาทีมพัฒนาจะตรวจสอบคุณภาพของ Source Code ก่อนที่จะทำการทดสอบแบบ Integration test, Acceptance test ซึ่งช่วยเหลือในการทำ Regression test โดยกระบวนการเหล่านี้ทำเพื่อตรวจสอบเรื่องของคุณภาพ และต้องทำงานอัตโนมัติ สิ่งที่เน้นย้ำ คือ Feedback ที่รวดเร็วในการ Integration มันจะทำให้เราเห็นปัญหาที่เกิดขึ้นทั้งหมดของระบบ ซึ่งลดเวลาในการค้นหาปัญหาและที่สำคัญช่วยลดเวลาในภาพรวมของการพัฒนา การรวมกัน ด้วยคุณภาพที่สูง

ขั้นตอนของ CI

  1. ระบบ CI จะเริ่มตรวจสอบรหัสของคุณ (CVS, การโค่นล้ม Perforce, ClearCase, ภาพและแหล่งที่ปลอดภัย ฯลฯ ) ระบบส่วนใหญ่สามารถตรวจสอบแหล่ง ข้อมูลอื่น ๆ เช่น วิธีการที่ซอฟต์แวร์รู้ว่ามันถึงเวลาสำหรับการสร้าง ทุกครั้งที่มีการเปลี่ยนแปลงรหัสของคุณระบบ CI ตรวจสอบออกรุ่นล่าสุดของรหัสของคุณ
  2. ซอฟต์แวร์จะตรวจสอบโครงการของคุณ ระบบจะทำงานสร้างสคริปต์ที่มีอยู่โดยการตัดพวกเขาในสคริปต์ ในขั้นตอนนี้ซอฟแวร์ CI ของคุณจะต้องให้คุณมีสคริปต์ หากคุณไม่ได้สร้างความแข็งแกร่งหรือทำซ้ำเครื่องมือ CI ของคุณจะเปิดเผยข้อบกพร่องนี้ มันจะบังคับให้คุณที่จะมีการสร้างระบบการทำความสะอาด
  3. การทดสอบระบบ CI คุณสร้างใหม่ การทดสอบจะถูกสร้างขึ้นในกรอบ xUnit (Junit, Nunit, HtmlUnit, JsUnit ฯลฯ ) ซึ่งหมายความว่าคุณมีการเข้าถึงหลายสิบของกรอบการทดสอบที่อยู่ในช่วงการทดสอบ Fromunit เบราว์เซอร์คลิกผ่านการทดสอบ เมื่อคุณตั้งค่าระบบ runtests คนมีแนวโน้มที่จะเขียนการทดสอบ พวกเขายังจะมีส่วนร่วมในการทดสอบที่พวกเขาได้รับการหลบซ่อนตัวอยู่ในเครื่องของตัวเอง
  4. ขั้นตอนสุดท้ายระบบ CI ของคุณจะแจ้งให้ผลของทุกคน นักพัฒนาหรือผู้ทดสอบที่เพิ่งเปลี่ยนรหัสจะได้รับอีเมลบอก Themhow ยาวการสร้างและการทดสอบเอาหลายวิธีการทดสอบผ่านไปกี่ล้มเหลว ฯลฯ ระบบของคุณจะยังเก็บผลไปยังหน้าเว็บ

          อย่างไรก็ตามขั้นตอนการพิมพ์สามารถกำหนดค่าได้มาก คุณสามารถเผยแพร่ในความหลากหลายของวิธีที่น่าสนใจเกินหน้าเว็บมาตรฐานคุณ Canpublish ไปยังหน้าเว็บที่กำหนดเองเข้าสู่ระบบ XML, อีเมล์, ไคลเอนต์ข้อความโต้ตอบแบบทันที Oreven โคมไฟลาวา ขั้นตอนที่เผยแพร่เป็นวิธีที่มีความยืดหยุ่นมากในการแบ่งปันผลงานสร้างของคุณ

ส่วนสำคัญของ CI

         มีการปฏิบัติที่สำคัญหลายประการที่บูรณาการอย่างต่อเนื่องทั้งต้องใช้หรือสนับสนุน พวกเขามีการจัดการซอร์สโค้ดสคริปต์ Buildsand อัตโนมัติมาทดสอบผลประโยชน์ที่มาจากการใช้ระบบ CI จริงมาจากการปฏิบัติพื้นฐานว่าระบบ CI ต้องไม่ได้รับผิด CI เพิ่มความความสมบูรณ์ของผลประโยชน์เช่นกัน มันเป็นเพียงแค่ปัญหาแบบวันต่อวัน เมื่อคุณใช้การปฏิบัติอื่น ๆ เหล่านี้

 

  1. Maintain a single Source repository

          สามารถทำการ build บนเครื่องเปล่าๆ ได้เลยเรื่องการใช้พวก version control นั้นแนะนำให้มี main branch ในการพัฒนาระบบเพียง branch เดียวเนื่องจากยิ่งมีมาก ยิ่งเกิดปัญหามาก

  1. Automate the build

          การ deploy หรือ run ระบบนั้นมักจะมีกระบวนการที่ซับซ้อนเช่นการ compile การ copy หรือย้ายไฟล์ การสร้างหรือแก้ไข schema database รวมทั้งอาจจะมีกระบวนการอื่นๆ อีกมากมาย โดยในการ build สามารถใช้เครื่องมือมาช่วยได้ เช่น ภาษา Java สามารถใช้พวก Maven, Gradle ช่วย ซึ่งสั่งให้ build ได้ด้วยชุดคำสั่งเดียว มันสะดวกสบายมากAutomated build ที่ดีสามารถที่จะ build และ run บนเครื่องเปล่าๆ ได้เลย

  1. Make your Build self-testing

          การทดสอบตามแนวคิด TDD ไม่ได้หาข้อผิดพลาดในทุกๆ อย่างหรือทำแล้วจำนวนข้อผิดพลาดจะเป็นศูนย์เพราะว่าไม่มีอะไรที่ perfect ไปหมดทุกอย่างหรอกนะแต่ถ้าเรา run การทดสอบบ่อย เพื่อหาข้อผิดพลาดมากกว่า

  1. Everyone Commits To the Mainline Every Day

          Integration คือ การพูดคุยและการติดต่อสื่อสาร อนุญาตให้แต่ละคนในทีมบอกหรือคุยกันว่า มีอะไรเปลี่ยนแปลงบ้าง โดยการ commit ควรที่จะไป branch หลักที่ทำการ build เสมอ เพื่อจะไม่เสียเวลาในการ merge ไปมา ต่อไปจะมาดูขั้นตอนการ commit การเปลี่ยนแปลง ที่ควรจะทำเป็นดังนี้

  • ดึงการเปลี่ยนแปลงล่าสุดจาก repository กลางมาที่เครื่องก่อน
  • ทำการ run ชุดทดสอบว่าผ่านทั้งหมด
  • ทำการแก้ไขตามความต้องการ
  • เมื่อทำการแก้ไขเสร็จ ให้ทำการ run ชุดทดสอบให้ผ่าน
  • ทำการดึงการเปลี่ยนแปลงล่าสุดจาก repository กลาง
  • ถ้ามีการเปลี่ยนแปลงและ conflict กันก็แก้ไขซะ
  • ทำการ run ชุดทดสอบให้ผ่านอีกรอบ
  • เมื่อทุกอย่างเรียบร้อย จึงทำการ commit ไปยัง repository กลาง
  1. Every Commit Should Build the Mainline on an Integration Machine

          การ commit ไป แล้ว build server มัน fail นั้นเป็นสิ่งที่ไม่ได้แย่แต่มันบอกสิ่งที่เรายังต้องปรับปรุง เพื่อให้มันผ่านอยู่เสมอ ทำให้เราพัฒนาระบบอยู่บนสิ่งที่มันยังทำงานได้ มีสุขถาพที่ดีอยู่เสมอ

  1. Keep the Build Fast

หัวใจของ Continuous Integration คือ fast feedback ดังนั้นถ้าคุณทำการสร้างระบบ Continuous Integration แล้วมันช้า นั่นแสดงว่าคุณมาผิดทาง ในแนวปฎิบัติของ XP programming บอกว่าคำว่า fast feedback คือเวลาไม่เกิน 10 นาที ดังนั้นยิ่งเวลาน้อย คุณสามารถไปทำงานอื่นได้เพิ่มอีกมาก

 

Continuous Integration Workflow

 

  1. Test in a Clone of the Production Environment

         ควรทดสอบอยู่บน environment เหมือนกับ server เน้นย้ำว่าควรเหมือนกันให้มากที่สุดเท่าที่จะทำได้ เช่น Hardware, Software, IP, port ต่างๆ เป็นต้น จะไม่เกิดความผิดพลาดแปลกๆ เมื่อ deploy ขึ้น production server แน่นอนว่าเจอกันบ่อยๆ แน่นอน

  1. Make it Easy for Anyone to Get the Latest Executable

         คนที่เกี่ยวข้องสามารถเข้าถึงระบบงานล่าสุดได้เสมอ ตัวอย่างเช่นใน java project เราจะต้องสามารถนำพวก WAR, EAR ล่าสุดที่ build ผ่านมาใช้งานได้ทันที เมื่อต้องการไม่ใช่ว่าต้องการเมื่อไร จะทำการ build เมื่อนั้น ซึ่งผิดมากๆ

  1. Everyone can see what’s happening

         แนวปฏิบัตินี้สำคัญมากๆ ถ้าคุณทำ Continuous Integration แล้วคุณต้องโชว์เพื่อแสดงให้เห็นสิ่งที่คุณกำลังทำอยู่ว่า มันเป็นอย่างไร การโชว์ไม่จำเป็นต้องผ่านจาก computer เท่านั้น ยังสามารถทำเป็น physical board ได้ เช่นการนำปฏิทินกระดาษมาแปะไว้ แล้วทำกระดาษมาแปะในแต่ละวัน เพื่อบอกสถานะการทดสอบก็ได้ทำให้การทำงานสนุกมากยิ่งขึ้น เพราะการทำ Continuous Integration แล้ว มันต้องโชว์

  1. Automate Deployment

        ในระบบ Continuous Integration นั้นควรที่จะมีมากกว่า 1 เครื่องหรือมากกว่า 1 VM (Virtual Machine) เนื่องจากทำให้สามารถขั้นตอนการ build ออกจากส่วนการทดสอบแบบต่าง ๆ ได้ง่าย ดังนั้นสิ่งที่คุณต้องการก็คือ การ deploy ระบบงานลงในเครื่องต่างๆ ต้องไปปรับให้มันทำงานแบบอัตโนมัติด้วยเช่น

  • dev server
  • test server
  • SIT server
  • SUT server
  • Staging server
  • Production server

    สุดท้ายอย่าลืมว่า Continuous Integration มันไม่ใช่เครื่องมือ แต่มันคือหลักการของระบบที่ใช้ในการพัฒนาและปรับปรุงนะครับผม” 

    6

 

ขอบคุณแหล่งอ้างอิงจาก : http://www.somkiat.cc/tag/97-thing-developer-should-know/

 

  •  
  •  
  •  
  •  
  •  
  •  
Titiphong Phetmanee
at GlurGeek.Com

One comment

  1. “หากขาดตกบกพร่องประการใดก็ช่วยแสดงความคิดเห็น ตำหนิ ติ ชม ไว้ด้วยนะครับ
    และขออภัยไว้ ณ ที่นี้ด้วยนะครับผม
    ขอบคุณครับผม”

Leave a Reply