Production ใน CI/CD — คืออะไร ขั้นตอนและสภาพแวดล้อมในการพัฒนา

Production ใน CI/CD คืออะไร

โปรดักชันในบริบทของ CI/CD คือขั้นตอนสุดท้ายของวงจรชีวิตแอปพลิเคชัน ซึ่งโค้ดหลังจากผ่านทุกขั้นตอนของการ build และการทดสอบจะพร้อมใช้งานสำหรับ ผู้ใช้ปลายทาง ซึ่งแตกต่างจากสภาพแวดล้อมการพัฒนาและสเตจจิง สภาพแวดล้อมโปรดักชันทำงานกับข้อมูลและโหลดจริง ซึ่งกำหนดข้อกำหนดพิเศษด้านความน่าเชื่อถือและประสิทธิภาพ

บทบาทของสภาพแวดล้อมโปรดักชัน

สภาพแวดล้อมโปรดักชันไม่ใช่แค่เซิร์ฟเวอร์ แต่เป็น โครงสร้างพื้นฐานทั้งหมดที่รวมถึงตัวปรับสมดุลโหลด ฐานข้อมูล ชั้นแคช CDN และระบบตรวจสอบ แต่ละองค์ประกอบต้องทนทานต่อข้อผิดพลาดและปรับขนาดได้ ในการพัฒนามือถือ โปรดักชันยังรวมถึงบริการแบ็กเอนด์ เกตเวย์ API และโครงสร้างพื้นฐานพุชที่รองรับแอปพลิเคชันไคลเอนต์

ข้อกำหนดของสภาพแวดล้อมโปรดักชัน

สภาพแวดล้อมโปรดักชันต้องเป็นไปตามเกณฑ์ที่เข้มงวด: ความพร้อมใช้งาน 99.9% ขึ้นไป เวลาตอบสนองของ API ไม่เกิน 200 ms รองรับการกู้คืนจากภัยพิบัติ (RTO และ RPO ภายใน SLA) สำหรับแอปพลิเคชันมือถือ จำเป็นต้องมีการรายงานข้อขัดข้อง การวิเคราะห์การใช้งาน และแพลตฟอร์ม A/B สำหรับการทดลองเพิ่มเติม ไปป์ไลน์ CI/CD ช่วยให้มั่นใจว่าสอดคล้องกับข้อกำหนดเหล่านี้ผ่านการตรวจสอบอัตโนมัติก่อนการปรับใช้แต่ละครั้ง

ขั้นตอนการปรับใช้ในโปรดักชัน

การปรับใช้ในโปรดักชันเป็นกระบวนการหลายขั้นตอนที่ทำให้เป็นอัตโนมัติผ่าน ไปป์ไลน์ CI/CD แต่ละขั้นตอนรวมถึงการตรวจสอบที่ป้องกันไม่ให้โค้ดที่มีข้อบกพร่องไปถึงโปรดักชัน มาดูขั้นตอนสำคัญโดยใช้ตัวอย่างไปป์ไลน์ทั่วไปสำหรับแอปพลิเคชันมือถือ

ไปป์ไลน์ CI/CD สำหรับโปรดักชัน

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

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

ระบบอัตโนมัติในการปรับใช้

การปรับใช้อัตโนมัติในโปรดักชันใช้กลยุทธ์ การปรับใช้แบบไม่มีการหยุดทำงาน: การอัปเดตแบบโรลลิ่ง การปรับใช้แบบบลู-กรีน หรือการเผยแพร่แบบคานารี ด้วยการอัปเดตแบบโรลลิ่ง อินสแตนซ์แอปพลิเคชันใหม่จะค่อยๆ แทนที่อินสแตนซ์เก่าโดยไม่หยุดบริการ การปรับใช้แบบบลู-กรีนจะรักษาสภาพแวดล้อมที่เหมือนกันสองแห่งและสลับปริมาณการรับส่งข้อมูลทันที ทำให้สามารถย้อนกลับได้อย่างรวดเร็วหากเกิดปัญหา การเลือกกลยุทธ์ขึ้นอยู่กับความสำคัญของบริการและเวลาหยุดทำงานที่ยอมรับได้ สำหรับแอปพลิเคชันมือถือ การปรับใช้ในโปรดักชันรวมถึงการเผยแพร่ในร้านค้าแอป (App Store Connect, Google Play Console) ด้วยการเปิดตัวแบบเป็นระยะ ซึ่งต้องมีการรวม CI/CD เพิ่มเติมกับ API ของร้านค้าเพื่อทำให้กระบวนการเผยแพร่เป็นอัตโนมัติ รวมถึงการอัปโหลดไบนารี การกรอกข้อมูลเมตา และการส่งเพื่อตรวจสอบ

