ลองอ่านคอนเซ็ปตอนแรกตื่นเต้นมากครับ นึกว่า DigitalOcean ทำ Serverless ออกมาแล้ว แต่จริงๆเป็น PaaS (Platform as a Service) ตัวหนึ่ง ที่ช่วยสร้าง Infrastructure ต่างๆ ให้โดยที่เราไม่ต้องจัดการอะไรเองเลย แต่ก็ยังตื่นเต้นอยู่นะ เพราะมันทำด้วย Kubernetes ที่ Scaling ได้ และรองรับภาษาหลายตัว รวมถึง PHP ด้วยจ้า

มีอะไรน่าสนใจใน DigitalOcean App Platform

ก่อนจะพาดูผมทดสอบ ขอขายของให้สุดก่อน ว่าทำไมผมถึงชอบมัน และตื่นเต้นอยากลองใช้

1. ราคาถูก – คนใช้ DigitalOcean อย่างผมจะรู้ว่าที่นี่ราคาถูกดี รวมถึงเจ้าระบบ App Platform ด้วย ที่เริ่มต้นเพียง 5$ ต่อเดือน (แต่ใช้ ฟรี ได้นะ ถ้าเป็น static files)
2. รองรับหลายภาษาเขียนโปรแกรมและเฟรมเวิร์ก – เช่น Node.js, Python, Django, Go, PHP, Laravel, React, Ruby, Ruby on Rails, Gatsby, Hugo แต่ถ้าอยากใช้นอกเหนือกว่านี้ เช่น .NET Core ก็ทำเป็น Docker Container ไปใช้ได้ รวมถึงทำไต์ง่ายๆ เป็น static sites หรือ CDN ก็ได้
3. Scale ได้ง่าย – เพราะทำงานอยู่บน Kubernetes clusters จึงทำให้ รองรับการ Scale-out หรือ Scale-up ได้ เพียงแค่กดเปลี่ยนแพ็คเกจของ App หรือกดเพิ่มลดจำนวน App ในหน้า Dashboard ได้เลย
4. Zero Downtime – ในขณะที่เรา Scale-out หรือ Scale-up ตัว Server เราอยู่ จะไม่กระทบกับเว็บไซต์เรา ผู้เข้าเว็บไซต์ยังทำงานได้ปกติ
5. Automated Deployment – มันจะเชื่อมต่อกับ Github ของเรา (อนาคตจะต่อกับ Bitbucket,GitLab ได้) และเมื่อมีการ Push Code ขึ้นไป ก็จะทำการ Deploy ทันทีที่ App Platform ทำให้เราเห็นการเปลี่ยนแปลงได้ทันทีบนหน้าเว็บไซต์เรา

ตั้งแต่ข้อ 3-5 ถ้าเราจะวางระบบ Infrastructure ให้ได้แบบนี้ คงไม่ใช่เรื่องง่ายๆเลย (อย่างน้อยก็สำหรับผมคนหนึ่งแล้วหละ)

ปล. จะเรียกว่าข้อเสียไหมไม่รู้นะครับ แต่ตอนนี้ยังไม่มีบริการทางฝั่ง Asia ให้เลือก ดังนั้นอาจมีผลกับความเร็วเล็กน้อย, รวมถึงยังไม่มีฟีเจอร์ให้ใช้งานอะไรมาก จนถึงขั้นกำหนด Pipeline หรือลงรายละเอียด จนถึงขั้นเป็น CI/CD แบบใน Jenkins ได้

แนะนำให้ศึกษาเรื่องเหล่านี้ก่อน

บริการนี้เรียกได้ว่าเป็น Automated Deployment ดังนั้น หากจะนำไปใช้งานจริง ควรจะเข้าใจที่มาที่ไปไว้บ้าง ว่า Best Practice ที่ควรทำเป็นอย่างไร เพราะหากอ่านแล้วและนำไปใช้จริง อาจจะเกิดความเสียหายได้ ดังนั้น ผมแนะนำให้ไปอ่านเรื่องราวนี้ก่อนครับ

• สรุปแนวคิด The Twelve Factors ในภาพเดียวจบ
• เริ่มต้นทำ CI/CD – Automation Deployment ด้วย Git และ Jenkins (3 – จบ)
• ต้องคิดอย่างไร รู้อะไร และทำอย่างไร เพื่อให้เกิด Automated Test
• จะทำระบบให้รองรับ Automated Test ได้อย่างไร (Testable)
• มาทำความรู้จักกับ Serverless และ AWS Lambda ฉบับคนคิดจะใช้ (ไม่เกี่ยวแต่อยากนำเสนอ แหะๆ)

