ci.md

ลองทำ Continuous Integration (CI)

{% hint style="success" %} แนะนำให้อ่าน
บทความนี้เป็นส่วนหนึ่งของคอร์ส 👶 Azure DevOps ที่จะมาสอนการใช้งานทุกสิ่งที่ DevOps ควรจะต้องมี เพื่อให้เราสามารถทำ Feedback loop ได้ไวขึ้น ดังนั้นถ้าเพื่อนๆสนใจอยากดูว่ามันทำอะไรได้ก็กดไปอ่านที่บทความหลักได้เลยครัช {% endhint %}

{% hint style="warning" %} คำเตือน
ถ้าเพื่อนๆต้องการทำตามบทความนี้ จะต้องมีโปรเจคใน Azure DevOps ที่มีการนำ source code ตัว asp.net core mvc ขึ้นมาไว้บน repository เสียก่อน แต่ถ้าใครยังไม่มีก็สามารถไปทำตามได้จากบทตัวนี้ก่อน เล่นกับ Repository แล้วค่อยกลับมาทำตามบทความนี้ก็ได้ครัช {% endhint %}

หลังจากที่เราได้นำ source code ของเว็บ asp.net core mvc ขึ้นมาไว้บน Azure DevOps เรียบร้อยแล้ว ถัดมาเราก็จะทำการสร้าง Build pipeline เพื่อทำให้โปรเจคของเรามันทำการตรวจสอบความถูกต้องของโค้ดที่เรานำขึ้นมาต่อ โดยเป้าหมายของการทำ Build pipeline คือการทำให้ของทุกอย่างมันกลายเป็น Automation ไปทั้งหมดเพื่อลดการเสียเวลาของคนนั่นเอง ดังนั้นเราไปดูกันต่อเบย

🔥 Build Pipeline

ในการทำ Build Pipeline นั้นมันมีให้เราเล่นหลายส่วนเลย ซึ่งเนื้อหาของรอบนี้จะสอนการทำ Continuous Integration หรือที่เราเรียกย่อๆว่า CI ก่อนส่วนเรื่องที่เหลือจะแยกเอาเป็นบทถัดไปนะจ๊ะ ซึ่งเราสามารถเข้าไปจัดการ Build pipeline ได้จากเมนูด้านซ้ายมือในหมวดของ Pipeline นั่นเอง ดังนั้นจิ้มมันไปซะ

{% hint style="info" %} Continuous Integration
โดยการทำงานของ CI คือ เมื่อคนในทีมทำงานเสร็จแล้ว มันก็จะมีระบบที่เอามาตรวจสอบว่างานของเขาเรียบร้อยดีหรือเปล่า เช่น มี error ที่ทำให้ build ไม่ผ่านหรือเปล่า เทสเคสทำงานได้สมบูรณ์ไหม การตั้งค่าต่างๆเป็นไปตามที่ทีมตกลงกันหรือเปล่า บลาๆ หรือพูดง่ายๆว่า เป็นการตรวจสอบว่างานที่ทำเสร็จตัวนี้สามารถทำงานได้ตามที่ทีมตกลงกันไว้ {% endhint %}

อย่างที่บอกว่าการทำ Build pipeline มันมีให้เราเลือกเล่นหลายอย่าง ซึ่งบทความนี้จะเน้นไปที่ CI ดังนั้นการตั้งค่าต่างๆจะอยู่ในหมวดย่อยที่ชื่อว่า Builds นั่นเอง

สร้าง Continuous Integration

เจ้าโปรเจคของเราพอดีว่ามันพึ่งถูกสร้างขึ้นมาใหม่ มันก็จะยังไม่มี Build อะไรเลย ดังนั้นที่ด้านขวามือกดจงกด New pipeline ลงไปซะ

ถัดมาเขาก็จะถามว่าตัว source code ที่เราจะเอามา Build นั้นมันอยู่ที่ไหน โดยเราสามารถเอา source code มาจากที่อื่นที่ไม่ได้อยู่ใน Azure DevOps ก็ได้นะ แต่ในตัวอย่างรอบนี้ขอเล่นท่าพื้นฐานก่อนนั่นก็คือเอา source code มาจาก Azure repository ยังไงล่ะ ก็จิ้มมันลงป๊ายย

ถัดไปเขาก็จะถามว่าจะให้มันเอางานมาจาก Repository ตัวไหน ซึ่งในตัวอย่างผมมี repo เดียว ดังนั้นก็เลือกมันไปซะ