การตรวจสอบหลังการปรับใช้

หลังจากการปรับใช้ในโปรดักชันสำเร็จ ไปป์ไลน์ CI/CD จะเริ่มชุด การทดสอบควัน ที่ตรวจสอบฟังก์ชันการทำงานพื้นฐานของบริการ: ความพร้อมใช้งานของเอนด์พอยต์ ความถูกต้องของการตอบสนองของ API เวลาตอบสนองภายในขีดจำกัดปกติ สำหรับแอปพลิเคชันมือถือ จะมีการตรวจสอบความสามารถในการอนุญาต การซิงโครไนซ์ข้อมูล และการทำงานที่ถูกต้องของการรวมการชำระเงินเพิ่มเติม หากการทดสอบควันล้มเหลว ไปป์ไลน์จะเริ่มการย้อนกลับไปยังเวอร์ชันเสถียรก่อนหน้าโดยอัตโนมัติและส่งการแจ้งเตือนไปยังทีม การตรวจสอบหลังการปรับใช้จะดำเนินต่อไปเป็นเวลา 30-60 นาทีด้วยระดับการแจ้งเตือนที่สูงขึ้น — นี่คือช่วงเวลาในการตรวจจับปัญหาที่ไม่ครอบคลุมโดยการทดสอบอัตโนมัติ

ความแตกต่างระหว่างโปรดักชันและสภาพแวดล้อมทดสอบ

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

การกำหนดค่าและโครงสร้างพื้นฐาน

การกำหนดค่าสภาพแวดล้อมโปรดักชันต้อง แยกออก จากสภาพแวดล้อมอื่นอย่างเคร่งครัด ซึ่งใช้กับตัวแปรสภาพแวดล้อม สตริงการเชื่อมต่อฐานข้อมูล คีย์ API และใบรับรอง โครงสร้างพื้นฐานโปรดักชันมักจะถูกทำซ้ำในหลายโซนความพร้อมใช้งานเพื่อให้มั่นใจถึงความทนทานต่อข้อผิดพลาด สำหรับแอปพลิเคชันมือถือ โปรดักชันยังรวมถึงการกำหนดค่า Apple App Store และ Google Play ที่ไม่มีใน build ทดสอบ

การจัดการข้อมูล

ในโปรดักชัน ห้ามใช้ข้อมูลจริงสำหรับการทดสอบโดยเด็ดขาด — สภาพแวดล้อมสเตจจิงและการพัฒนามีไว้เพื่อจุดประสงค์นั้น การเปลี่ยนแปลงโครงสร้าง ฐานข้อมูล ทั้งหมดต้องผ่านการย้ายข้อมูลที่ไปป์ไลน์ CI/CD ใช้โดยอัตโนมัติ การสำรองข้อมูลโปรดักชันจะดำเนินการตามกำหนดการด้วยการตรวจสอบความสมบูรณ์อัตโนมัติ นโยบายการเก็บรักษากำหนดระยะเวลาการจัดเก็บข้อมูลสำรองตามข้อกำหนด GDPR และข้อบังคับอื่นๆ

การตรวจสอบโครงสร้างพื้นฐานโปรดักชัน

การตรวจสอบโปรดักชันเป็นกระบวนการต่อเนื่องในการรวบรวมและวิเคราะห์เมตริก บันทึก และร่องรอย หากไม่มีการตรวจสอบที่ครอบคลุม ก็เป็นไปไม่ได้ที่จะรับประกัน SLA และตรวจจับเหตุการณ์ได้ทันเวลา แนวทางการตรวจสอบสมัยใหม่มีพื้นฐานอยู่บนสามเสาหลัก: เมตริก (ตัวชี้วัดเชิงตัวเลข) บันทึก (บันทึกเหตุการณ์ที่มีโครงสร้าง) และร่องรอย (การติดตามคำขอ)

เมตริกสำคัญ