ทดสอบ DigitalOcean App Platform กันหน่อย

ไปสร้าง Repository บน GitHub ไว้ และนำไฟล์โค้ดของเว็บไซต์เรา push ขึ้นไปรอไว้ก่อน ในที่นี้ผมใส่ index.html ไว้

เข้า DigitalOcean และไปที่เมนู App จากนั้นกด Launch Your App (ใครยังไม่ได้สมัคร ก็ไปสมัครสมาชิก DigitalOcean กันก่อนนะ)

สำหรับครั้งแรก จะเจอให้ Link Account กับ GitHub ก่อนนะครับ

เมื่อ Link Account GitHub เสร็จ ก็เลือก Repository ที่เราต้องการใช้สร้าง

จากนั้นเลือก Region ซึ่งปัจจุบันตอนผมทดสอบ ยังมีเพียงฝั่งทวีป America และ Europe เท่านั้น, จากนั้นเราเลือก Git Branch ที่ต้องการเชื่อมโยงการ Deploy และเลือกว่าจะให้ Deploy อัตโนมัติทันทีเมื่อมีการ Push Code เข้าสู่ Branch นั้น

มาถึงส่วนสำคัญ คือการ Config App ของเรา ว่าจะตั้งค่าอย่างไรบ้าง ดังนี้

• Type – คือประเภทของ APP ซึ่งในที่นี้ระบบมองว่าโค้ดผมเป็น HTML มันเลยเลือกให้เป็น Static Site ให้
• HTTP Routes – กำหนด Path ในการเข้าถึง เช่น / จะวิ่งเข้ามาที่ App นี้ หรือจะตั้งว่า /aabbcc ก็ได้ ดังนั้นใครเข้า www.web.com/aabbcc ก็จะเข้ามาที่ App นี้
• Environment Variables – ตัวแปรที่เก็บไว้ใช้ในระบบ เช่น เก็บ User/Password Database ไว้ที่นี่เป็นต้น
• Build Command – เป็น Shell Script จะใส่อะไรก็ได้ หรือเว้นไว้ก้ได้
• Output Directory – ที่เก็บผลลัพธ์หลังจาก build แล้ว

ส่วนปุ่มด้านล่าง Add a Database คือการให้ App นี้อนญาตให้เชื่อมต่อกับ Database อะไรได้บ้าง หรือจะสร้างใหม่เลยก็ได้นะ

ขั้นตอนสุดท้ายคือการเลือกแพ็คเกจใช้งาน ซึ่งในที่นี้เป็น Static Site เลยทำให้ใช้งานได้ฟรีครับ แต่ถ้าเราใช้กับพวก Dynamic Script อย่าง Node.js, PHP, Docker ก็จะต้องใช้เป็น Basic หรือ Pro เท่านั้น แต่ก็ถือว่าเป็นการเริ่มต้นใช้งานที่ถูกมากๆ แค่ 5$ เท่านั้น (แต่แพ็คเกจ Basic ทาง DigitalOcean แนะนำให้ใช้เป็นระบบสำหรับทดสอบ หรือ Prototype จะดีกว่านะ)

หลังจากกด Launch Starter App แล้ว รอสักครู่ มันจะสร้าง Instant และเมื่อเสร็จแล้ว ก็จะเห็น URL สำหรับการใช้งาน

เมื่อทดลองเข้าไปดูตาม URL ก็จะเห็นหน้าที่ผมไว้สร้างไว้บน GitHub แล้ววว

แต่หน้าตามันดูห่วยๆ เนอะ คราวนี้ผมจะสร้าง css file เพิ่ม

และทำการ push code ขึ้นสู่ GitHub

มีไฟล์ css เพิ่มมาใน GibHub แล้ว

พอผมกลับไปดูหน้าเว็บไซต์ ว้าวว มันเป็นระเบียบสวยงามขึ้นแล้ววว

ไปดูรายการ Deployments มีการเก็บบันทึกไว้ว่ามีการ Deploy อะไรไปบ้าง

สรุป

อย่างที่ผมเกริ่นไปตอนแรก การจะวางระบบ Infrastructure ให้ได้แบบนี้ หรือเริ่มใช้ Kubernetes คงไม่ใช่เรื่องง่ายๆเลยสำหรับผู้ใช้งานทั่วไป หรือโปรแกรมเมอร์หลายๆคน รวมถึงผมด้วย ต่อให้สร้างขึ้นมาได้ แต่การดูแลรักษาเป็นเรื่องที่ปวดหัวมาก เช่น ถ้ามีผู้ใช้เข้ามาสูงมากๆ หรือถ้าโดน DDoS โจมตี เป็นต้น

