DAY 04 Curriculum Standard v3.2
Step 01 – Step 06
Autonomous Trigger Engine

SCM Integration, Git Triggers & Polling

เชื่อมต่อประสาทสัมผัสของ Jenkins เข้ากับ Source Control: เปรียบเทียบเทคโนโลยีการปลุกไปป์ไลน์ระหว่าง Push Webhooks, การเฝ้าตรวจ pollSCM, และกลไกกระจายโหลดด้วย H (Hash) Cron Triggers พร้อมกลยุทธ์ Checkout ที่รวดเร็วและปลอดภัย

Pedagogy Rule
Human First
Interactive Lab
Trigger & Hash Cron
Spaced Recall
9 D4 + 2 D3 + 2 D2 + 2 D1
Architectural Rule

"Never Exhaust Your SCM With Aggressive Polling."

ไปป์ไลน์ที่ฉลาดต้องถูกปลุกผ่าน Event-Driven Push Notification (Webhooks) เท่านั้น หากจำเป็นต้องใช้ Scheduled Cron ต้องมีสัญลักษณ์ `H` (Hash) เสมอเพื่อกระจายโหลด ไม่ให้เซิร์ฟเวอร์รุมยิง Git พร้อมกันตอนต้นชั่วโมง

Spaced Repetition Active Recall

ข้อสอบวันนี้มี 15 ข้อ ประกอบด้วยเนื้อหาใหม่ Day 4 จำนวน 9 ข้อ, ทบทวน Day 3 จำนวน 2 ข้อ, ทบทวน Day 2 จำนวน 2 ข้อ, และทบทวนสถาปัตยกรรม Day 1 จำนวน 2 ข้อ

DAY 04 TRIGGER SPEC READY TO STUDY
STEP 01

Introduced Topic & The Big Picture

Definition ในภาษามนุษย์

SCM Integration และ Triggers คืออะไรในระบบ Jenkins?

SCM Integration คือ "แขนกลที่เอื้อมไปดึงโค้ดมาจากตู้เซฟ Git" (เช่น GitHub, GitLab, Bitbucket) เข้ามาไว้บนเครื่อง Agent เพื่อเตรียมรันบิลด์ ส่วน Triggers คือ "เซนเซอร์จับความเคลื่อนไหว" ที่คอยสั่งให้ Jenkins ตื่นขึ้นมาทำงานทันทีอัตโนมัติ โดยที่โปรแกรมเมอร์ไม่ต้องมานั่งกดปุ่ม "Build Now" บนหน้าเว็บด้วยตัวเองแม้แต่ครั้งเดียว

Before (รันมือ / นั่งเฝ้าหน้าจอ) Manual Overhead
  • ต้องโทรแจ้งหรือทักแชต: พอโปรแกรมเมอร์ Push โค้ดเสร็จ ต้องทักบอกทีม DevOps ให้ช่วยกดปุ่มบิลด์ เสียเวลาและเกิดคอขวด
  • บิลด์ข้ามการอัปเดต: บางคนลืมกดบิลด์ ทำให้โค้ดที่ผิดพลาดถูกทิ้งไว้ใน Repo นานหลายวันโดยไม่มีใครรู้ว่าคอมไพล์ไม่ผ่าน
  • ตั้งรอบบิลด์แบบเดาสุ่ม: กำหนดเวลารันตอนเที่ยงคืน แต่โค้ดไม่มีการเปลี่ยนแปลง ทำให้เซิร์ฟเวอร์ตื่นมารันฟรีเปลืองไฟและค่า Cloud
After (Webhook Event-Driven + Hash Cron) Autonomous CI/CD
  • ตื่นทันทีใน 500ms ด้วย Webhook: ทันทีที่คำสั่ง `git push` สำเร็จ GitHub จะสะกิด Jenkins ให้เริ่มบิลด์ทันทีแบบ Real-time
  • ตรวจจับเฉพาะกิ่งที่ต้องการ: บิลด์เฉพาะกิ่งที่มีการแก้จริง เช่น กิ่ง `main` หรือเมื่อมี Pull Request เข้ามาทดสอบ
  • กระจายภาระด้วย Hash Cron (H): งานประเภท Nightly Test จะสุ่มเวลารันอย่างสมดุล ไม่แย่ง CPU กันตอน 00:00 น. เป๊ะ
Anatomy: 4 เสาหลักของระบบ SCM & Triggers ใน Jenkins
Trigger Taxonomy
MECHANISM 01
Webhook (Push-based)

Git Provider (เช่น GitHub/GitLab) เป็นฝ่ายยิง HTTP POST Request มาหา Jenkins ทันทีที่มี Commit หรือ PR เกิดขึ้น รวดเร็วและไม่เปลืองทรัพยากร

MECHANISM 02
Poll SCM (Pull-based)