เมตริกสำคัญของสภาพแวดล้อมโปรดักชันรวมถึง: เวลาใช้งาน (ความพร้อมใช้งานของบริการ) ความหน่วง (เวลาหน่วงตอบสนอง) อัตราข้อผิดพลาด (เปอร์เซ็นต์ของข้อผิดพลาด) ปริมาณงาน (แบนด์วิดท์) และความอิ่มตัว (ระดับโหลดของทรัพยากร) สำหรับแอปพลิเคชันมือถือ เมตริกเวลาเริ่มต้น อัตราที่ไม่มีข้อขัดข้อง และเวลาซิงโครไนซ์ข้อมูลมีความสำคัญ การแจ้งเตือนถูกกำหนดค่าตาม SLO (วัตถุประสงค์ระดับบริการ) เพื่อให้ทีมได้รับการแจ้งเตือนก่อนที่จะมีการละเมิด SLA

เครื่องมือตรวจสอบ

แพลตฟอร์มเฉพาะทางใช้สำหรับการตรวจสอบโครงสร้างพื้นฐานโปรดักชัน: Datadog, New Relic, Grafana + Prometheus สำหรับการรวบรวมเมตริก, Sentry และ Crashlytics สำหรับติดตามข้อผิดพลาดในแอปพลิเคชันมือถือ บันทึกจะถูกรวมศูนย์ผ่านสแต็ก ELK (Elasticsearch, Logstash, Kibana) หรือ Splunk การติดตามคำขอจะดำเนินการโดยใช้ Jaeger หรือ Zipkin เครื่องมือทั้งหมดถูกรวมเข้ากับไปป์ไลน์ CI/CD สำหรับการสร้างแดชบอร์ดอัตโนมัติเมื่อปรับใช้บริการใหม่ ระบบตอบสนองต่อเหตุการณ์ (PagerDuty, Opsgenie) รับการแจ้งเตือนจากเครื่องมือตรวจสอบทั้งหมดและกำหนดผู้รับผิดชอบประจำการโดยอัตโนมัติตามกฎการหมุนเวียนและการยกระดับ คู่มือการดำเนินงานสำหรับเหตุการณ์แต่ละประเภทจะถูกเก็บไว้ในพื้นที่เก็บข้อมูลและมีเวอร์ชันพร้อมกับโค้ด ซึ่งช่วยให้มั่นใจถึงความเกี่ยวข้องของคำแนะนำในการกู้คืน

ความปลอดภัยของสภาพแวดล้อมโปรดักชัน

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

การเข้าถึงและบทบาท

การเข้าถึงสภาพแวดล้อมโปรดักชันถูกจำกัดอย่างเข้มงวดตามหลักการสิทธิพิเศษน้อยที่สุด นักพัฒนาไม่สามารถเข้าถึงเซิร์ฟเวอร์โปรดักชันโดยตรง — การเปลี่ยนแปลงทั้งหมดผ่าน ไปป์ไลน์ CI/CD ด้วยกลไกการอนุมัติ สำหรับการเข้าถึงฉุกเฉิน จะใช้ข้อมูลประจำตัวชั่วคราวที่มีการหมุนเวียนอัตโนมัติและการบันทึกการดำเนินการอย่างสมบูรณ์ หลักการสี่ตา (การดำเนินการใดๆ ต้องได้รับการอนุมัติจากสองคน) เป็นมาตรฐานสำหรับการดำเนินการในโปรดักชัน

การตรวจสอบการเปลี่ยนแปลง

ทุกการเปลี่ยนแปลงในโปรดักชันจะถูกบันทึกใน ระบบตรวจสอบ: ใครเป็นผู้เริ่มปรับใช้ คอมมิตใดถูกปรับใช้ การตรวจสอบใดผ่านไปแล้ว การปรับใช้ใช้เวลาเท่าใด การรวม CI/CD กับระบบการจัดการเหตุการณ์ (PagerDuty, Opsgenie) ช่วยให้สามารถสร้างตั๋วอัตโนมัติเมื่อการปรับใช้ล้มเหลวหรือมีการละเมิด SLO บันทึกโปรดักชันทั้งหมดจะถูกเก็บไว้ในพื้นที่เก็บข้อมูลที่ไม่สามารถเปลี่ยนแปลงได้โดยมีการเก็บรักษาอย่างน้อย 90 วันตามข้อกำหนด SOC2 และ ISO 27001