{% hint style="info" %} Azure Repository
อย่างที่บอกว่าภายใน 1 project ที่อยู่ใน Azure DevOps นั้น เราสามารถสร้าง Repository ขึ้นมาได้มากกว่า 1 ตัวนะจ๊ะ จะเป็น private ทั้งหมดเลยก็ได้ {% endhint %}

ถัดมาเขาก็จะถามว่าจะกำหนดการ Build เจ้า source code เรายังไงดี ซึ่งในตัวอย่างผมอยากโชว์ของบางอย่างเพิ่มหน่อยนึง ดังนั้นกด Show more ไปโลด

เขาก็จะโชว์ออกมาให้เห็นทั้งหมดเลยว่าเราสามารถ build source code แบบไหนได้บ้าง และต่อให้ไม่มีในรายการพวกนี้ เราก็ยังสามารถ custom build ได้อีกนะ (ชอบมากเพราะมัน build Xcode ให้ผมได้ด้วย 😍)

กลับมาเข้าเรื่องของเรากันต่อ ใน source code ของผมคือ asp.net core mvc ดังนั้นผมก็จะเลือกตัว build เป็น ASP.NET Core ไปจ๊า

เขาก็จะเตรียมอะไรต่างๆนิดหน่อย พอเสร็จแล้วก็จะได้หน้าตาออกมาประมาณนี้ ซึ่งในตอนนี้ผมยังไม่อยากลงรายละเอียดว่ามันคืออะไร แต่เอาเป็นว่ามันพร้อมที่จะ build source code เราเรียบร้อยละ ดังนั้นกด Save and run โลด

{% hint style="info" %} แนะนำให้อ่าน
สำหรับรายละเอียดการสร้าง yaml เพื่อทำ run steps นั้นสามารถอ่านได้จากลิงค์หลักของ Microsoft ได้เลย ส่วนถ้าเพื่อนๆใช้ภาษาอื่นในการเขียนเว็บก็สามารถเลือกภาษาที่ตัวเองใช้ได้จากเมนูด้านซ้ายมือเลย
Microsoft document - Build, test, and deploy .NET Core apps {% endhint %}

เขาก็จะให้เราบันทึกการตั้งค่านี้ลงไป (การบันทึกของพวกนี้ก็เหมือนกับการ commit การทำ build นั่นแหละ) ซึ่งจากตรงนี้ถ้ากำหนดค่าเสร็จแล้วก็กด Save and run ด้านล่างขวาสุดอีกที

เรียบร้อยตัว Azure DevOps ก็จะเริ่มนำ source code ของเราไป build ให้เราละ ตอนนี้ก็ได้แต่สวดมนต์อย่าให้มันมี error ไม่ก็ไปหากาแฟมาดื่มซักแก้ว

ผลลัพท์

เรียบร้อยละพอมัน build เสร็จเขาก็จะออกรายงานผลออกมาให้เรา ซึ่งในตัวอย่างของผมนั้นมัน build ได้ผ่านหมดไม่มีข้อผิดพลาดตรงไหนเลยก็จะออกมาราวๆนี้

ซึ่งในแต่ละขั้นตอน เราจะสามารถกดเข้าไปดูรายละเอียดได้ว่าเขาใช้คำสั่งอะไรในการทำงานของขั้นตอนนั้นๆ และถ้ามีข้อผิดพลาดมันก็จะแจ้งเตือนออกมาเป็นสีแดงให้เราเห็นด้วย (ตัวอย่างอยู่ด้านล่างๆ) เช่นผมอยากดูว่าตอนเขาทำ dotnet build Release มันทำอะไรบ้างก็ลองกดเข้าไปดู ก็จะออกมาราวๆนี้

ถัดมาในหมวดของ Summary เขาก็จะสรุปให้เราดูว่าไอ้ที่ build ไปนั้นผลเป็นยังไง มี commit ไหนบ้างที่เกี่ยวข้อง และสุดท้ายเคยถูกเอาไป deploy สักครั้งหรือเปล่า (ในส่วนของการ deploy จะอยู่ในเรื่อง Continuous Delivery ของบทถัดไปครัช)

ส่วนในหมวด Test จะเป็นการสรุปว่า test cases ต่างๆของเราผ่านครบหมดหรือเปล่า ซึ่งในโปรเจคของเรายังไม่มีในส่วนนี้ ดังนั้นพอกดเข้าไปมันก็จะบอกว่ายังไม่มีนะจ๊ะ ลองไปสร้างเล่นแล้ว push ขึ้นมาใหม่ดูสิ

