Jenkins Professional - Phase 2: Robust & Scalable Delivery Pipelines Overview

PHASE 02 Intermediate Standard v3.2

Day 06 – Day 11

Team & Production-Grade CI/CD

Robust & Scalable Delivery

ยกระดับจากไปป์ไลน์เดี่ยว สู่ระบบส่งมอบระดับองค์กรที่ปลอดภัย ทรงพลัง และนำกลับมาใช้ซ้ำได้: ป้องกันความลับรั่วไหลด้วย Credentials, บิลด์ใน Docker Agents ที่สะอาดหมดจด, ติดตั้ง Approval Gates, เร่งสปีดด้วย Parallel Threads, และสร้างมาตรฐานกลางด้วย Shared Libraries

Duration

6 Days

Learning Method

6 Steps

Active Recall

90 MCQs

Architectural Shift

"From Individual Scripts to Enterprise Standards."

ใน Phase 2 เราจะหยุดคัดลอก Jenkinsfile แปะซ้ำๆ และก้าวสู่วิศวกรรมซอฟต์แวร์ระดับสากล: ความลับต้องไม่ปรากฏในโค้ดหรือ Log, สภาพแวดล้อมบิลด์ต้องเป็น Ephemeral Containers, และฟังก์ชันไปป์ไลน์ทั้งหมดต้องถูกรวมศูนย์ไว้ใน Shared Library เพียงจุดเดียว

Spaced Recall สะสมข้าม Phase (Day 01 – Day 11)

ข้อสอบ 15 ข้อในแต่ละวันของ Phase 2 จะรักษาความจำของ Phase 1 (Controller/Agent, Declarative Syntax, Parameters, SCM, Artifacts) ไว้อย่างเหนียวแน่น พร้อมทดสอบเจาะลึกเนื้อหาใหม่ 9 ข้อต่อวัน

PHASE 2 SPECIFICATION READY TO STUDY

Scientific Learning Protocol

แผนผัง Spaced Repetition Cumulative Quizzes (90 ข้อ)

ในแต่ละวันของ Phase 2 จะมีข้อสอบปรนัย Interactive MCQ 15 ข้อ (ใหม่ 9 ข้อ + ทบทวน 6 ข้อ) ตรวจผลและคำนวณคะแนนทันที

15 MCQs / Day × 6 Days = 90 MCQs

Day / Topic	New Material (วันปัจจุบัน)	Cumulative Active Recall (ทบทวนวันก่อน)	Total MCQs
D06 Credentials Management & Security	9 ข้อ (60%) — Secret Text, SSH, `withCredentials`, Masking	6 ข้อ (40%) — ทบทวน Phase 1 (D5: 2, D4: 2, D3: 1, D2: 1)	15
D07 Docker as Pipeline Execution Agents	9 ข้อ (60%) — `agent { docker }`, Volume Mounts, DinD Pitfalls	6 ข้อ (40%) — ทบทวน Day 6 (3 ข้อ) + Phase 1 (3 ข้อ)	15
D08 Flow Control: Conditions & Approval Gates	9 ข้อ (60%) — Directive `when`, `input` gates, submitter whitelist	6 ข้อ (40%) — ทบทวน Day 7 (2 ข้อ) + Day 6 (2 ข้อ) + Phase 1 (2 ข้อ)	15
D09 Parallel Execution, Fail-Fast & Resilience	9 ข้อ (60%) — `parallel`, `failFast: true`, `timeout`, `retry`	6 ข้อ (40%) — ทบทวน Day 8 (2 ข้อ) + Day 7 (2 ข้อ) + Day 6 (2 ข้อ)	15
D10 Jenkins Shared Libraries (DRY Architecture)	9 ข้อ (60%) — `@Library`, `vars/`, `src/`, Custom Groovy DSL	6 ข้อ (40%) — ทบทวน Day 9 (2 ข้อ) + Day 8 (2 ข้อ) + Day 7-6 (2 ข้อ)	15
D11 Quality Gates & Enterprise Notifications	9 ข้อ (60%) — SonarQube Quality Gate, Webhook Alerting, Slack payload	6 ข้อ (40%) — Phase 2 Grand Synthesis (D10, D9, D8, D7, D6)	15

