ลองอ่านคอนเซ็ปตอนแรกตื่นเต้นมากครับ นึกว่า 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 ได้เองอย่างไม่ยากเย็นนัก

จัดการสิทธิเพื่อใช้ 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 – จบ)

บทความนี้อ้างอิงวิธีการจาก Digitalocean Tutorials : How To Set Up Automatic Deployment with Git with a VPS

คำเตือน: อย่างที่บอก มันแค่อำนวยความสะดวกด้วย Git ดังนั้นก่อนจะ Deploy ขึ้น Production Server ควรผ่านการ Test ให้เสร็จเสียก่อน

(รูปตัวอย่างของ Git Deployment ของ จาก flyingcorkmedia.com)

เตรียมของ

บน Production Server:

• Directory ที่เราใช้ Live เว็บไซต์ เช่น /var/www/domain.com
• Directory ที่เราใช้เก็บ Git Repo เช่น /var/repo/site.git

บน Localhost:

• ติดตั้ง Git
• ทำการผูก SSH Key ระหว่างเครื่องเรา (Localhost) กับ Production Server (ถ้าไม่ผูกก็ได้ แต่จะต้องมาพิมพ์รหัสตลอดทุกครั้งที่ Commit นะ, ตัดสินใจดูเอาเอง)

เริ่มต้นทำ Git Repo บน Production Server

ถ้ายังไม่ได้สร้าง /var/repo/site.git ให้ใช้คำสั่ง

[wc_code]mkdir /var/repo/site.git[/wc_code]

จากนั้น เข้าไป git init ให้มันด้วยคำสั่ง git init –bare

[wc_code]cd /var/repo/site.git
git init –bare[/wc_code]

อธิบาย: git init –bare จะสร้างและเก็บค่าคอนฟิกของ Version Control เฉยๆ จะไม่มีการเก็บ Source Code

ทำการ Git Hook

ให้เข้าไปที่ไดเร็กทอรี่ repo ที่ได้สร้างไว้เมื่อสักครู่ จากนั้น ปรับ permission ไฟล์ hooks/post-receive เพื่ออนุญาตให้ execute file ได้ และเข้าไปแก้ไขข้อมูลในไฟล์นั้น

[wc_code]cd /var/repo/site.git
chmod +x hooks/post-receive
vi hooks/post-receive[/wc_code]

ในไฟล์นั้นจะไม่มีข้อมูลใดๆ จากนั้นให้เราใส่คำสั่งดังนี้

[wc_code]#!/bin/sh
git –work-tree=/var/www/domain.com –git-dir=/var/repo/site.git checkout -f[/wc_code]

เป็นการบอกว่า เมื่อมีการ git push เข้ามา ให้ส่ง source code ไปยัง /var/www/domain.com

จากนั้นให้เราบันทึกและออกมาจากหน้า editor
เป็นอันเสร็จขั้นตอนที่ต้องทำบน Production Server

ทำ Git Repo บน Localhost

คราวนี้เรามาจัดการบนเครื่อง Localhost เราต่อ โดยให้เราเข้าไปที่ไดเร็กทอรี่ที่เก็บ Source Code ของเรา จากนั้นเข้า Git Bash และทำการพิมพ์ git init

[wc_code]git init[/wc_code]

และพิมพ์คำสั่งทำการสร้าง remote ขึ้นมาชื่อ live

[wc_code]git remote add live ssh://user@mydomain.com/var/repo/site.git[/wc_code]

เป็นอันเสร็จขั้นตอนของ Localhost ครับ

ทดลองใช้งาน

ให้ลองสร้างไฟล์ขึ้นมาสักไฟล์หนึ่ง จากนั้น ทำการ commit git ตามปกติ แต่ ขั้นตอน push ให้ส่งไปที่ remote live แทน เช่น

[wc_code]git add .
git commit -m “Test push file to production server”
git push live master[/wc_code]

ข้อมูลบนเว็บไซต์ของเราบน Production Server จะมีการเปลี่ยนแปลงไปตามที่เราได้แก้ไขไป

เพิ่มขั้นตอนทำเป็น Development Environment ก่อนก็ได้นะ

การเอาขึ้น Production ด้วยคำสั่งเดียวมันดูอันตรายไปหน่อย อาจทำขั้นตอนเดียวกันนี้แต่เป็น Development Environment ก่อนก็ได้ โดยทำเหมือนเดิมทุกอย่างเลยครับ

โดยสมมติว่า

• Directory ที่เราใช้ Live Beta เว็บไซต์ เช่น /var/www/beta
• Directory ที่เราใช้เก็บ Git Repo Beta เช่น /var/repo/beta.git

ให้สร้าง Config Version Control

[wc_code]cd /var/repo/beta.git
git init –bare
chmod +x hooks/post-receive
vi hooks/post-receive[/wc_code]

ใส่ข้อมูลในไฟล์ hooks/post-receive ว่า

[wc_code]#!/bin/sh
git –work-tree=/var/www/beta –git-dir=/var/repo/beta.git checkout -f[/wc_code]

จากนั้นมา add remote beta ใน repo localhost เราไปที่ไดเร็ดทอรี่ beta.git

[wc_code]git remote add beta ssh://user@mydomain.com/var/repo/beta.git[/wc_code]

คราวนี้ เวลาพัฒนาหรือแก้ไขปรับหรุง Source Code เสร็จ ก็ทำการนำเข้า Dvelopment Environment เพื่อทดสอบก่อน

[wc_code]git add .
git commit -m “New version”
git push beta master[/wc_code]

เมื่อทดสอบระบบทั้งหมดใน Development Environment  เสร็จ ก็ทำการนำเข้า Production อีกครั้ง

[wc_code]git push live master[/wc_code]

เป็นอันจบขั้นตอนทั้งหมด

ไว้คราวหน้าลอง CI/CD แล้วจะมาเขียนเหลาไหฟังอีกครั้ง

—

Featured Image from  flyingcorkmedia.com