แก้ไข Continuous Integration

หลังจากที่เราได้ลองสร้าง CI และลอง Run จนเสร็จเรียบร้อยแล้ว คราวนี้ถ้าเราอยากจะไปแก้ไข CI ที่เรามีอยู่ก็สามารถทำได้โดยการกดที่เมนู Builds เจ้าเก่าตามรูปด้านล่าง

หลังจากกดไป เขาก็จะเปิด Build ทั้งหมดที่เรามีออกมาให้ ซึ่งจากขั้นตอนทั้งหมดเรามี 1 ตัวที่ทำงานเสร็จแล้ว ดังนั้นเราก็จะเห็นหน้าตาประมาณนี้

ซึ่งจากจุดนี้ถ้าอยากแก้ไขตัว build อันไหนก็ให้เลือก build ที่ต้องการจะแก้ แล้วกดปุ่ม Edit ด้านบนขวาเอาเด้อ

🔥 ลองแก้โค้ด

จากตรงนี้ผมก็จะลองไปแก้ไขโค้ดในเครื่องผมนิดหน่อยแล้วทำการ push งานขึ้นมาใหม่อีกครั้ง โดยแก้ไขไฟล์

saladpuk\Views\Home\Index.cshtml

โดยแก้โค้ดบรรทัดที่ 2 เป็นแบบนี้

ViewData["Title"] = "Saladpuk Home Page";

แล้วก็ทำการ commit + push งานขึ้นไปอีกครั้งด้วยคำสั่ง

git add .
git commit -am "Changed the home title"
git push

{% hint style="warning" %} Failed to push
ถ้าทำตามขั้นตอนที่ผมเขียนไว้เป๊ะๆจะพบว่ามัน push ไม่ได้นะครับ เราต้องใช้คำสั่ง git pull ลงมาก่อน แล้วเราจะเห็นว่ามันมี commit ที่เราไปตั้งค่า build pipeline อยู่ด้วยนั่นเอง นั่นแสดงว่าทุกอย่างที่อยู่บน Azure DevOps นั้นก็มี git state อยู่นั่นเองครัช คราวนี้ก็หวานหมูเราเลยเพราะทุกอย่างเราสามารถย้อนหน้าถอยหลังได้หมดอย่างแท้จริง เพราะเขาเตรียมให้เราทำสิ่งที่เรียกว่า Infrastructure as Code ไวเรียบร้อยแบ๊ว ส่วนมันคืออะไรก็ไปอ่านคร่าวๆได้จากลิงค์นี้ครัช 👶 DevOps พื้นฐาน - (IaC) {% endhint %}

พอเรา push งานได้เรียบร้อย ลองกลับไปดูที่ตัว Azure DevOps ของเราอีกครั้งในเมนู Builds เหมือนเดิม เราจะพบว่า มันกำลัง build source code ที่เราพึ่ง push ขึ้นไปให้เราอยู่นั่นเอง นี่แหละพลังแห่ง Automation ที่จะช่วยตรวจสอบโค้ดต่างๆให้เราอัตโนมัติทันทีที่งานมีการแก้ไข

จากตรงนี้เราก็น่าจะเห็นภาพคร่าวๆกันแล้วนะว่า การทำ Build pipeline ในส่วนของ Continuous Integration หรือที่เราเรียกกันติดปากว่า CI นั้นมันทำง่ายแค่ไหน ซึ่งเจ้านี่แหละจะช่วยลดเวลาของเหล่า developer ลงได้เยอะเลยถ้าเราใส่ กฎกติกา ของทีมเราลงไปในการทำ build เช่น ถ้า test cases พวกนี้ไม่ผ่านไม่ให้ไปต่อ หรือ ถ้าเรื่องนี้ยังไม่ได้ก็ต้องมีการ report บลาๆนั่นเอง

ซึ่งจากจุดนี้ในบทถัดไปเราจะไปดูในเรื่องของการทำ Build pipeline ในส่วนที่ 2 กันบ้างนั่นคือการทำ Continuous Delivery หรือ CD นั่นเอง เพื่อช่วยให้เราเอางานขึ้น Environments ต่างๆได้โดยที่ไม่เกิดข้อผิดพลาดนั่นเอง ดังนั้นกดปุ่ม Next ด้านล่างเพื่ออ่านบทถัดไปเบย