Phase 2 Execution Schedule

แผนการเรียนรู้ 6 วันแบบ Interactive Timeline (Day 06 – 11)

คลิก "View 6 Steps" เพื่อกางดูรายละเอียดแต่ละวัน

DAY 06 Pipeline Security & Secrets

Jenkins Credentials Management & Security

15 MCQs (9 D6 + 6 P1 Recall)

ปกป้องกุญแจสำคัญขององค์กร: การจัดเก็บความลับ (Secret text, Username/Password, SSH Key), การเรียกใช้อย่างปลอดภัยผ่านคำสั่ง withCredentials และการรับมือกับดัก Log Masking bypass

01. Human Definition

Credentials Management คือตู้เซฟกลางบน Controller ที่เก็บกุญแจ รหัสผ่าน และ Token ทั้งหมด โดยไม่ยอมให้ใครอ่านรหัสผ่านตรงๆ จาก Jenkinsfile และเซ็นเซอร์ตัวอักษรเป็นดอกจัน (****) บนหน้าจอ Log

02. Everyday Mental Model

คีย์การ์ดดิจิทัลของโรงแรม: แขกแตะคีย์การ์ดเพื่อเปิดประตูลิฟต์และห้องพักได้ทันที โดยแขกไม่ต้องรู้ว่ารหัสฐานสองในชิปคือเลขอะไร

Before vs After Comparison

ถ้าไม่มี: ฮาร์ดโค้ด Password/Token ลงใน Jenkinsfile พอ Commit เข้า Git คนทั้งบริษัทเห็นรหัสผ่านหมด | ถ้ามี: ระบุเพียง Credential ID ในโค้ด และค่าจริงจะถูก Mask ซ่อนใน Log อัตโนมัติ

03. Production War Story

วิศวกรใช้คำสั่ง echo "Deploying with token: $API_TOKEN" ใน Bash Script ส่งผลให้ Masking หลุดรั่วผ่าน Subshell บันทึกลง Log สาธารณะ จนระบบคลาวด์โดนแฮกและเกิดค่าเสียหายกว่า $45,000

04. Hands-on Syntax Levels

L1: environment { AWS_SECRET = credentials('aws-prod-key') }

L2: ใช้บล็อก withCredentials([string(credentialsId: '...', variable: 'TOKEN')]) { ... }

L3: SSH User Private Key binding พร้อมการทำ Secret Masking Audit ตรวจจับ String Leak

05. Simulator Objective: ทดสอบกลไก Log Masking และตรวจจับการหลุดรั่วของตัวแปรลับเมื่อส่งผ่าน Shell

Exam: 9 D6 + 6 Recall (Phase 1)

DAY 07 Containerized Build Farm

Docker as Pipeline Execution Agents

15 MCQs (9 D7 + 6 Recall)

บอกลาปัญหา Dependency ทะเลาะกันบนโฮสต์: การใช้คำสั่ง agent { docker { ... } }, การ Mount Volume, การควบคุมสิทธิ์ UID/GID, และข้อควรระวังเรื่อง Docker-in-Docker (DinD)

01. Human Definition

Docker Agent คือการเสกห้องแล็บชั่วคราวขึ้นมารันเฉพาะงานนั้น เมื่อเริ่มบิลด์ Jenkins ดึง Docker Image ที่มี Tool ครบมารัน พอรันเสร็จก็ทำลายทิ้ง ไม่ทิ้งขยะตกค้างบนเครื่องโฮสต์

02. Everyday Mental Model

เต็นท์พยาบาลสนามแบบยกไปตั้ง: เจ้าหน้าที่ยกเต็นท์ที่มีเครื่องมือเฉพาะทางมาตั้งรักษาผู้ป่วย พอเสร็จภารกิจก็รื้อเก็บ ไม่ต้องต่อเติมอาคารหลักให้วุ่นวาย