ดังนั้นการมีบริการ PaaS ลักษณะนี้ขึ้นมา ก็ช่วยทำให้เราสะดวกมากขึ้น และทำให้โปรแกรมเมอร์อย่างเรา สามารถเป็น DevOps ได้เองอย่างไม่ยากเย็นนัก

วิธีติดตั้ง

การใช้งานมี 2 แบบครับ คือใช้คำสั่ง coverlet ทำงานเลย ให้ติดตั้งด้วยคำสั่ง

dotnet tool install --global coverlet.console

หรือทำงานผ่านคำสั่ง dotnet test ให้เพิ่ม nuget package ด้วยคำสั่ง

dotnet add package coverlet.msbuild

วิธีใช้งาน

ในตัวอย่างนี้ โครงสร้างโปรเจ็คผมจะหน้าตาตามรูปภาพด้านล่าง และผมเข้าจะยกตัวอย่างคำสั่งทั้งหมดกรณีที่อยู่ในโฟลเดอร์ /tests/web.UnitTest/

ดังนั้น เมื่อต้องการดู Code Coverage ผ่านคำสั่ง coverlet

coverlet bin/Debug/netcoreapp2.1/api.dll --target "dotnet" --targetargs "test web.UnitTest.csproj --no-build" --output "../web.UnitTest.Results/Coverage.xml" --format opencover

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

• bin/Debug/netcoreapp2.1/api.dll : คือ ที่อยู่ของไฟล์ Unit Test Binary ที่เรา Build มาแล้ว
• test web.UnitTest.csproj –no-build : คือ arguments เพื่อบอกว่าเราต้องการทดสอบด้วย MSTest ไปที่ File Project ไหน, และผมเพิ่มไปว่า ไม่ต้อง ทำการ build project ใหม่ เพราะผมสั่ง build ไปแล้ว (ถ้าใครไม่สั่ง build ก่อน ให้เอา –no-build ออกด้วยนะ)
• ../web.UnitTest.Results/Coverage.xml : คือ ที่อยู่ของไฟล์ report ซึ่งผมให้ใช้เป็น Formet ของ OpenCover จึงจ้องมีนามสกุล .xml (ค่ามาตรฐาน ถ้าไม่ระบุ มันจะเป็น JSON)
• opencover : คือ Format ของไฟล์ report ที่เราจะนำไปใช้งานต่อ

ลองมาดูการใช้งานผ่านคำสั่ง dotnet test แบบปกติบ้าง

dotnet test --no-restore --no-build --logger:"trx;LogFileName=Results.trx" --results-directory:"../web.UnitTest.Results" /p:CollectCoverage=true /p:CoverletOutput="../web.UnitTest.Results/Coverage.xml" /p:CoverletOutputFormat=opencover

ถ้าให้เดาค่าต่างๆ คงพอเดากันได้นะครับ ระบุเหมือนด้านบนเลย แต่คำสั่งหนึ่งที่ต้องมีเสมอคือ

/p:CollectCoverage=true 

เพื่อบ่งบอกว่า เราต้องการ Generate Code Coverage ออกมาด้วย

การแสดงผล

เมื่อรันคำสั่งตามด้านบนเรียบร้อยแล้ว จะได้หน้าตาประมาณนี้ครับ

ความหมายที่ได้จากการแสดงผล คือ

• Module : ชื่อ System ที่มันทำการทดสอบ
• Method coverage : จำนวนของ Function/Method ที่ถูกเรียกใช้งาน
• Branch coverage : จำนวนของ Branch หรือเงื่อนไขใน if statement ถูกเรียกใช้งานทั้ง true และ false
• Line coverage : จำนวนของบรรทัดที่ถูกเรียกใช้งาน

อ้างอิงคำอธิบายจาก http://www.somkiat.cc/introduction-to-code-coverage/

กำหนดคุณภาพ ด้วยการตั้ง Threshold

คราวนี้ ถ้าเราอยากตั้งค่าว่า ถ้า Code Coverage เรามี Test ครอบคลุมต่ำกว่า xx% เราจะไม่ให้ผ่านการทดสอบ โดยเพิ่ม Argument ชื่อ threshold ลงไป ดังนี้

ตัวอย่างด้วยคำสั่ง coverlet

