CI/CD with GitHub Actions & DevOps Pipelines · บทเรียน

การนำไปใช้งานจริงด้วยด่านอนุมัติ

เรียนรู้การเลื่อนบิลด์จากสภาพแวดล้อมเตรียมใช้งานไปยังสภาพแวดล้อมจริงอย่างปลอดภัย โดยใช้กฎคุ้มครองสภาพแวดล้อมของ GitHub Actions การอนุมัติด้วยตนเอง และด่านการนำไปใช้งาน

บทเรียน 4 จาก 413 ขั้นตอน

การนำไปใช้งานจริงด้วยด่านอนุมัติ เป็นบทเรียน CI/CD with GitHub Actions & DevOps Pipelines ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน CI/CD with GitHub Actions & DevOps Pipelines และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส CI/CD with GitHub Actions & DevOps Pipelines มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดการใช้งานจริงจึงต้องมีด่านตรวจสอบ

การปรับใช้อย่างต่อเนื่องจะส่งโค้ดออกไปโดยอัตโนมัติ แต่การส่งตรงไปยังการใช้งานจริงโดยไม่มีจุดตรวจสอบใด ๆ มีความเสี่ยง รุ่นเผยแพร่ที่มีปัญหาอาจส่งผลกระทบต่อผู้ใช้ทุกคนได้ทันที

ด่านอนุมัติคือการหยุดชั่วคราวโดยเจตนา ซึ่งมนุษย์หรือการตรวจสอบอัตโนมัติจะยืนยันว่าควรดำเนินการปรับใช้ต่อ

  • ลดขอบเขตผลกระทบจากข้อผิดพลาด
  • สร้างประวัติการตรวจสอบว่าใครอนุมัติสิ่งใด
  • ช่วยแยกระดับความเชื่อมั่นระหว่าง staging กับ production

สภาพแวดล้อมของ GitHub

ระบบการทำงานของ GitHub มีฟีเจอร์ที่เรียกว่า สภาพแวดล้อม สภาพแวดล้อม เช่น production สามารถเก็บข้อมูลลับ ตัวแปร และ กฎการป้องกัน ของตนเองได้

คุณอ้างอิงสภาพแวดล้อมจากงานโดยใช้คีย์ environment ซึ่งเป็นพื้นฐานสำหรับเพิ่มด่านอนุมัติ

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: echo 'Deploying to production'

ผู้ตรวจสอบที่จำเป็น

ในการตั้งค่าของที่เก็บข้อมูล ภายใต้ การตั้งค่า > สภาพแวดล้อม > production คุณสามารถเปิดใช้ ผู้ตรวจสอบที่จำเป็นได้

เมื่องานกำหนดเป้าหมายไปยังสภาพแวดล้อมนั้น การทำงานของกระบวนการทำงานจะหยุดรอจนกว่าผู้ตรวจสอบที่อยู่ในรายการจะคลิก Approve

  • กำหนดผู้ตรวจสอบได้สูงสุด 6 คน
  • โดยค่าเริ่มต้น การอนุมัติเพียงคนเดียวจะปลดล็อกงาน
  • ผู้อนุมัติอาจต้องไม่ใช่ผู้ที่เรียกใช้การทำงาน ทั้งนี้ขึ้นอยู่กับการตั้งค่า

กระบวนการทำงานที่มีด่านครบถ้วน

ในที่นี้ งาน build จะทำงานก่อน จากนั้นงาน deploy จะขึ้นต่อกับงานดังกล่าวผ่าน needs และกำหนดเป้าหมายไปยังสภาพแวดล้อม production ที่มีการป้องกัน

การปรับใช้จะไม่เริ่มจนกว่าผู้ตรวจสอบที่จำเป็นจะอนุมัติในส่วนติดต่อผู้ใช้ของการทำงาน

name: Deploy
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'build artifact'
  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.example.com
    steps:
      - run: echo 'deploy to prod'

ตัวจับเวลารอ

นอกจากผู้ตรวจสอบแล้ว สภาพแวดล้อมยังรองรับตัวจับเวลารอ ซึ่งบังคับให้รอได้สูงสุด 30 วันก่อนดำเนินการปรับใช้ต่อ

ตัวจับเวลารอระยะสั้นมีประโยชน์ในฐานะช่วงพักเพื่อความปลอดภัย เพราะเปิดโอกาสให้ทีมยกเลิกการทำงานก่อนที่การปรับใช้จะไปถึงการใช้งานจริง

ข้อจำกัดสาขาสำหรับการปรับใช้

สภาพแวดล้อมสามารถจำกัดสาขาที่อนุญาตให้ปรับใช้ได้ สำหรับ production โดยทั่วไปจะอนุญาตเฉพาะ main หรือแท็กเผยแพร่

วิธีนี้ป้องกันการปรับใช้ไปยังการใช้งานจริงโดยไม่ตั้งใจจากสาขาฟีเจอร์

  • สาขาที่มีการป้องกัน — เฉพาะสาขาที่มีกฎการป้องกัน
  • สาขาที่เลือกไว้ — รายการสาขาหรือรูปแบบแท็กที่อนุญาตอย่างชัดเจน

ข้อมูลลับตามขอบเขตสภาพแวดล้อม

