[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"academy-blogs-th-1-1-all-what-is-ci-cd-github-actions-all--*":3,"academy-blog-faqs-x3e3xuldfzeouel-th":92,"academy-blog-translations-x3e3xuldfzeouel":117},{"data":4,"page":91,"perPage":91,"totalItems":91,"totalPages":91},[5],{"alt":6,"collectionId":7,"collectionName":8,"content":9,"cover_image":10,"cover_image_l_url":11,"cover_image_m_url":12,"cover_image_path":13,"cover_image_s_url":14,"created":15,"created_by":16,"expand":17,"id":84,"keywords":85,"locale":55,"published_at":86,"scheduled_at":71,"school_blog":80,"short_description":87,"status":78,"title":88,"updated":89,"updated_by":90,"slug":81,"views":83},"แบบจำลองสถานีไม้เรียงบนสายพานเล็กที่พาบล็อกไม้เคลื่อนผ่าน ข้างการ์ดสรุปขั้น Build, Test และ Deploy ของ CI\u002FCD Pipeline","sclblg987654321","school_blog_translations","\u003Cp>ลองนึกภาพเย็นวันศุกร์ เพื่อนในทีมแก้บั๊กเล็กๆ เสร็จแล้วรีบ Merge (รวมโค้ด) เข้า main ก่อนกลับบ้าน ไม่มีใครรันเทสต์ เพราะทุกคนคิดว่า \"แก้นิดเดียวเอง\" สองชั่วโมงต่อมา หน้าเว็บจริงขึ้น Error ทั้งหน้า และคนที่ต้องเปิดโน้ตบุ๊กกลับมาแก้ตอนสามทุ่มคือคุณ\u003C\u002Fp>\u003Cp>สั้นๆ: CI\u002FCD คือการให้เครื่องรัน Build และ Test ให้อัตโนมัติทุกครั้งที่มีคนส่งโค้ดเข้ามา แล้วส่งโค้ดที่ผ่านการตรวจไปถึงมือผู้ใช้ด้วยขั้นตอนเดิมทุกครั้ง แทนที่จะพึ่งความจำว่าใครรันเทสต์หรือยัง\u003C\u002Fp>\u003Cp>วันนี้ Superdev Academy จะพาไปดูว่า CI กับ CD ต่างกันตรงไหน ทำไม CD ถึงมีสองความหมาย Pipeline มีขั้นตอนอะไรบ้าง แล้วปิดท้ายด้วยการเขียนไฟล์ GitHub Actions ไฟล์แรกที่รัน \u003Ccode>npm test\u003C\u002Fcode> ให้เองทุกครั้งที่ Push\u003C\u002Fp>\u003Ch2>CI\u002FCD ย่อมาจากอะไร\u003C\u002Fh2>\u003Cp>CI ย่อมาจาก \u003Cstrong>Continuous Integration\u003C\u002Fstrong> ส่วน CD ย่อมาจากได้สองคำ คือ \u003Cstrong>Continuous Delivery\u003C\u002Fstrong> หรือ \u003Cstrong>Continuous Deployment\u003C\u002Fstrong> ซึ่งไม่ใช่เรื่องเดียวกัน และเป็นจุดที่คนสับสนบ่อยที่สุดของหัวข้อนี้\u003C\u002Fp>\u003Cp>คำว่า Continuous แปลว่าต่อเนื่อง หัวใจของมันคือทำบ่อยๆ ทีละน้อย แทนที่จะรวมโค้ดหรือปล่อยงานครั้งใหญ่เดือนละครั้งแล้วลุ้นว่าจะพังหรือไม่\u003C\u002Fp>\u003Ch2>CI คืออะไร\u003C\u002Fh2>\u003Cp>GitHub Docs ให้นิยามไว้ว่า Continuous Integration คือแนวปฏิบัติที่นักพัฒนา Commit โค้ดเข้า Repository กลางบ่อยๆ และทุกครั้งที่ Commit ระบบจะ Build และ Test ให้ต่อเนื่อง เพื่อเช็กว่า Commit นั้นไม่ได้พาข้อผิดพลาดใหม่เข้ามา (อ่านต้นฉบับได้ที่ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdocs.github.com\u002Fen\u002Factions\u002Fget-started\u002Fcontinuous-integration\">GitHub Docs: Continuous integration\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>สิ่งที่ CI ตรวจไม่จำเป็นต้องเป็น Unit Test อย่างเดียว GitHub Docs ยกตัวอย่างไว้ทั้ง Linter ที่ตรวจรูปแบบการเขียน การตรวจความปลอดภัย Code Coverage และ Functional Test พูดง่ายๆ คืออะไรที่คุณเคยต้องจำว่า \"ก่อน Merge ต้องรันนะ\" ย้ายไปให้เครื่องรันแทนได้หมด\u003C\u002Fp>\u003Cp>ถ้ายังไม่เคยเขียนเทสต์เลย เริ่มจากบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fhow-to-write-unit-tests-and-integration-tests-effectively\">การเขียน Unit Test และ Integration Test อย่างไรให้ได้ผล\u003C\u002Fa> ก่อนได้ เพราะ CI ที่ไม่มีเทสต์ให้รัน ก็แค่ Build ผ่านแล้วบอกว่าเขียว\u003C\u002Fp>\u003Ch2>CD คืออะไร: Continuous Delivery กับ Continuous Deployment ต่างกันอย่างไร\u003C\u002Fh2>\u003Cp>สองคำนี้ต่างกันแค่ขั้นสุดท้าย คือใครเป็นคนกดปล่อยขึ้น Production (ระบบจริงที่ผู้ใช้ใช้งาน)\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Continuous Delivery:\u003C\u002Fstrong> โค้ดทุกชิ้นที่ผ่าน Pipeline อยู่ในสภาพพร้อมปล่อยได้ตลอดเวลา แต่จะปล่อยเมื่อไหร่ ยังให้คนตัดสินใจกด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Continuous Deployment:\u003C\u002Fstrong> ทุกการเปลี่ยนแปลงที่ผ่าน Pipeline ถูกปล่อยขึ้น Production ให้เองอัตโนมัติ ไม่มีคนกดคั่นกลาง\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Martin Fowler อธิบายไว้ในบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FContinuousDelivery.html\">ContinuousDelivery\u003C\u002Fa> ว่า Continuous Delivery หมายถึงทีม \u003Cem>สามารถ\u003C\u002Fem> Deploy ได้บ่อย แต่อาจเลือกไม่ทำ ส่วน Continuous Deployment คือทุกการเปลี่ยนแปลงวิ่งผ่าน Pipeline แล้วขึ้น Production เอง และเขาย้ำว่าการจะทำ Continuous Deployment ได้ ต้องทำ Continuous Delivery ได้ก่อน\u003C\u002Fp>\u003Cblockquote>\u003Cp>ถ้าเจอคำว่า CD ในเอกสารไหน ให้ดูว่าเขาหมายถึงแบบไหน หน้า Continuous deployment ของ GitHub Docs ใช้ CD ในความหมายของ Continuous Deployment โดยตรง\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>สำหรับทีมเล็กหรือโปรเจกต์แรก Continuous Delivery มักเป็นจุดเริ่มที่ปลอดภัยกว่า เพราะยังมีคนดูก่อนปล่อยของจริง\u003C\u002Fp>\u003Ch2>CI\u002FCD Pipeline คืออะไร มีขั้นตอนอะไรบ้าง\u003C\u002Fh2>\u003Cp>Pipeline คือลำดับขั้นตอนที่โค้ดต้องเดินผ่านตั้งแต่ถูก Push จนไปถึงผู้ใช้ ถ้าขั้นไหนล้ม ขั้นถัดไปจะไม่ถูกรัน โค้ดที่มีปัญหาจึงไปไม่ถึงปลายทาง Pipeline ของแต่ละทีมหน้าตาต่างกันได้มาก แต่ส่วนใหญ่มีสามขั้นหลักนี้\u003C\u002Fp>\u003Ch3>1. Build: ประกอบโค้ดให้พร้อมรัน\u003C\u002Fh3>\u003Cp>ติดตั้ง Dependency, Compile หรือ Bundle โค้ดให้ออกมาเป็นของที่รันได้ ถ้า Build ไม่ผ่าน แปลว่าโค้ดยังไม่ครบ ไม่ต้องไปต่อ\u003C\u002Fp>\u003Ch3>2. Test: เช็กว่าโค้ดยังทำงานถูก\u003C\u002Fh3>\u003Cp>รัน Unit Test, Lint หรือการตรวจอื่นๆ ที่ทีมตกลงกันไว้ ขั้นนี้คือหัวใจของ CI และเป็นขั้นที่ช่วยเคสเย็นวันศุกร์ข้างบนได้โดยตรง\u003C\u002Fp>\u003Ch3>3. Deploy: ส่งโค้ดขึ้นระบบปลายทาง\u003C\u002Fh3>\u003Cp>ส่งของที่ผ่านสองขั้นแรกไปยัง Staging หรือ Production จะให้คนกดอนุมัติก่อน (Delivery) หรือปล่อยเองเลย (Deployment) ก็เลือกตรงนี้\u003C\u002Fp>\u003Ch2>GitHub Actions คืออะไร\u003C\u002Fh2>\u003Cp>GitHub Actions คือระบบ CI\u002FCD ที่อยู่ในตัว GitHub เอง คุณเขียนขั้นตอนเป็นไฟล์ YAML วางไว้ใน Repository แล้ว GitHub จะเอาไปรันบนเครื่องที่เรียกว่า Runner ทุกครั้งที่เกิดเหตุการณ์ที่กำหนด เช่น Push หรือเปิด Pull Request (ถ้ายังไม่คุ้นกับตัว GitHub อ่าน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fwhat-is-github-explained\">GitHub คืออะไร\u003C\u002Fa> ก่อนได้)\u003C\u002Fp>\u003Cp>ศัพท์ที่ต้องรู้มีแค่สี่คำ ตาม \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdocs.github.com\u002Fen\u002Factions\u002Freference\u002Fworkflows-and-actions\u002Fworkflow-syntax\">GitHub Docs: Workflow syntax\u003C\u002Fa>\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Workflow:\u003C\u002Fstrong> ไฟล์ \u003Ccode>.yml\u003C\u002Fcode> หรือ \u003Ccode>.yaml\u003C\u002Fcode> หนึ่งไฟล์ ต้องเก็บไว้ในโฟลเดอร์ \u003Ccode>.github\u002Fworkflows\u003C\u002Fcode>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>on:\u003C\u002Fstrong> เหตุการณ์ที่สั่งให้ Workflow เริ่มรัน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Job:\u003C\u002Fstrong> กลุ่มงานที่รันบน Runner หนึ่งเครื่อง ถ้ามีหลาย Job จะรันพร้อมกันเป็นค่าเริ่มต้น\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Step:\u003C\u002Fstrong> คำสั่งทีละขั้นใน Job จะเรียก Action สำเร็จรูปด้วย \u003Ccode>uses\u003C\u002Fcode> หรือรันคำสั่ง Shell ด้วย \u003Ccode>run\u003C\u002Fcode> ก็ได้\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>เรื่องค่าใช้จ่าย \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdocs.github.com\u002Fen\u002Fbilling\u002Fconcepts\u002Fproduct-billing\u002Fgithub-actions\">หน้า Billing ของ GitHub Docs\u003C\u002Fa> ระบุว่าใช้ฟรีสำหรับ Public Repository ที่รันบน Standard GitHub-hosted Runner ส่วน Private Repository บนแพ็กเกจ GitHub Free ได้โควตา 2,000 นาทีต่อเดือน (ตรวจเมื่อ 1 ตุลาคม 2026 ตัวเลขนี้เปลี่ยนได้ เช็กหน้าเดิมอีกครั้งก่อนวางแผนจริง)\u003C\u002Fp>\u003Ch2>ตัวอย่าง: เขียน Workflow แรกที่รัน npm test\u003C\u002Fh2>\u003Cp>เราจะทำโปรเจกต์ Node.js ที่เล็กที่สุดเท่าที่ทำได้ มีฟังก์ชันเดียว เทสต์เดียว แล้วให้ GitHub Actions รันเทสต์ให้ทุกครั้งที่ Push หรือเปิด Pull Request เข้า main ทุกอย่างข้างล่างนี้ทีมเรารันจริงบนเครื่องด้วย Node.js v26.7.0 และ npm 11.19.0 เมื่อ 1 ตุลาคม 2026\u003C\u002Fp>\u003Ch3>ขั้นที่ 1: เตรียมโค้ดและเทสต์\u003C\u002Fh3>\u003Cp>ไฟล์ \u003Ccode>sum.js\u003C\u002Fcode>\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-javascript\">function sum(a, b) {\n  return a + b;\n}\nmodule.exports = { sum };\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>ไฟล์ \u003Ccode>sum.test.js\u003C\u002Fcode> ใช้ Test Runner ที่มากับ Node.js เอง ไม่ต้องติดตั้งอะไรเพิ่ม\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-javascript\">const test = require('node:test');\nconst assert = require('node:assert');\nconst { sum } = require('.\u002Fsum');\n\ntest('sum adds two numbers', () => {\n  assert.strictEqual(sum(2, 3), 5);\n});\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>ไฟล์ \u003Ccode>package.json\u003C\u002Fcode> กำหนดให้ \u003Ccode>npm test\u003C\u002Fcode> เรียก \u003Ccode>node --test\u003C\u002Fcode> และใช้รายงานผลแบบ TAP ซึ่งเป็นข้อความธรรมดาอ่านง่ายใน Log\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-json\">{\n  \"name\": \"ci-demo\",\n  \"version\": \"1.0.0\",\n  \"scripts\": {\n    \"test\": \"node --test --test-reporter=tap\"\n  }\n}\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch3>ขั้นที่ 2: สร้างไฟล์ .github\u002Fworkflows\u002Fci.yml\u003C\u002Fh3>\u003Cpre>\u003Ccode class=\"language-yaml\">name: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n    branches: [main]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v7\n      - uses: actions\u002Fsetup-node@v7\n        with:\n          node-version: 24\n      - run: npm test\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>อ่านทีละส่วน:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Ccode>on\u003C\u002Fcode> สั่งให้รันเมื่อมี Push หรือ Pull Request เข้า Branch main\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ccode>runs-on: ubuntu-latest\u003C\u002Fcode> ขอ Runner ที่เป็น Ubuntu เวอร์ชันล่าสุดที่ GitHub เตรียมไว้\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ccode>actions\u002Fcheckout@v7\u003C\u002Fcode> ดึงโค้ดใน Repository ลงมาบน Runner\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ccode>actions\u002Fsetup-node@v7\u003C\u002Fcode> ติดตั้ง Node.js เวอร์ชัน 24 ตามตัวอย่างใน README ของ Action นี้\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ccode>npm test\u003C\u002Fcode> รันเทสต์ ถ้าเทสต์ล้ม Step นี้ก็ล้ม\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>เรื่องเลขเวอร์ชัน ทีมเราเช็กจากหน้า Releases ของแต่ละ Action เมื่อ 1 ตุลาคม 2026: \u003Ccode>actions\u002Fcheckout\u003C\u002Fcode> ล่าสุดคือ v7.0.1 (20 กรกฎาคม 2026) และ \u003Ccode>actions\u002Fsetup-node\u003C\u002Fcode> ล่าสุดคือ v7.0.0 (14 กรกฎาคม 2026) ที่น่าสังเกตคือตัวอย่าง Node.js ใน GitHub Docs วันเดียวกันยังใช้ \u003Ccode>actions\u002Fcheckout@v6\u003C\u002Fcode> อยู่ ถ้าเลขในเอกสารกับใน Repository ของ Action ไม่ตรงกัน ให้ยึด Repository ของ Action เป็นหลัก\u003C\u002Fp>\u003Ch3>ขั้นที่ 3: รันเทสต์ในเครื่องก่อน Push\u003C\u002Fh3>\u003Cp>ก่อนให้ GitHub รัน ให้แน่ใจก่อนว่าคำสั่งเดียวกันผ่านในเครื่องตัวเอง ผลจริงจากเครื่องเรา (ตัดบรรทัดท้ายออก):\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-text\">> ci-demo@1.0.0 test\n> node --test --test-reporter=tap\n\nTAP version 13\n# Subtest: sum adds two numbers\nok 1 - sum adds two numbers\n  ---\n  duration_ms: 0.480792\n  type: 'test'\n  ...\n1..1\n# tests 1\n# suites 0\n# pass 1\n# fail 0\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>จากนั้นลองแกล้งทำโค้ดพัง เปลี่ยน \u003Ccode>a + b\u003C\u002Fcode> เป็น \u003Ccode>a - b\u003C\u002Fcode> แล้วรันใหม่ ผลคือ \u003Ccode>not ok 1 - sum adds two numbers\u003C\u002Fcode> พร้อมข้อความ \u003Ccode>-1 !== 5\u003C\u002Fcode> และ \u003Ccode># fail 1\u003C\u002Fcode> คำสั่งจบด้วย Exit Code 1 ส่วนตอนเทสต์ผ่าน Exit Code คือ 0\u003C\u002Fp>\u003Cp>ตัวเลขนี้แหละที่ GitHub Actions ใช้ตัดสิน เอกสาร Workflow syntax ระบุว่า Runner รายงานสถานะของ Step ว่าผ่านหรือล้มจาก Exit Code ของคำสั่ง ดังนั้นถ้าเพื่อนเย็นวันศุกร์คนนั้นเปิด Pull Request ที่ทำเทสต์พัง GitHub จะขึ้นสถานะล้มไว้ให้ทุกคนเห็นก่อนกด Merge เราไม่ได้แปะ Log จาก Runner จริงไว้ตรงนี้ เพราะบทความนี้ทดสอบบนเครื่องตัวเอง ไม่ได้รันบน GitHub\u003C\u002Fp>\u003Ch3>ขั้นที่ 4: เช็กว่า YAML อ่านออก\u003C\u002Fh3>\u003Cp>YAML พังเพราะเว้นวรรคผิดได้ง่ายมาก วิธีเช็กเร็วๆ คือให้ Python อ่านไฟล์ดู (ทีมเราใช้ PyYAML 6.0.3)\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">python3 -c \"import yaml; print(yaml.safe_load(open('.github\u002Fworkflows\u002Fci.yml')))\"\u003C\u002Fcode>\u003C\u002Fpre>\u003Cblockquote>\u003Cp>Fun Fact: ผลที่ได้จะเห็น Key ชื่อ \u003Ccode>True\u003C\u002Fcode> แทน \u003Ccode>on\u003C\u002Fcode> เพราะ PyYAML อ่านตามสเปก YAML 1.1 ที่ถือว่าคำว่า on คือค่า boolean ไฟล์ไม่ได้ผิด GitHub อ่าน \u003Ccode>on\u003C\u002Fcode> ได้ถูกต้อง แค่อย่าตกใจถ้าเห็นแบบนี้ตอนเช็กในเครื่อง\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>การเช็กแบบนี้บอกได้แค่ว่า YAML ถูกไวยากรณ์ ไม่ได้บอกว่าชื่อ Key ถูกตามที่ GitHub ต้องการ ส่วนนั้นต้องเทียบกับ Workflow syntax หรือดูผลหลัง Push ในแท็บ Actions ของ Repository\u003C\u002Fp>\u003Ch2>มี CI\u002FCD แล้ว โค้ดจะไม่พังอีกเลยใช่ไหม\u003C\u002Fh2>\u003Cp>ไม่ใช่ CI รันได้แค่เทสต์ที่คุณเขียนไว้ ถ้าบั๊กเกิดในส่วนที่ไม่มีเทสต์ครอบ Pipeline ก็จะขึ้นเขียวอย่างมั่นใจ ทั้งที่โค้ดพัง สถานะเขียวจึงแปลว่า \"ผ่านทุกอย่างที่เราสั่งให้ตรวจ\" ไม่ได้แปลว่า \"ถูกต้องแล้ว\"\u003C\u002Fp>\u003Cp>สิ่งที่ช่วยได้จริงคือการวางรั้วให้ครบ ตั้งให้ Branch main รับเฉพาะ Pull Request ที่ CI ผ่าน เพิ่มเทสต์ทุกครั้งที่เจอบั๊กใหม่ และถ้ายังไม่มั่นใจในชุดเทสต์ ให้เริ่มจาก Continuous Delivery ที่ยังมีคนกดปล่อย ก่อนขยับไป Continuous Deployment ส่วนวิธีวาง Branch ให้ทั้งทีมใช้ร่วมกัน อ่านต่อได้ที่ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fgit-for-team-professional-workflow-guide\">Git for Team: คู่มือวาง Workflow ไม่ให้โค้ดพัง\u003C\u002Fa> และถ้าทีมยังเถียงกันว่าจะรวม Branch แบบไหน มีบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fgit-rebase-vs-merge\">Git Rebase vs Merge ต่างกันยังไง\u003C\u002Fa> รออยู่\u003C\u002Fp>\u003Cp>เมื่อ Workflow แรกรันได้แล้ว ขั้นต่อไปคือเพิ่ม Lint, Build หรือเลือกเครื่องมืออื่นที่เหมาะกับทีม เรามีบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002F10-ways-to-enhance-code-development-efficiency-using-ci-cd\">10 วิธีการเพิ่มประสิทธิภาพในกระบวนการพัฒนาโค้ดด้วย CI\u002FCD\u003C\u002Fa> ที่รวบรวมเทคนิคและเครื่องมืออย่าง Jenkins กับ GitLab CI\u002FCD ไว้ให้ไล่อ่านต่อ\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>สรุป: CI\u002FCD คืออะไร และควรเริ่มตรงไหน\u003C\u002Fh2>\u003Cp>CI คือการให้เครื่อง Build และ Test ทุกครั้งที่มีโค้ดใหม่ CD คือการส่งโค้ดที่ผ่านแล้วไปถึงผู้ใช้ โดย Continuous Delivery ยังให้คนกดปล่อย ส่วน Continuous Deployment ปล่อยเองทั้งหมด Pipeline ส่วนใหญ่มีสามขั้น Build, Test และ Deploy และ GitHub Actions ทำทั้งหมดนี้ได้จากไฟล์ YAML ไฟล์เดียวใน \u003Ccode>.github\u002Fworkflows\u003C\u002Fcode>\u003C\u002Fp>\u003Cp>ไม่ต้องรอให้โปรเจกต์ใหญ่ก่อนค่อยเริ่ม เอาโปรเจกต์ที่มีอยู่ตอนนี้ เขียนเทสต์สักหนึ่งตัว วางไฟล์ \u003Ccode>ci.yml\u003C\u002Fcode> ตามตัวอย่างข้างบน แล้ว Push ดู ครั้งแรกที่เห็นเครื่องหมายเขียวขึ้นข้าง Commit คุณจะไม่อยากกลับไป Merge แบบลุ้นๆ อีกเลย\u003C\u002Fp>\u003Cp>ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา\u003C\u002Fp>\u003Cp>Facebook: \u003Cstrong>Superdev Academy Thailand\u003C\u002Fstrong> (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.academy.th\">https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.academy.th\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>YouTube: \u003Cstrong>Superdev Academy Channel\u003C\u002Fstrong> (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.youtube.com\u002F@SuperdevAcademy\">https:\u002F\u002Fwww.youtube.com\u002F@SuperdevAcademy\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>Instagram: \u003Cstrong>@superdevacademy\u003C\u002Fstrong> (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.instagram.com\u002Fsuperdevacademy\u002F\">https:\u002F\u002Fwww.instagram.com\u002Fsuperdevacademy\u002F\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>TikTok: \u003Cstrong>@superdevacademy\u003C\u002Fstrong> (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.tiktok.com\u002F@superdevacademy?lang=th-TH\">https:\u002F\u002Fwww.tiktok.com\u002F@superdevacademy?lang=th-TH\u003C\u002Fa>)\u003C\u002Fp>","cover_cover_6jpf1wjuu6.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F9pbxud9ly7qk123\u002Fl\u002Fcover_cover_6jpf1wjuu6.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F9pbxud9ly7qk123\u002Fm\u002Fcover_cover_6jpf1wjuu6.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F9pbxud9ly7qk123\u002Fcover_cover_6jpf1wjuu6.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F9pbxud9ly7qk123\u002Fs\u002Fcover_cover_6jpf1wjuu6.webp","2026-10-01 06:31:24.495Z","wfztm6bp9384v3u",{"keywords":18,"locale":49,"school_blog":59},[19,27,31,35,40,45],{"collectionId":20,"collectionName":21,"created":22,"created_by":23,"id":24,"name":25,"updated":26,"updated_by":23},"sclkey987654321","school_keywords","2026-03-04 08:44:18.322Z","76qprkevbgfdps8","1n94l86nx7etuf9","CI\u002FCD","2026-06-07 06:46:30.916Z",{"collectionId":20,"collectionName":21,"created":28,"created_by":16,"id":29,"name":30,"updated":28,"updated_by":16},"2026-10-01 06:31:24.489Z","sw6iitu997lr6ly","CI\u002FCD Pipeline",{"collectionId":20,"collectionName":21,"created":32,"created_by":16,"id":33,"name":34,"updated":32,"updated_by":16},"2026-10-01 06:31:24.490Z","wsrud061xh3ixpg","GitHub Actions",{"collectionId":20,"collectionName":21,"created":36,"created_by":23,"id":37,"name":38,"updated":39,"updated_by":23},"2026-03-04 08:49:20.321Z","v09yffuhbx6p9ek","Continuous Integration","2026-06-07 06:48:11.501Z",{"collectionId":20,"collectionName":21,"created":41,"created_by":23,"id":42,"name":43,"updated":44,"updated_by":23},"2026-03-04 08:49:20.065Z","zjrm8kyoqcqp2te","Continuous Delivery","2026-06-07 06:48:11.283Z",{"collectionId":20,"collectionName":21,"created":46,"created_by":16,"id":47,"name":48,"updated":46,"updated_by":16},"2026-10-01 06:31:24.491Z","5qr1zf2a803jh6y","Continuous Deployment",{"code":50,"collectionId":51,"collectionName":52,"created":53,"flag":54,"id":55,"is_default":56,"label":57,"updated":58},"th","pbc_1989393366","locales","2026-01-22 10:59:55.832Z","twemoji:flag-thailand","s8wri3bt4vgg2ji",true,"Thai","2026-04-10 15:42:46.614Z",{"category":60,"collectionId":61,"collectionName":62,"created":63,"expand":64,"id":80,"slug":81,"updated":82,"views":83},"qn0d7xwatkleou1","pbc_2105096300","school_blogs","2026-10-01 06:31:24.492Z",{"category":65},{"blogIds":66,"collectionId":67,"collectionName":68,"created":69,"created_by":23,"id":60,"image":70,"image_alt":71,"image_path":72,"image_s_url":73,"label":74,"name":75,"priority":76,"publish_at":77,"scheduled_at":71,"status":78,"updated":79,"updated_by":23},[],"sclcatblg987654321","school_category_blogs","2026-03-04 08:31:21.896Z","4jn5ccty4x9_2894s1fj97_azjr5xx2br.webp","","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Fqn0d7xwatkleou1\u002F4jn5ccty4x9_2894s1fj97_azjr5xx2br.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Fqn0d7xwatkleou1\u002Fs\u002F4jn5ccty4x9_2894s1fj97_azjr5xx2br.webp",{"en":75,"th":75},"How to",0,"2025-02-04 08:40:59.666Z","published","2026-08-18 14:49:10.697Z","x3e3xuldfzeouel","what-is-ci-cd-github-actions","2026-10-28 09:47:34.772Z",143,"9pbxud9ly7qk123",[24,29,33,37,42,47],"2026-10-28 01:46:10.461Z","CI\u002FCD คืออะไร Continuous Delivery กับ Deployment ต่างกันยังไง พร้อมลองเขียน GitHub Actions ไฟล์แรกที่รัน npm test ทุกครั้งที่ Push และผลรันจริงจากเครื่องเรา","CI\u002FCD คืออะไร? เริ่มทำ Pipeline แรกด้วย GitHub Actions","2026-10-28 01:46:10.464Z","ebkf8ra4nd55ual",1,[93,97,101,105,109,113],{"answer":94,"id":95,"question":96},"CI ย่อมาจาก Continuous Integration ส่วน CD ย่อมาจาก Continuous Delivery หรือ Continuous Deployment แล้วแต่บริบท Continuous Integration คือการ Build และ Test โค้ดอัตโนมัติทุกครั้งที่มีคน Commit เข้า Repository กลาง ส่วน CD คือการส่งโค้ดที่ผ่านการตรวจแล้วไปยังระบบจริง จึงควรดูให้ชัดว่าเอกสารที่อ่านอยู่หมายถึง CD แบบไหน","ylvvcsayba46ov9","CI\u002FCD ย่อมาจากอะไร",{"answer":98,"id":99,"question":100},"CI\u002FCD Pipeline คือลำดับขั้นตอนอัตโนมัติที่โค้ดต้องผ่านตั้งแต่ Push จนถึงผู้ใช้ ส่วนใหญ่มี 3 ขั้น คือ Build, Test และ Deploy ถ้าขั้นไหนล้ม เช่น npm test จบด้วย Exit Code 1 ขั้นถัดไปจะไม่ถูกรัน โค้ดที่มีปัญหาจึงไปไม่ถึง Production","f1k8rn6t60misgf","CI\u002FCD Pipeline คืออะไร",{"answer":102,"id":103,"question":104},"CI\u002FCD มี 3 ส่วนที่ควรแยกให้ออก คือ Continuous Integration ที่ Build และ Test ทุก Commit, Continuous Delivery ที่ทำให้โค้ดพร้อมปล่อยเสมอแต่ยังให้คนกดปล่อย และ Continuous Deployment ที่ปล่อยขึ้น Production อัตโนมัติ เครื่องมือที่ใช้ทำได้ เช่น GitHub Actions, GitLab CI\u002FCD และ Jenkins","ao5mgnrcpvk39b1","CI\u002FCD มีอะไรบ้าง",{"answer":106,"id":107,"question":108},"ต่างกันที่ขั้นสุดท้าย Continuous Delivery ทำให้โค้ดพร้อม Deploy ได้ตลอด แต่ให้คนเลือกเวลาปล่อย ส่วน Continuous Deployment ปล่อยทุกการเปลี่ยนแปลงที่ผ่าน Pipeline ขึ้น Production เองอัตโนมัติ Martin Fowler อธิบายไว้ที่ martinfowler.com ว่าการทำ Continuous Deployment ได้ต้องทำ Continuous Delivery ได้ก่อน","h5o3kcyqch7qrpm","Continuous Delivery กับ Continuous Deployment ต่างกันอย่างไร",{"answer":110,"id":111,"question":112},"GitHub Actions คือระบบ CI\u002FCD ที่มากับ GitHub โดยคุณเขียนขั้นตอนเป็นไฟล์ YAML เก็บไว้ในโฟลเดอร์ .github\u002Fworkflows แล้ว GitHub จะรันบน Runner อย่าง ubuntu-latest ทุกครั้งที่เกิดเหตุการณ์ที่กำหนดใน on เช่น push หรือ pull_request ไฟล์หนึ่งไฟล์เรียกว่า Workflow ประกอบด้วย Job และ Step","muomx1ngi7ujcaa","GitHub Actions คืออะไร",{"answer":114,"id":115,"question":116},"GitHub Actions ใช้ฟรีสำหรับ Public Repository ที่รันบน Standard GitHub-hosted Runner และสำหรับ Self-hosted Runner ตามหน้า Billing ของ GitHub Docs ส่วน Private Repository บนแพ็กเกจ GitHub Free ได้โควตา 2,000 นาทีต่อเดือน ข้อมูลนี้ตรวจเมื่อ 1 ตุลาคม 2026 และเปลี่ยนได้ ควรเช็กหน้า Billing อีกครั้งก่อนวางแผนจริง","i8sj735jcy8j3ia","GitHub Actions ใช้ฟรีไหม",{"th":81,"en":81}]