coverlet bin/Debug/netcoreapp2.1/api.dll --target "dotnet" --targetargs "test web.UnitTest.csproj --no-build" --output "../web.UnitTest.Results/Coverage.json" --threshold 80

ตัวอย่างด้วยคำสั่ง dotnet test

dotnet test --no-restore --no-build --logger:"trx;LogFileName=Results.trx" --results-directory:"../web.UnitTest.Results" /p:CollectCoverage=true /p:CoverletOutput="../web.UnitTest.Results/Coverage.xml" /p:CoverletOutputFormat=opencover /p:Threshold=80 /

ซึ่งในตัวอย่างผมกำหนดว่า Coverage ทุกประเภทจะต้องเกิน 80% ถึงจะเรียกว่าผ่าน ถ้าต่ำกว่านั้นจะ Fail ทันที ดังรูปด้านล่าง

และเราสามารถกำหนดเฉพาะ Coverage ได้ด้วย เช่นผมต้องการเช็คเฉพาะ Line Coverage ก็สามารถเพิ่ม Argument เข้าไป ดังนี้

ตัวอย่างด้วยคำสั่ง coverlet

--threshold-type line

ตัวอย่างด้วยคำสั่ง dotnet test

 /p:ThresholdType=line

ผลที่ได้คือ

สรุป

ถ้าเทียบกับ minicover แล้ว ตัวนี้ค่อนข้างใช้งานง่าย ไม่ซับซ้อนมากนัก รองรับ .Net Core 2.2.1 ตัวล่าสุดด้วย และสามารถแจกแจงรายละเอียด ตาม Coverage Type ต่างๆ พร้อมออก Report ได้ เช่น json, lcov, opencover (xml file), cobertura (xml file) และ teamcity ถ้าสนในรายละเอียดมากกว่านี้ ไปดูได้ที่ Github ของผู้พัฒนาได้เลยครับ ที่ https://github.com/tonerdo/coverlet

Featured image from: https://www.aapnainfotech.com/test-coverage-much-testing-enough/

จัดการสิทธิเพื่อใช้ Deployment

ขั้นตอนนี้จะให้นำ SSH Key ของ Jenkins ไปทำความรู้จักกับ Bitbucket
ก่อนอื่น ทำการตรวจสอบก่อนเลยว่า user jenkins ใน server เรา เชื่อมต่อ bitbucke.org ได้ไหม ด้วยคำสั่ง

[wc_code]$ sudo -u jenkins ssh -vT git@bitbucket.com[/wc_code]

ให้ดูบรรทัดท้ายๆ ถ้ามันมี username ที่เราใช้บน Bitbucket แปลว่ามันรู้จักกันแล้ว

แต่ถ้าขึ้นว่า Permission Denied  ให้ทำการ copy public key ไปไว้บน bitbucket ครับ โดยวิธีการดู Jenkins public key คือ

[wc_code]$ sudo vi /var/lib/jenkins/.ssh/id_rsa.pub[/wc_code]

เป็นอันเสร็จเรียบร้อย

สร้างโฟลเดอร์เว็บไซต์ และไฟล์คำสั่ง Deployment

ไฟล์เว็บไซต์ผมจะเก็บไว้ที่ /var/www/test_ci_cd และเมื่อมีโฟลเดอร์แล้ว ให้ clone project ลงมาทั้งหมด

[wc_code]$ sudo mkdir /var/www/test_ci_cd[/wc_code]

[wc_code]$ sudo git clone git@bitbucket.org:few/test-project.git .[/wc_code]

ทำการสร้างไฟล์เพื่อใช้ Deployment ซึ่งในที่นี้ผมใช้ชื่อ deploy.php

[wc_code]$ sudo vi /var/www/test_ci_cd/deploy.php[/wc_code]

ในไฟล์มีโค้ดประมาณนี้

ซึ่งเป็นโค้ดที่ Jenkins จะเอาไว้ใช้งาน โดยมีขั้นตอนคือ

1. เข้าโฟลเดอร์ที่เก็บเว็บไซต์ (หรือเก็บไฟล์ deploy.php)
2. ทำการล้างไฟล์เก่าออกทั้งหมด (optional)
3. ดึงไฟล์ล่าสุดที่มีการเปลียนแปลงและผ่านการทำสอบแล้ว ลงมาบน server

จากนั้นทำการบันทึก ก็เสร็จแล้ว

เพิ่ม Config Deployment บน Jenkins

เข้าไปที่ Project ที่เราใช้ทำงาน จากนั้นเพิ่มในส่วนของ Build จุดเดียวกับที่ตั้งให้ทำ PHPUnit ดังนี้

