[Node Js] มาลองทำ CI บน GitLab

Jedsada Tiwongvorakul
20Scoops CNX
Published in
3 min readAug 22, 2017

ณ ปัจจุบันนักพัฒนาทั้งหลายไม่ว่าจะในฝั่งของเว็ปไซต์หรือบนมือถือก็คงได้ยินคำว่า Continuous Integration (CI) กันมาหนาหูพอสมควร แต่ทว่า CI มันคืออะไรล่ะ และมีเครื่องมืออะไรที่ช่วยในการทำบ้างล่ะ? ไปดูกันเลย ปู้น ปู้น 🚃

เริ่มต้นด้วย CI คืออะไร

Continuous Integration (CI) คือ เครื่องมือในการทำบูรณาการอย่างต่อเนื่องให้เป็นเรื่องธรรมดาในการพัฒนาองค์กรมากที่สุด… แปลออกมาแล้วดู งง เหลือเกิน เอาเป็นว่ามันคือการนำ Code มารวมกันแล้วนำมา Build และทดสอบด้วยระบบงานอัตโนมัติ สามารถอ่านรายละเอียดเพิ่มเติมจากด้านล่างได้เลย 👇

เครื่องมือในการทำ CI

สำหรับเครื่องมือในการทำ CI นั้นมีหลายตัวมากยกตัวอย่าง เช่น jenkins, Travis-CI, CircleCI, Gitlab CI, buddybuild และ อื่นๆ

http://www.uqasar.eu/wp-content/uploads/2015/03/logos-continuous-integration-tools.png

แต่ในบทความนี้เจ้าของบล็อคขอยกตัวอย่างการทำ CI ด้วย Gitlab CI ซึ่งในบทความนี้จะใช้ Node Js ในการทำซึ่งเจ้าของบล็อคต้องขอออกตัวก่อนว่าพึ่งหัดเขียนนะครับ เอาล่ะมาเริ่มกันเลย ✌️

สำหรับคนที่จะเริ่มต้นหัด Node Js สามารถอ่านเพิ่มเติมได้จากด้านล่างนี้เลยนะครับ

ขั้นตอนแรก เจ้าของบล็อคก็ทำสร้างโปรเจ็คโดยจะมีไฟล์ดังต่อไปนี้

โครงสร้างไฟล์ในตัวอย่าง

เริ่มจากไฟล์ index.js ก็จะมีชุดโค้ดดังนี้

ต่อไปก็จะเป็นไฟล์ test.js ก็จะมีการเขียน test คลาส Calculator ดังนี้

และสุดท้ายในไฟล์ package.json ก็จะมีหน้าตาประมาณนี้

จากตัวอย่างด้านบนเจ้าของบล็อคใช้ mocha ในการเขียน test และ ในส่วนของ report จะใช้ mochawesome เพื่อที่จะดู result ของ test ในรูปแบบ html สวยๆ และใช้ nyc เพื่อที่จะดูผลการ coverage ของ test ซึ่งเมื่อทำการสั่ง npm test ก็จะได้ report ที่มีหน้าตาประมาณนี้ออกมา

report test ของ mochawesome
report coverage ของ nyc

ขั้นตอนที่สอง เอาล่ะก็มาถึงพระเอกของงานสักที ซึ่งการทำ CI ใน Gitlab CI นั้นต้องทำการสร้างไฟล์ .gitlab-ci.yml ไว้ในโฟลเดอร์ของโปรเจ็คซะก่อน

ภาพประกอบเฉยๆ นะครับ

โดยในไฟล์ .gitlab-ci.yml ก็จะมีชุดคำสั่งดังนี้

  • image คือ Docker Image ในที่ก็จะเป็นเวอร์ชั่นของ node js ก็สามารถเข้าไปเลือกเวอร์ชั่นได้ตามต้องการได้ที่นี่
  • before_script คือ script ที่ต้องการจะให้ทำงานก่อนจะถึง job ที่เราต้องการ
  • after_script คือ script ที่ต้องการหลังจาก job ทำงานเสร็จ เช่น เมื่อทำงานเสร็จให้ส่ง message ไปที่ slack อะไรประมาณนี้ซึ่งในตัวอย่างจะเป็นการ echo เฉยๆ
  • cache คือ ใช้เพื่อระบุ file หรือ directory ที่ต้องการเก็บ cache ในระหว่างการทำงานของ job อย่างเช่นในตัวอย่างจะเก็บ cache ของ node_module เอาไว้เพื่อกันไม่ให้ติดตั้งใหม่ทุกครั้งของการเริ่ม job ใหม่
  • stages คือ ใช้ในการกำหนดขั้นตอนของการทำงาน โดยสามารถมี stage ได้มากกว่าหนึ่ง ซึ่งในตัวอย่างจะมี stages ได้แก่ build, test และ deploy
  • job คือ งานที่ต้องการจะทำซึ่งสามารถมีได้มากกว่าหนึ่ง และ job ในตัวอย่างก็ได้แก่ build, lin_test, unit_test และ deploy_code โดยแต่ละ job สามารถกำหนดคำสั่งที่ต้องการได้ใน tag script และการกำหนดในอยู่ stages ที่กำหนดไว้โดยกำหนดใน tag stage ซึ่งข้อดีของการกำหนด stage นั้นจะทำให้ดู pipelines ใน Gitlab ได้ง่าย และแบ่งการทำงานอย่างชัดเจนนั่นเอง