Jenkins เป็นฝ่ายวิ่งไปถาม Git Server เป็นระยะ (เช่น ทุก 5 นาที) ว่ามีโค้ดใหม่ไหม หากมีจึงจะเริ่มบิลด์ มีภาระโหลดสูงกว่า

MECHANISM 03
H-Hash Cron Triggers

คำสั่งตั้งเวลารันตามตารางเวลา เช่น triggers { cron('H 2 * * *') } โดยตัวอักษร H จะคำนวณแฮชชื่อ Job เพื่อกระจายนาทีที่รัน

MECHANISM 04
checkout scm Directive

คำสั่งดาวน์โหลด Source Code ลงบน Workspace ของ Agent โดยอัตโนมัติตามกิ่งและ Commit ID ที่ทริกเกอร์บิลด์นั้น

STEP 02

Everyday Mental Model & Intuition

ภาพจำในชีวิตประจำวัน: กริ่งประตูบ้าน (Webhook) vs คนเดินไปดูตู้ไปรษณีย์ทุก 5 นาที (Poll SCM)

หากต้องการเห็นภาพความแตกต่างระหว่างกลไกทริกเกอร์แต่ละแบบ ให้จินตนาการถึง **การรอรับพัสดุที่บ้าน**:

01
กริ่งประตูอัจฉริยะ (Webhook)

บุรุษไปรษณีย์มาถึงหน้าบ้านแล้วกดกริ่ง "ติ๊งต่อง!" ทันที เจ้าของบ้านที่นั่งดูทีวีอยู่เดินออกมาเปิดประตูรับของได้ทันทีใน 2 วินาที ไม่ต้องเสียแรงเดินไปหน้าบ้านก่อนเวลา

02
คนเดินไปดูตู้จดหมาย (Poll SCM)

บ้านไม่มีกริ่ง เจ้าของบ้านต้องลุกจากโซฟาเดินออกไปชะโงกดูตู้จดหมายทุกๆ 5 นาที 99% ของการเดินไปคือตู้ว่างเปล่า เสียพลังงาน และถ้าของมาตอนนาทีที่ 1 ต้องรอไปอีก 4 นาทีถึงจะรู้

03
นาฬิกาปลุกกระจายรอบ (H-Cron)

ถ้าตั้งให้นักเรียน 500 คนออกจากหอพักพร้อมกันตอน 07:00 น. บันไดจะถล่ม แต่ถ้าให้อาจารย์สุ่มระบุว่า "ห้องเลขคู่ไป 07:08 น., ห้องเลขคี่ไป 07:22 น." ทุกคนจะเดินทางสะดวกไร้คอขวด

STEP 03

Real-World Engineering Context & War Story

Production War Story: วิกฤต GitHub IP Rate-Limit Ban ถล่มทั้งองค์กร
SEV-1 SCM OUTAGE

จุดเริ่มต้น: องค์กรด้านการเงินแห่งหนึ่งมี Microservices กว่า 300 โปรเจกต์ใน Jenkins วิศวกรทุกคนตั้งค่าการตรวจสอบโค้ดแบบก๊อปปี้ต่อกันมาคือ: triggers { pollSCM('* * * * *') } ซึ่งหมายถึงสั่งให้ Jenkins ส่งคำสั่ง Git Poll ข้ามอินเทอร์เน็ตไปถาม GitHub Enterprise/Cloud ทุกๆ 60 วินาทีตลอด 24 ชั่วโมง

วันที่พังยับเยิน: เมื่อรวม 300 โปรเจกต์ เท่ากับว่า Jenkins Controller กำลังยิง Request ออกไปหา GitHub มากกว่า 18,000 ครั้งต่อชั่วโมง จาก IP เดียวกันของบริษัท ผลปรากฏว่าระบบ DDoS Defense ของ GitHub ทำงานและสั่ง แบน IP Address ขาออกของออฟฟิศทั้งหมดทันที

สิ่งที่เกิดขึ้น: นักพัฒนา 400 คนในบริษัทไม่สามารถ `git clone`, `git push`, หรือแม้แต่เปิดดู Pull Request ได้เลย Jenkins ทุกตัวติด Error HTTP 429 Too Many Requests งานส่งมอบโค้ดหยุดชะงักทั้งบริษัทเป็นเวลา 8 ชั่วโมงจนกว่าทีม Security จะทำเรื่องขอปลดบล็อกจากฝ่ายสนับสนุน

หลักการแก้ปัญหาแบบ Senior DevOps: Push Webhooks + H-Hash Schedules

ยกเลิก pollSCM ทั้งหมด! แล้วเปลี่ยนมาติดตั้ง GitHub Webhook ที่ยิงมาเฉพาะตอนมีโค้ดใหม่จริง และสำหรับงานตั้งเวลาตกดึก ให้เปลี่ยนจาก 0 0 * * * มาเป็น H H(0-2) * * * เพื่อให้ Jenkins คำนวณ Hash กระจายเวลารันอัตโนมัติ ไม่เกิด Spike โหลดพร้อมกัน

STEP 04