ซึ่ง folder path และชื่อไฟล์ ให้เปลี่ยนไปตามที่เราตั้งค่าไว้ด้วยนะ

ลองทดสอบ Automation Deployment

ตอนนี้ไฟล์ที่ผมใช้ทดสอบทำงานบวกเลขได้ตามปกติ และไฟล์ test unit ผมก็ยังใช้งานได้ตามปกติ
ผมจะลองเพิ่มข้อความบนไฟล์ calculate.php โดยยังไม่ได้แก้ไขอะไร เพื่อดูว่าระบบไหลไปได้ถูกต้องหรือไม่

[wc_code]echo ‘Hi, automate test and deploy (success, all test case)’;[/wc_code]

จากนั้นให้ Push เข้าสู่ระบบ

ลองเปิดดูบน Jenkins จะต้องพบว่ามัน Success

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

แปลว่า ระบบ Jenkins ทำการทำการ Automate Test และเมื่อทดสอบ Unit Test ผ่านทั้งหมด ก็ได้ Automate Deploy ให้เราเรียบร้อยแล้ววว

คราวนี้ มาลองทดสอบกรณีที่ Unit Test ทำงานไม่ผ่านบ้าง
โดยผมได้แก้สูตรคิดเลข จาก บวก เป็น หาร ดังนั้น Unit Test ที่ผมทำการทดสอบไว้ทั้งหมดจะผิดทันที เพราะคำตอบมันเป็นผลลัพธ์ของการบวกเท่านั้น
และผมได้ทำการแก้ไขข้อความด้วยว่า จะเกิดการ fail, all test case

เช่นเดิม แก้ไขเสร็จ ทำการ git push ขึ้นไปบน Bitbucket

จากนั้นเมื่อไปดูบน Jenkins มันจะแสดงข้อความ FAILURES ขึ้นมา เพราะ Unit Test เราไม่ผ่าน

ดังนั้น ไฟล์บน Procution ก็จะไม่มีอะไรเปลี่ยนแปลง เพราะเมื่อ Unit Test ไม่ผ่าน มันจะไม่ไปเรียกไฟล์ deployment ทำต่อ

สรุป

จากที่ได้ลองผิดลองถูกทำมาจนครบ ทำให้เห็นภาพได้ชัดเจนเลยครับว่า Continuous Integration และ Continuous Deployment มันสะดวกและเร็วขึ้นมาก ช่วยส่งเสริมกับเรื่องการส่งมอบงานเป็นรอบและส่งให้ได้ไว เพื่อให้มีการ feedback เร็ว ดังนั้น การเสียเวลาศึกษาและตั้งระบบขึ้นมาอีกสักหน่อย มันจะช่วยงานเราได้ในระยะยาว

แต่อย่างที่ชื่อเรื่องบอกนะครับ นี่เป็นเพียงการเริ่มต้น ดังนั้นขั้นตอนที่เราจะใช้งานจริงๆ อาจจะมีมากกว่านี้ที่ต้องเพิ่มขึ้น ทั้งการเพิ่ม Security, การเพิ่มเรื่องของ Test, การ git push ไปพักไว้ที่ dev branch ก่อน, การ Deploy ไปยัง Stating Server เพื่อทำ Acceptant Test แล้วค่อย merge git เข้าสู่ master branch และ deploy Production … ผมก็คงเขียนไม่หมด เอาเป็นว่า ไปเผชิญโลกกว้างกันดูครับ

(รูปจาก http://www.bogotobogo.com/DevOps/DevOps_CI_CD_Pipeline_Sample.php)

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

เว็บอ้างอิง

• Automatically Deploy Private Git Repo to Server
• รูปปกจาก http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

ซี่รี่ “เริ่มต้นทำ CI/CD”

• เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)
• เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)
• เริ่มต้นทำ CI/CD – Automation Deploy ด้วย Git (Bitbucket) และ Jenkins (3 – จบ)

และคุณประโยชน์ที่เราจะไปใช้ Scrum เพื่อทำ Agile คือ การส่งมอบงาน หรือ Software ที่ใช้ได้ ให้ได้ไวๆ
ดังนั้น การส่งมอบให้ได้ไว คือการทำงานเป็นรอบ และการทำงานเป็นรอบ เราจะได้ผลตอบรับไว (fast feedback) ว่าใช่หรือไม่ใช่ ผิดหรือถูก

