> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/cloud/azure-devops/ci.md).

# ลองทำ Continuous Integration (CI)

{% hint style="success" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของคอร์ส [**👶 Azure DevOps**](https://saladpuk.gitbook.io/learn/cloud/azure-devops) ที่จะมาสอนการใช้งานทุกสิ่งที่ DevOps ควรจะต้องมี เพื่อให้เราสามารถทำ Feedback loop ได้ไวขึ้น ดังนั้นถ้าเพื่อนๆสนใจอยากดูว่ามันทำอะไรได้ก็กดไปอ่านที่บทความหลักได้เลยครัช
{% endhint %}

{% hint style="warning" %}
**คำเตือน**\
ถ้าเพื่อนๆต้องการทำตามบทความนี้ จะต้องมีโปรเจคใน **Azure DevOps** ที่มีการนำ source code ตัว asp.net core mvc ขึ้นมาไว้บน repository เสียก่อน แต่ถ้าใครยังไม่มีก็สามารถไปทำตามได้จากบทตัวนี้ก่อน [**เล่นกับ Repository**](https://saladpuk.gitbook.io/learn/cloud/azure-devops/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 %}

![](/files/-LwnGvhU_QutD8ribW58)

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

![](/files/-Lrxlp1XcqNDVafSPfit)

### สร้าง Continuous Integration

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

![](/files/-LsfTdVYf8URt6enSmSi)

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

![](/files/-Lpqh-brGdTR_NFsjAcf)

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

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

![](/files/-Lps7PEguZRvX6sSQu-r)

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

![](/files/-LsoXY1QUW1tmrt3xyiM)

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

![](/files/-LrxbQinZau-P2jrJ2IQ)

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

![](/files/-LplAXO_VqPjFBfMaYhT)

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

{% hint style="info" %}
**แนะนำให้อ่าน**\
สำหรับรายละเอียดการสร้าง yaml เพื่อทำ run steps นั้นสามารถอ่านได้จากลิงค์หลักของ Microsoft ได้เลย ส่วนถ้าเพื่อนๆใช้ภาษาอื่นในการเขียนเว็บก็สามารถเลือกภาษาที่ตัวเองใช้ได้จากเมนูด้านซ้ายมือเลย\
[Microsoft document - Build, test, and deploy .NET Core apps](https://docs.microsoft.com/en-us/azure/devops/pipelines/ecosystems/dotnet-core?view=azure-devops)
{% endhint %}

![](/files/-LnHR829jP6PPd_btc-h)

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

![](/files/-LoFyqyHugO_hqOi9Gcb)

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

![](/files/-Lsf8td5Pv2VhYbYFgMg)

### ผลลัพท์

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

![](/files/-Lw4dJi_fnpCqD9RqC5s)

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

![มองไม่เห็นก็กดที่รูปเอาละกันนะ](/files/-LwlNFEC_rvaJImlfCs2)

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

![](/files/-LoQezoYy0hbXZ3SXh5E)

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

![](/files/-LoQgjXX6VJbYqqHrWl9)

### แก้ไข Continuous Integration

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

![](/files/-Lrxlp1XcqNDVafSPfit)

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

![เสียใจด้วยรูปโปรไฟล์หล่อๆอันนี้เป็นของผมนะจุ๊](/files/-LoChpw-bnTegK0gQjK-)

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

![](/files/-Lngbtfoj-LBgVWduPmw)

## 🔥 ลองแก้โค้ด

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

```
saladpuk\Views\Home\Index.cshtml
```

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

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

![](/files/-Lwmmu3UaX09PuWzAZTu)

แล้วก็ทำการ 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)**](https://saladpuk.gitbook.io/learn/basic/devops#infrastructure-as-code-iac)
{% endhint %}

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

![](/files/-LsX7G60Pz12BidSt8eI)

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

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