Hands-on Syntax Breakdown (ลงมือทำทีละก้าว 3 ระดับ)

LEVEL 01: IMPLICIT VS EXPLICIT CHECKOUT

การดึงซอร์สโค้ดด้วย checkout scm

Basic SCM Access
pipeline {
    agent any

    stages {
        stage('Inspect Source Code') {
            steps {
                // โดยปกติ Declarative Pipeline จะสั่ง checkout scm อัตโนมัติเมื่อเริ่ม stage แรก
                echo "Current Git Commit: ${env.GIT_COMMIT}"
                echo "Current Git Branch: ${env.GIT_BRANCH}"
                
                // แสดงรายการไฟล์ที่ดึงมาจาก Git
                sh 'git status && ls -la'
            }
        }
    }
}

คำอธิบาย: ใน Declarative Pipeline ค่าเริ่มต้นจะทำ Automatic Checkout ให้เสมอ ทำให้โค้ดจากกิ่งที่ถูกทริกเกอร์มาปรากฏในโฟลเดอร์ Workspace ของเครื่อง Agent โดยอัตโนมัติ

LEVEL 02: HASH-BASED CRON TRIGGERS

การตั้งเวลาบิลด์อัตโนมัติด้วย triggers { cron('H ...') }

Load Balancing Cron
pipeline {
    agent any

    triggers {
        // รันทุกวันระหว่างช่วงเวลา 02:00 - 04:00 น. โดยใช้ Hash (H) สุ่มนาทีและชั่วโมงที่แน่นอน
        cron('H H(2-4) * * *')
        
        // Poll ตรวจสอบ SCM ทุกๆ 30 นาที (สุ่มนาทีโดย H เพื่อไม่ให้รุม Git)
        pollSCM('H/30 * * * *')
    }

    stages {
        stage('Nightly Regression Suite') {
            steps {
                echo 'Running heavy nightly integration tests...'
                sh './run-extended-tests.sh'
            }
        }
    }
}

คำอธิบาย: สัญลักษณ์ H ย่อมาจาก Hash โดย Jenkins จะนำชื่อของ Job ไปแปลงเป็นค่าตัวเลขคงที่ เช่น Job A อาจได้นาทีที่ 14 ส่วน Job B อาจได้นาทีที่ 37 ทำให้งานไม่เริ่มพร้อมกัน

LEVEL 03: ENTERPRISE WEBHOOK WITH BRANCH FILTERING

การผูก Webhook ร่วมกับเงื่อนไข when { branch } และ Skip Checkout

Production Standard
pipeline {
    agent any

    options {
        // ปิด Automatic checkout เพื่อให้เราควบคุมเองใน stage ที่ต้องการ
        skipDefaultCheckout(true)
        timeout(time: 30, unit: 'MINUTES')
    }

    stages {
        stage('Selective Git Checkout') {
            steps {
                // สั่งดึงโค้ดเฉพาะเมื่อจำเป็น
                checkout scm
            }
        }

        stage('Deploy to Production') {
            // รันเฉพาะเมื่อการเปลี่ยนแปลงเกิดขึ้นบนกิ่ง main หรือ master เท่านั้น
            when {
                branch 'main'
            }
            steps {
                echo 'Deploying validated code from main branch...'
            }
        }
    }

    post {
        always {
            cleanWs()
        }
    }
}

คำอธิบาย: การใช้ skipDefaultCheckout(true) มีประโยชน์มากในโปรเจกต์ขนาดใหญ่ที่บาง Stage ต้องการแค่ดาวน์โหลด Docker Image หรือรัน Notification โดยไม่ต้องเสียเวลาดาวน์โหลดซอร์สโค้ดทั้งก้อน

STEP 05

Interactive Simulator: SCM Trigger & Hash-Cron Calculator

จำลองสถานการณ์: เปรียบเทียบความเร็วและโหลดระหว่าง Webhook Push vs Poll SCM vs H-Cron

เลือกรูปแบบ Trigger ด้านล่าง ระบุกิ่ง Git (Branch Name) และคลิกปุ่ม "Simulate Git Event" เพื่อดูความเร็วการตอบสนองและจำนวน API Request ที่ส่งไปยัง Git Provider

Trigger Simulation Controller Event Engine
Enable when { branch 'main' } Gate:

หากเปิดไว้ กิ่งที่ไม่ใช่ 'main' จะข้าม Stage การ Deploy ทันที

Trigger Metrics & Response STATUS: STANDBY
LATENCY TO RUN
0 ms
API HOURLY LOAD
0 reqs
RESOLVED H-MINUTE
Min :42
[System] Trigger simulator loaded. Select trigger mode to simulate...
STEP 06

Cumulative Active Recall Deep-Dive Exam (15 MCQs)

Spaced Repetition: 9 New (Day 04) + 2 Recall (Day 03) + 2 Recall (Day 02) + 2 Recall (Day 01)
Score:
0 / 15
Answered: 0/15