เช่นกัน Software ที่ใช้ได้และส่งมอบงานได้ไว ก็ต้องมี Automate Test ที่ทำงานได้แทนเรา และครอบคลุม หนึ่งในนั้นคือ Unit Test

ว่าแล้วก็ลองมาดูกัน

ติดตั้ง PHPUnit บน Ubuntu

ใช้คำสั่งเดียว ดังนี้

[wc_code]$ sudo apt-get install phpunit[/wc_code]

ทดสอบด้วยคำสั่ง

[wc_code]$ phpunit –version[/wc_code]

จะแสดงข้อความ ประมาณ [wc_code]PHPUnit 3.7.21 by Sebastian Bergmann.[/wc_code] ก็พร้อมใช้แล้วครับ

ติดตั้ง PHPUnit บน Windows

ซับซ้อนนิด ลองทำตามดู

1. .ไป Download PHPUnit ที่ https://phpunit.de/
2. จะได้ไฟล์ชื่อประมาณว่า phpunit-6.2.1.phar ให้เอามันไปไว้ที่ไหนโฟลเดอร์ไหนสักแห่ง ในที่นี้ผมไว้ที่ C:\bin
3. จากนั้นเข้าไปที่ windows command ด้วยการกด ปุ่มรูป windows ที่ keyboard + R
4. พิมพ์คำสั่ง
   [wc_code]cd C:\bin
   echo @php “%~dp0phpunit-6.2.1.phar” %* > phpunit.cmd[/wc_code]
5. ถ้าสังเกตในโฟลเดอร์ของเรา จะพบไฟล์ชื่อ phpunit.cmd ขึ้นมาไฟล์หนึ่ง
   
6. จากนั้นไปตั้งค่า Environment Variables และใส่ Path เป็นที่อยู่โฟลเดอร์ที่เราเก็บไฟล์ไว้ นั่นก็คือ C:\bin
   
7. คราวนี้เราจะสามารถใช้งาน phpunit ที่โฟลเดอร์อื่นๆ นอกเหนือจาก C:\bin ได้แล้ว
   

เริ่มต้นลองเขียน PHPUnit แบบง่ายๆ

สมมติว่าผมสร้างไฟล์ชื่อ Calculate.php ในนั้นมี Class ชื่อ Calculate และมี Function บวกเลขขึ้นมาตัวหนึ่ง

ผมต้องสร้างไฟล์ทดสอบขึ้นมาประกบ Function นี้ โดยผมตั้งชื่อว่า test_calculate.php และมีโค้ด ดังนี้

ไฟล์ นี้ผมจะ include ไฟล์ที่จะทำการทดสอบมาด้วย นั่นคือ Calculate.php
จากนั้นผมจะ extends เรียกใช้ตัว PHPUnit_Framework_TestCase เพื่อเรียกใช้งานคำสั่งต่างๆของ PHPUnit

class Test_calculate extends PHPUnit_Framework_TestCase

เรียกใช้ function setup() ซึ่งมันจะทำคำสั่งทั้งหมดในนี้ทุกครั้งที่มีการทดสอบ function อื่นๆ เสมอ

public function setup() {
$this->calculate = new Calculate();
}

สร้าง function ทดสอบการบวกเลขขึ้นมา โดยการตั้งชื่อของ PHPUnit จะต้องขึ้นต้นด้วย test เสมอ
และผทใช้คำสั่ง assertEquals() เพื่อตรวจสอบว่า ผลลัพธ์ที่ได้จาก $this->calculate->add($a, $b) เท่ากับ $expected หรือไม่
โดยตัวแปล $a, $b, $expected ผมให้เรียกใช้มาจากชุดตัวเลขทดสอบ ที่เก็บไว้ใน function additionProvider()
โดยวิธีการเรียกใช้นั้น คือคำสั่ง @dataProvider ที่อยู่ในกรอบคอมเม้น
/**
* @dataProvider additionProvider
*/
public function testAdd($a, $b, $expected) {
$this->assertEquals($expected, $this->calculate->add($a, $b));
}

public function additionProvider()
{
return [
‘0+0=0’ => [0, 0, 0],
‘0+1=1’ => [0, 1, 1],
‘1+0=0’ => [1, 0, 0],
‘1+4=3’ => [1, 4, 3]
];
}

จากนั้นทำการรันคำสั่ง

[wc_code]$ phpunit test_calculate.php[/wc_code]

ผลที่ได้จะเป็นดังรูปนี้

ความหมายคือ ผลการทดสอบ ไม่ผ่าน
โดยทดสอบด้วย 4 ชุดข้อมูล ไม่ผ่าน 2 ชุดข้อมูล