แต่ละสภาพแวดล้อมมีข้อมูลลับของตนเอง สภาพแวดล้อม production สามารถเก็บ PROD_DB_URL ขณะที่ staging เก็บ STAGING_DB_URL

ข้อมูลลับที่กำหนดในสภาพแวดล้อมจะพร้อมใช้เฉพาะกับงานที่กำหนดเป้าหมายไปยังสภาพแวดล้อมนั้น เพิ่มการแยกส่วนอีกชั้นหนึ่ง

    steps:
      - name: Deploy
        env:
          DB_URL: ${{ secrets.PROD_DB_URL }}
        run: ./deploy.sh

การติดตามสถานะการปรับใช้

การตั้งค่า url ให้กับสภาพแวดล้อมจะเพิ่มลิงก์ที่คลิกได้ไปยังการปรับใช้ในส่วนติดต่อผู้ใช้ของ GitHub และบันทึกวัตถุการปรับใช้ผ่านส่วนติดต่อการเขียนโปรแกรมสำหรับการปรับใช้

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

    environment:
      name: production
      url: https://myapp.example.com

การอนุมัติการทำงานที่รอดำเนินการ

เมื่องานที่มีด่านตรวจสอบกำลังรอ คุณจะเห็นแบนเนอร์สีเหลือง ตรวจสอบการปรับใช้บนหน้าการทำงานของกระบวนการทำงาน

  • เปิดการทำงานในแท็บ การทำงาน
  • คลิก Review deployments
  • เลือกสภาพแวดล้อม แล้วคลิก Approve and deploy หรือ Reject

คุณสามารถเพิ่มความคิดเห็นเพื่ออธิบายการตัดสินใจได้ด้วย

การรวมด่านตรวจสอบหลายด่าน

ด่านตรวจสอบสำหรับการใช้งานจริงที่รัดกุมที่สุดจะรวมกฎหลายข้อเข้าด้วยกัน:

  • ผู้ตรวจสอบที่จำเป็น (การอนุมัติโดยมนุษย์)
  • ตัวจับเวลารอ (ช่วงพัก)
  • ข้อจำกัดสาขา (เฉพาะ main)
  • ข้อมูลลับของสภาพแวดล้อม (การแยกส่วน)

การวางด่านเหล่านี้ซ้อนกันจะสร้างกระบวนการเลื่อนรุ่นที่รัดกุมจากสภาพแวดล้อมทดสอบก่อนเผยแพร่ไปยังการใช้งานจริง

การข้ามด่านตรวจสอบอย่างปลอดภัย

บางครั้งคุณจำเป็นต้องแก้ไขเร่งด่วนในกรณีฉุกเฉิน แทนที่จะลบกฎการป้องกัน ให้พิจารณาใช้กระบวนการทำงานแก้ไขเร่งด่วนแยกต่างหากที่มีขอบเขตแคบ พร้อมการบันทึกการทำงานของตนเองและผู้ตรวจสอบที่เข้มงวดยิ่งขึ้น

อย่าปิดใช้ด่านตรวจสอบอย่างถาวรเพื่อความสะดวก เพราะจะทำลายจุดประสงค์ของกลไกความปลอดภัย

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจของคุณเกี่ยวกับด่านอนุมัติสำหรับการใช้งานจริง

ทบทวน

คุณได้เรียนรู้วิธีเพิ่มด่านอนุมัติสำหรับการปรับใช้ไปยังการใช้งานจริงโดยใช้สภาพแวดล้อมของ GitHub

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

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

เริ่มต้นได้ฟรี

เรียนรู้ CI/CD with GitHub Actions & DevOps Pipelines ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
12
บทเรียน
48

คำถามที่พบบ่อย

บทเรียน “การนำไปใช้งานจริงด้วยด่านอนุมัติ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การนำไปใช้งานจริงด้วยด่านอนุมัติ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส CI/CD with GitHub Actions & DevOps Pipelines ให้อัปเกรดเป็น CoddyKit PRO คอร์ส CI/CD with GitHub Actions & DevOps Pipelines มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การนำไปใช้งานจริงด้วยด่านอนุมัติ”

เรียนรู้การเลื่อนบิลด์จากสภาพแวดล้อมเตรียมใช้งานไปยังสภาพแวดล้อมจริงอย่างปลอดภัย โดยใช้กฎคุ้มครองสภาพแวดล้อมของ GitHub Actions การอนุมัติด้วยตนเอง และด่านการนำไปใช้งาน คุณปฏิบัติ CI/CD with GitHub Actions & DevOps Pipelines ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน CI/CD with GitHub Actions & DevOps Pipelines หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน CI/CD with GitHub Actions & DevOps Pipelines บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การนำไปใช้งานจริงด้วยด่านอนุมัติ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน CI/CD with GitHub Actions & DevOps Pipelines นี้ได้ไหม

ได้ บทเรียน CI/CD with GitHub Actions & DevOps Pipelines ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. บทนำสู่การนำส่งอย่างต่อเนื่อง
  2. การนำไปใช้ในสภาพแวดล้อมทดสอบก่อนผลิต
  3. ตัวแปรสภาพแวดล้อมและข้อมูลลับ
  4. การนำไปใช้งานจริงด้วยด่านอนุมัติ
← กลับไปที่ CI/CD with GitHub Actions & DevOps Pipelines