ข้อสังเกต ใน job unit_test เจ้าของบล็อคได้มีการกำหนด tag artifacts ไว้เพื่อทำการอัพโหลด directory ของ report test และ coverage เอาเพื่อที่จะสามารถดาวน์โหลดไปดูได้ หรือถ้าเป็น Android ก็จะเป็นไฟล์ .apk เอาไว้ให้คนในทีมสามารถโหลดไปเทสเล่นได้

ซึ่งในบทความนี้เป็นการตั้งค่าแบบเบื้องต้นเท่านั้นสามารถเข้าไปอ่านเพิ่มเติมจากด้านล่างนี้ได้เลยครับผม

ต่อไปก็ให้ทำการ push โค้ดขึ้น git ของ Gitlab ก็เป็นอันเสร็จสิ้นกระบวนการก็ให้ไปดูที่เมนู pipelines ของ repository นั้นก็จะได้หน้าตาประมาณนี้ออกมา

และเมื่อกดไปที่คำว่า running ก็จะได้หน้าตาดังนี้

จะเห็นได้ว่าเป็นไปตาม stages ที่เราได้กำหนดไว้หน้าตาดูดีเลยทีเดียวแต่ถ้าหากเราไม่ได้กำหนด stages หน้าตาก็จะออกมาประมาณนี้

สามารถเข้าไปดู log ของ job ได้ว่าทำอะไร หรือทำถึงไหนแล้วได้โดยคลิกที่ job ที่ต้องการจะดูก็จะได้ผลลัพธ์ดังนี้

และสุดท้ายเมื่อทำงานสิ้นหมดทุก job แล้วก็จะมีให้ดาวน์โหลด artifacts ซึ่งจะเป็น report ของการ test และ coverage ใน stage ของ unit_test ดังนี้

ก็มีไว้ให้ทีมดาวน์โหลดไปดูเล่น ฮ่าๆ

สุดท้ายในการ push code ขึ้น Git ทุกครั้ง CI ก็จะทำงานทันทีถ้าไม่เขียวเมื่อไหร่ละก็รู้เรื่องเลย ฮ่าๆ และตัวของ Gitlab-CI นั้นยังมีลูกเล่นอีกอย่างหนึ่งที่น่าสนใจ คือการตั้ง Schedules ของการทำงาน CI ได้อีกด้วยโดยให้คลิกไปที่เมนู Schedules โดยจะมีหน้าตาดังนี้

และเมื่อกดสร้าง Schedules ก็จะมีหน้าตาให้ตั้งค่าเยอะแยะมากมาย ดังภาพข้างล่าง

ก็สามารถลองเล่นได้ตามใจชอบได้เลยครับผม 🔥

สรุป

การทำ Continuous Integration (CI) บน Gitlab ก็ถือเป็นอีกตัวเลือกหนึ่ง สำหรับใครที่ใช้ Git ของ Gitlab เพราะโดยส่วนใหญ่ Tools ของการทำ CI ที่ฟรีก็จะถูกเทให้ไปใช้ Github หรือ Bitbucket กันซะหมด เช่น Travis-CI, CircleCI หรือ buddybuild ซึ่งพวกนี้เท่าที่เจ้าของบล็อคได้สัมผัสมา รู้สึกว่ามีความง่ายในการติดตั้งมากกว่า Gitlab-CI พอสมควรเลยทีเดียว บางอันนี้กด next อย่างเดียวเลยก็ว่าได้ ก็หวังว่าบทความนี้จะเป็นประโยชน์สำหรับใครที่สนใจในการเริ่มต้นทำ CI บน Gitlab นะครับ

--

--