ให้ Jenkins ทดสอบ PHPUnit อัตโนมัติ ทุกครั้งที่มีการ Push สู่ Git

กลับไปที่ Jenkins Project ที่สร้างไว้จากบล็อก สอนติดตั้ง Jenkins
ในส่วนของ Build ให้กดปุ่ม Add build step เพื่อเพิ่มการทำงานในตอน build
จากนั้นเลือกเมนู Excute shell และใส่โค้ดไปว่า

[wc_code]phpunit –log-junit test/results/phpunit.xml test/test_calculate.php[/wc_code]

ส่วนของ test/results/phpunit.xml จะเป็น path ที่เก็บไฟล์ report, ส่วน test/test_calculate.php คือไฟล์ที่ใช้ทดสอบ
ดังนั้นใครไฟล์ทดสอบไว้อย่างไร ก็แก้กันตามนั้นส่วนไฟล์ report ก็แล้วแต่จะตั้งนะ

ต่อมา ในส่วนของ Post-build Actions ให้กดปุ่ม Add post-build action เพื่อเพิ่มการทำงานหลัง build เสร็จ
จากนั้นเลือกเมนู Publish JUnit test result report และใส่ที่อยู่ของ report เมื่อสักครู่เข้าไป

[wc_code]test/results/phpunit.xml[/wc_code]

(มันจะแจ้งตัวอักษรแดงๆ ว่าไม่พบไฟล์ก็ปล่อยมันไป)

หลังจากนั้นให้ลองกดปุ่ม Build ดู และให้กดไปที่รายการที่ Build ครั้งล่าสุด

ให้เลือกเมนู Test Result ก็จะพบผลการทดสอบที่แยก Function การทำงานพร้อม Progress Bar บอกผลด้วยว่า ผ่าน/ไม่ผ่าน กี่ Function

ในหน้าของ History ก็จะบอกประวัติของการพบข้อผิดพลาดว่ามากขึ้นหรือลดลง

เมื่อไปดูหน้าของ Project ก็จะมี Trend การพบข้อผิดพลาด

สรุป

หลังจากไดทำ Unit Test และไปให้ Jenkins เป็นตัวรันทดสอบให้อัตโนมัติทุกครั้งที่ Commit Code คราวนี้เราก็สบายใจได้แล้วว่า ทุกครั้งที่ทำงานและนำโค้ดขึ้น Git เราจะมีโค้ดที่สามารถทำงานได้ เราได้เริ่มต้นเข้าสู่ Continuous Integration ด้วย Unit Test แล้ววว

ในบล็อกตอนหน้า ผมจะนำโค้ดที่ใช้งานได้บน Git เข้าสู่ Production Server เพื่อลองทำ Continuous Deployment กันครับ

เว็บอ้างอิง

• สรุปการใช้งาน Jenkins ร่วมกับ PHP project แบบง่ายๆ
• ปรับปรุงคุณภาพของ Software ด้วย Continuous Integration Process กันนะ
• รูปปกจาก https://buddy.works/blog/introducing-phpunit

ซี่รี่ “เริ่มต้นทำ CI/CD”

• เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)
• เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)
• เริ่มต้นทำ CI/CD – Automation Deploy ด้วย Git (Bitbucket) และ Jenkins (3 – จบ)

Jenkins เป็น Automation Tools ที่เอาไว้ทำอะไรต่างๆแบบอัตโนมัติ ซึ่งในที่นี้เราเอามันไปใช้ทำ CI/CD เพื่อช่วยชีวิตนักพัฒนาอย่างเราให้สบายขึ้น อบย่างเช่น นักพัฒนาเพียงแค่เขียนโค้ด นำขึ้น Git แล้วให้ Jenkins ทำการทดสอบจากที่เราตั้งค่าไว้ ไม่ว่าจะ Robot Framework หรือ Test Unit ก็ตาม เมื่อผ่านเรียบร้อย ก็นำกลับไป Merge Code เข้า Git หรือจะ Deploy ต่อไปยัง Server ก็ว่ากันไป (ซึ่งผมจะเขียนบล็อกสอนทำตามนี้แหละ)

เนื่องด้วยผมใช้ Linux Ubuntu นะครับ ใครใช้ Linux/Windows อื่นๆ ก็ลองปรับๆเทียบเคียงดูอีกที

สิ่งที่ต้องมี