Before vs After Comparison

ถ้าไม่มี: โปรเจกต์ A ใช้ Java 8, โปรเจกต์ B ใช้ Java 21 ต้องลงตีกันบน Agent เครื่องเดียวจน OS พัง | ถ้ามี: แต่ละ Stage ระบุ Docker image คนละเวอร์ชัน รันแยกกันอย่างอิสระ 100%

03. Production War Story

ทีมรัน Docker build ภายใน Docker Agent โดยใช้วิธี Privileged DinD ส่งผลให้ Container สั่งค้าง Resource และไฟล์ Socket `/var/run/docker.sock` ถูก Root Exploit แฮกเข้ายึด Host Node สำเร็จ

04. Hands-on Syntax Levels

L1: agent { docker 'node:20-alpine' }

L2: ปรับแต่งอาร์กิวเมนต์ args '-v /tmp/cache:/cache -u root:root'

L3: สั่งคอมไพล์จาก agent { dockerfile { filename 'Dockerfile.build' } } ภายใน Repo

05. Simulator Objective: ทดลองสลับ Docker Image และจำลองการ Mount Workspace ระหว่าง Container กับ Agent

Exam: 9 D7 + 6 Recall (D6 + P1)

DAY 08 Governance & Gatekeeper

Flow Control: Conditions & Approval Gates

15 MCQs (9 D8 + 6 Recall)

ประตูตรวจคนเข้าเมืองของโค้ด: การตั้งเงื่อนไข when (`branch`, `environment`, `expression`, `beforeAgent`), การสร้าง Manual Approval Gate ด้วยคำสั่ง input และ Whitelist ผู้อนุมัติ

01. Human Definition

Flow Control คือป้อมยามคอยตรวจเช็กว่า Stage นี้ควรข้ามหรือควรทำ และ Approval Gate คือปุ่มสีแดงที่ให้มนุษย์ (หัวหน้าทีม/QA) มากดปุ่ม "อนุมัติ" บนหน้าเว็บ ก่อนที่โค้ดจะถูกยิงขึ้น Production

02. Everyday Mental Model

ประตูล็อกรหัสปล่อยยานอวกาศ: คอมพิวเตอร์คำนวณวงโคจรทุกอย่างผ่านฉลุย แต่ระบบจะหยุดรอให้นายพลหมุนกุญแจพร้อมกัน 2 ดอก จรวดจึงจะจุดระเบิด

Before vs After Comparison

ถ้าไม่มี: Developer ทำงานบน feature branch พอรันเสร็จ สคริปต์เผลอยิงโค้ดทดลองขึ้น Production Server ลูกค้าจริงล่ม | ถ้ามี: มีเงื่อนไขล็อกกิ่ง `when { branch 'main' }` และติดปุ่ม Approval ดักไว้

03. Production War Story

ทีมใส่คำสั่ง `input` คอยการอนุมัติ แต่ลืมใส่ Timeout และลืมใช้ `agent none` ส่งผลให้ Job จองค้างเครื่อง Worker Node ตัวใหญ่ราคาแพงไว้ตลอดวันหยุดเสาร์-อาทิตย์ คิวงานอื่นติดค้างนับร้อย

04. Hands-on Syntax Levels

L1: when { branch 'main' } ข้าม Stage อัตโนมัติหากไม่ใช่กิ่งหลัก

L2: สร้างปุ่มกด input message: 'อนุมัติการ Deploy หรือไม่?', submitter: 'lead-devops'

L3: ผสาน timeout(time: 1, unit: 'HOURS') + beforeAgent true เพื่อไม่ให้จองเครื่องทิ้งไว้

05. Simulator Objective: จำลองการประเมินเงื่อนไข when และการกดอนุมัติ Approval Gate พร้อมจับเวลา Timeout

Exam: 9 D8 + 6 Recall (D7 + D6 + P1)

DAY 09 High-Speed Execution

Parallel Execution, Fail-Fast & Resilience

15 MCQs (9 D9 + 6 Recall)