Server ที่ใช้ Ubuntu มี Ram ขั้นต่ำ 1GB จากนั้นให้สร้าง user ที่สามารถใช้งาน sudo ได้และใช้ File Key Authentication ในการเข้าสู่ระบบ (วิธีการสร้าง user + file key authentication + disable root user + disable password authentication)

ติดตั้ง Jenkins

เพิ่ม repository key ใน server

[wc_code]$ wget -q -O – https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add -[/wc_code]

พิมพ์ไปแล้วจะแสดงคำว่า [wc_code]OK[/wc_code] เป็นใช้ได้ จากนั้น กำหนด Debian package repo address

[wc_code]$ echo deb http://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list[/wc_code]

ทำการ update package สักหน่อย

[wc_code]$ sudo apt-get update[/wc_code]

สุดท้ายก็พิมพ์คำสั่งติดตั้ง Jenkins

[wc_code]$ sudo apt-get install jenkins[/wc_code]

จากนั้นให้ทำการ เปิดใช้ Jenkins

[wc_code]$ sudo service jenkins start[/wc_code]

แล้วลองเช็คดูว่า Jenkins ทำงานจริงหรือไม่

[wc_code]$ sudo service jenkins status[/wc_code]

ถ้า Jenkins ทำงานอยู่ ผลลัพธ์ที่ได้จะแสดงประมาณนี้

[wc_code]Jenkins Automation Server is running with the pid 12445[/wc_code] (เลขข้างหลังอะไรก็ว่าไป อาจไม่เหมือนกัน)

เปลี่ยนเลข Port Jenkins สักหน่อย

(ถ้าใครไม่ทำตรงนี้ ก็ข้ามไปได้ครับ ใช้ Port 8080 ดังเดิม)

ปกติ Jenkins จะใช้ Port 8080 ซึ่งผมคิดว่าเกร่อไปนิด เลยอยากเปลี่ยนเป็นเลขอื่นๆแทน โดยทำดังนี้

แก้ไข file ชื่อ /etc/default/jenkins

[wc_code]$ sudo vi /etc/default/jenkins[/wc_code]

แก้เลข port บนหาบรรทัดที่เขียนว่า HTTP_PORT

[wc_code]HTTP_PORT=8083[/wc_code]

จากนั้น save แล้วออกมา restart Jenkins อีกรอบ

[wc_code]$ sudo service jenkins restart[/wc_code]

ตั้งค่าใช้งาน Jenkins

เมื่อติดตั้งและเปลี่ยน port เรียบร้อย คราวนี้มาตั้งค่ากัน โดยเข้าไปที่ URL เว็บของเราหรือ IP แล้วตามด้วยเลข Port ที่เรากำหนดเมื่อสักครู่

[wc_code]http://ip_address_or_domain_name:8083[/wc_code]

การเข้าใช้งานครั้งแรก จะขึ้นหน้าตาแบบนี้ครับ

ซึ่งมันให้เราเอารหัสเปิดใช้งานครั้งแรกมากรอก โดยพิมพ์คำสั่งดูข้อมูลจาก /var/lib/jenkins/secrets/initialAdminPassword

[wc_code]$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword[/wc_code]

เราจะได้ตัวอักษรผสมตัวเลข 32 หลัก ซึ่งอันนี้แหละ เป็นรหัสที่ใช้กรอก

เมื่อกดไปขั้นต่อไป ให้เลือก Install suggested plugins เป็นค่าเริ่มต้นไปก่อน

แล้วมันจะทำการติดตั้งอะไรก็ว่าไป จนไปถึงหน้ากรอกข้อมูล Admin User ก็ตั้งได้จตามสะดวกที่ต้องการ เป็นอันเสร็จพิธี และเมื่อกดปุ่ม Start using Jenkins จะเจอหน้าแรกประมาณนี้ (Test Project กับ Test CI CD (Bitbucket) ไม่ต้องไปสนใจมันนะฮะ พอดีผมลืมแคปเจอร์หน้าตอนที่ยังไม่มี Project ขึ้น แหะๆ)

เว็บอ้างอิง

• Initial Server Setup with Ubuntu 16.04
• How To Install Jenkins on Ubuntu 16.04
• How to start Jenkins on different port rather than 8080 using command prompt in Windows?
• รูปปกจาก http://www.drdobbs.com/testing/soasta-and-cloudbees-team-for-jenkins-pl/240152753

ซี่รี่ “เริ่มต้นทำ CI/CD”

• เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)
• เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)
• เริ่มต้นทำ CI/CD – Automation Deploy ด้วย Git (Bitbucket) และ Jenkins (3 – จบ)