ลดเวลาจาก 90 นาทีเหลือ 12 นาที: การรันงานขนานกันด้วยบล็อก parallel, กลยุทธ์ตัดไฟแต่ต้นลมด้วย failFast: true, การตั้งค่า timeout และการ retry อย่างชาญฉลาด

01. Human Definition

Parallel Execution คือการสั่งให้คน 4 คนช่วยกันทำงานพร้อมกัน เช่น คนแรกทดสอบฝั่ง Frontend, คนที่สองทดสอบ Backend, คนที่สามทดสอบ Security โดย Fail-Fast คือกฎว่า "ถ้าคนใดคนหนึ่งทำพัง ให้ทุกคนหยุดมือทันที ไม่ต้องรันต่อให้เสียเวลา"

02. Everyday Mental Model

ช่องตรวจตั๋วและกระเป๋าที่สนามบิน: เปิดเคาน์เตอร์เช็คอินพร้อมกัน 6 ช่องเพื่อระบายคน แต่ถ้าเครื่องสแกนตรวจพบวัตถุอันตราย สัญญาณเตือนภัยจะสั่งปิดทุกช่องเพื่อความปลอดภัยทันที

Before vs After Comparison

ถ้าไม่มี: รันเทสต์ 4 โมดูลต่อคิวกัน ใช้เวลาโมดูลละ 20 นาที รวม 80 นาที | ถ้ามี: กระจาย 4 เธรดขนาน รันเสร็จพร้อมกันใน 20 นาที ประหยัดเวลาทำงานทีมได้ถึง 4 เท่า

03. Production War Story

เธรดที่ 1 พังตั้งแต่วินาทีที่ 30 แต่ไม่มีออปชัน `failFast: true` ปล่อยให้เธรดที่ 2 และ 3 รันสูญเปล่าต่อไปอีก 50 นาที เสียทั้งเวลาและค่าบริการ Cloud Compute ไปฟรีๆ

04. Hands-on Syntax Levels

L1: โครงสร้าง parallel { stage('Unit') {} stage('Integration') {} }

L2: สั่งยกเลิกทันทีเมื่อเธรดใดพัง failFast: true

L3: คลุมด้วยความยืดหยุ่น retry(3) { timeout(time: 15, unit: 'MINUTES') { sh '...' } }

05. Simulator Objective: ทดลองสปีดการรันแบบ Sequential vs Parallel และดูพฤติกรรมตัดไฟ failFast

Exam: 9 D9 + 6 Recall (D8 + D7 + D6)

DAY 10 Code Reuse & Standards

Jenkins Shared Libraries (DRY Architecture)

15 MCQs (9 D10 + 6 Recall)

สร้าง Single Source of Truth ให้ 500 ไปป์ไลน์ในบริษัท: สถาปัตยกรรมไดเรกทอรี vars/ และ src/, การเขียน Custom DSL Steps, และการโหลดผ่านแท็ก @Library('[email protected]') _

01. Human Definition

Shared Libraries คือคลังฟังก์ชันกลางระดับบริษัท แทนที่ทุกคนในองค์กรต้องเขียนคำสั่งคอมไพล์โค้ดหรือ Deploy ซ้ำๆ 100 บรรทัด ทุกคนเพียงเขียนเรียกฟังก์ชันสั้นๆ บรรทัดเดียว เช่น `standardBuild()`

02. Everyday Mental Model

คู่มือมาตรฐานองค์กร (SOP): บริษัทออกระเบียบปฏิบัติมาตรฐานเพียงเล่มเดียว ทุกสาขานำไปปฏิบัติตามเหมือนกัน หากมีกฎหมายเปลี่ยน แก้ที่คู่มือกลางจุดเดียว ทุกสาขาอัปเดตพร้อมกันทันที

Before vs After Comparison

ถ้าไม่มี: ต้องตามแก้คำสั่ง Deploy ใน 300 โปรเจกต์ เสียเวลาเปิด Pull Request แก้ไขนานเป็นเดือน | ถ้ามี: แก้ที่ Shared Library จุดเดียว ทุกโปรเจกต์ได้คอนฟิกความปลอดภัยเวอร์ชันใหม่ทันที

03. Production War Story

ทีมอัปเดตโค้ดในกิ่ง `master` ของ Shared Library โดยไม่ล็อก Release Tag ปรากฏว่าบั๊กใน Library กระจายถล่มไปป์ไลน์ทั้ง 400 งานของบริษัท พังพร้อมกันในเช้าวันจันทร์

04. Hands-on Syntax Levels

L1: เรียกใช้ไลบรารี @Library('[email protected]') _

L2: สร้าง Custom Global Var ใน vars/standardMavenPipeline.groovy

L3: OOP Utility Class ใน src/com/company/devops/DockerHelper.groovy

05. Simulator Objective: ทดสอบการโหลด Shared Library ข้าม Scope และจำลองการส่ง Parameters สู่ vars DSL

Exam: 9 D10 + 6 Recall (D9 + D8 + D7)

DAY 11 Quality Assurance & Phase 2 Cap

Quality Gates & Enterprise Notifications

15 MCQs (Phase 2 Capstone)

ด่านตรวจคุณภาพก่อนถึงมือลูกค้า: การผูก SonarQube Quality Gate บล็อกการรีลีสเมื่อ Code Coverage ไม่ถึงเกณฑ์, การยิง Webhook แจ้งเตือนทีมผ่าน Slack/Teams แบบ Rich Card และการสรุปจบ Phase 2

01. Human Definition

Quality Gate คือด่านตรวจจับคุณภาพโค้ดอัตโนมัติ ถ้ามีช่องโหว่ความปลอดภัยหรือเขียนโค้ดไม่ผ่านเกณฑ์ ไปป์ไลน์จะหยุดทันที และระบบ Notification จะส่งข้อความสวยงามเข้ากลุ่มแชตของทีมเพื่อบอกว่าใครทำพังและต้องแก้อย่างไร

02. Everyday Mental Model

เครื่องสแกนโลหะและสัญญาณเตือนไฟไหม้: ผู้โดยสารต้องเดินผ่านเครื่องสแกน ถ้ามีโลหะอันตราย ประตูจะปิดล็อกไม่ให้ผ่าน และลำโพงจะประกาศเตือนเจ้าหน้าที่ทันที

Before vs After Comparison

ถ้าไม่มี: โค้ดมี Security Vulnerability หลุดไป Production ลูกค้าโดนแฮกข้อมูล | ถ้ามี: SonarQube สั่ง Fail ทันทีพร้อมแจ้งเตือนใน Slack ภายใน 10 วินาที

03. Production War Story

ทีมเขียนสคริปต์สแกน Sonar แต่ใช้คำสั่ง Polling ซ้ำๆ ทำให้เซิร์ฟเวอร์ Jenkins โดน Timeout ส่งผลให้ Release ที่ผ่านแล้วถูกตัดสินว่าล้มเหลว ทำให้การส่งมอบล่าช้าไป 14 ชั่วโมง

04. Hands-on Syntax Levels

L1: สั่งสแกนโค้ด withSonarQubeEnv('MySonarServer') { sh 'mvn sonar:sonar' }

L2: รอรับผลการตรวจด้วย Webhook waitForQualityGate()

L3: ยิง Slack Rich Card slackSend channel: '#alerts', color: 'danger', message: "..."

05. Simulator Objective: จำลองการประเมิน Sonar Quality Gate (Pass/Fail) และการสร้าง Slack Alert Payload

Phase 2 Cap Exam: 15 MCQs (Grand Intermediate)

Phase 2 Intermediate Track

พร้อมเริ่มต้น Day 06: Credentials Management แล้วหรือยัง?

เปิดประตูสู่ความปลอดภัยระดับองค์กร: จัดการความลับอย่างมืออาชีพ ป้องกันการรั่วไหลใน Log ด้วย `withCredentials` พร้อมชุดข้อสอบ Spaced Repetition ชุดแรกของ Phase 2

Review Phase 1 Day 06 กำลังจะมา