Continuous Delivery (CD): คืออะไร แตกต่างจาก Continuous Deployment อย่างไร

Continuous Delivery คืออะไร

Continuous Delivery (CD) เป็นส่วนขยายของ Continuous Integration ที่เพิ่มระบบอัตโนมัติสำหรับทุกขั้นตอนการเตรียมรุ่น: การสร้างบิลด์สำหรับเผยแพร่ การลงนามด้วยใบรับรอง การทำให้สับสน การตรวจสอบเมตาดาต้าของร้านค้าแอป และการปรับใช้ในสภาพแวดล้อม staging คำศัพท์นี้ถูกนำเสนอโดย Jez Humble และ David Farley ในหนังสือ “Continuous Delivery” (2010) ซึ่งพวกเขาได้ทำให้แนวปฏิบัติที่เป็นทางการซึ่งช่วยให้ทีมสามารถทำให้การเผยแพร่สามารถคาดการณ์ได้และมีความเสี่ยงต่ำ

วิวัฒนาการของการส่งมอบซอฟต์แวร์

ก่อนการนำ CD มาใช้ การเผยแพร่เป็นเหตุการณ์หนึ่ง: ทีมงานรวมตัวกันในห้อง ดำเนินการตามรายการตรวจสอบ 20 ข้อ เรียกใช้สคริปต์ด้วยตนเอง และหวังว่าจะไม่มีอะไรพัง Continuous Delivery เปลี่ยนการเผยแพร่จากเหตุการณ์เป็นกระบวนการ: การเปลี่ยนแปลงโค้ดเล็กน้อยสามารถส่งถึงผู้ใช้ได้ภายในไม่กี่นาที ไม่ใช่เป็นสัปดาห์ Amazon, Netflix และ Etsy เป็นกลุ่มแรกที่นำ CD มาใช้ในปี 2010 — ปัจจุบันนี้เป็นมาตรฐานสำหรับทีมผลิตภัณฑ์

คุณค่าทางธุรกิจของ CD

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

CD เทียบกับ CI เทียบกับ Continuous Deployment

คำศัพท์ CI, CD และ Continuous Deployment มักสับสน แต่มีขอบเขตที่ชัดเจนระหว่างคำเหล่านี้ การเข้าใจความแตกต่างช่วยออกแบบไปป์ไลน์อย่างถูกต้องและเลือกระดับของระบบอัตโนมัติที่สอดคล้องกับวุฒิภาวะของทีมและข้อกำหนดทางธุรกิจ

Continuous Integration

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

Continuous Delivery

CD เพิ่มขั้นตอนให้กับ CI ได้แก่ การสร้างบิลด์สำหรับเผยแพร่ การตรวจสอบเมตาดาต้า การลงนาม และการปรับใช้ใน staging หรือร้านค้าแอปสำหรับการทดสอบเบตา ความแตกต่างที่สำคัญ — การตัดสินใจเผยแพร่สู่ระบบผลิตกระทำโดยบุคคล (ผู้จัดการ เจ้าของผลิตภัณฑ์) CD ทำให้การเผยแพร่ “อยู่ห่างเพียงคลิกเดียว” — ง่ายและปลอดภัย

Continuous Deployment

Continuous Deployment คือระบบอัตโนมัติเต็มรูปแบบ: ทุกการเปลี่ยนแปลงที่ผ่านทุกขั้นตอนของไปป์ไลน์ CD จะถูกส่งไปยังระบบผลิตโดยอัตโนมัติ โดยไม่ต้องอนุมัติด้วยตนเอง Continuous Deployment ใช้ได้กับผลิตภัณฑ์ SaaS และบริการเว็บ แต่ไม่ค่อยได้ใช้ในการพัฒนาแอปมือถือเนื่องจากนโยบายของร้านค้าแอป (App Store Review, Google Play Review ต้องส่งด้วยตนเอง)

Continuous Delivery สำหรับแอปพลิเคชันมือถือ

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

การเตรียมพร้อมสำหรับการเผยแพร่บน Google Play

ไปป์ไลน์ CD ของ Android รวมถึง: การสร้าง AAB (Android App Bundle) การลงนามด้วยคีย์สำหรับเผยแพร่ การทำให้สับสนผ่าน R8/ProGuard การตรวจสอบขนาด APK และคลาส multidex การสร้างบันทึกการเผยแพร่ การใช้ product flavors ของ Gradle (free/paid, dev/staging/prod) ช่วยให้จัดการการกำหนดค่าหลายแบบจากไปป์ไลน์เดียว

การเตรียมพร้อมสำหรับการเผยแพร่บน App Store

CD สำหรับ iOS ต้องมีการลงนามด้วยใบรับรองผ่าน Fastlane match การตรวจสอบความสอดคล้องของไอคอน (ข้อกำหนดของ App Store — 1024×1024 px) การตรวจสอบความถูกต้องของเมตาดาต้า (ชื่อ คำอธิบาย คำสำคัญ) การตรวจสอบว่าไม่มี API ส่วนตัว การตรวจสอบทางเทคนิคดำเนินการผ่าน altool --validate-app โดยไม่ต้องอัปโหลดไปยัง App Store Connect ซึ่งให้ข้อเสนอแนะที่รวดเร็ว

# Fastfile — ไปป์ไลน์ CD ที่สมบูรณ์สำหรับ iOS และ Android
platform :ios do
  desc "iOS CD — การเตรียมการเผยแพร่และอัปโหลดไปยัง TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — การสร้าง AAB และอัปโหลดไปยัง Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight รวบรวมภาพหน้าจอ รับใบรับรองผ่าน match สร้าง IPA และอัปโหลดไปยัง TestFlight เลน deliver_to_internal สำหรับ Android สร้าง Release AAB ผ่าน Gradle และอัปโหลดไปยังแทร็กภายในของ Google Play Console ไปป์ไลน์ทั้งสองทำงานจาก CI หลังจากผ่านการทดสอบ

ส่วนประกอบของไปป์ไลน์ CD

ไปป์ไลน์ CD ประกอบด้วยขั้นตอนต่อเนื่องกัน แต่ละขั้นตอนเพิ่มความมั่นใจว่าการเผยแพร่พร้อมสำหรับผู้ใช้ ขั้นตอนแบ่งเป็นทางเทคนิค (สร้าง ลงนาม) และทางผลิตภัณฑ์ (เมตาดาต้า ภาพหน้าจอ การตรวจสอบคำอธิบาย) การข้ามขั้นตอนใดๆ จะเพิ่มความเสี่ยงที่ร้านค้าแอปจะปฏิเสธการเผยแพร่

การจัดการเวอร์ชัน

ส่วนประกอบที่สำคัญของ CD คือการจัดการเวอร์ชันอัตโนมัติ การเพิ่มเวอร์ชัน (versionCode และ versionName สำหรับ Android, CFBundleVersion และ CFBundleShortVersionString สำหรับ iOS) ดำเนินการตามแท็ก Git หรือเวอร์ชันก่อนหน้าในร้านค้า Fastlane increment_version_number และคำสั่ง Gradle (versionCode auto-increment) ทำให้ขั้นตอนนี้เป็นอัตโนมัติ

เมตาดาต้าของร้านค้า

Google Play Console และ App Store Connect ต้องการ: คำอธิบายแอป คำสำคัญ หมวดหมู่ การให้คะแนน ลิงก์นโยบายความเป็นส่วนตัว CD รวมถึง การตรวจสอบการมีอยู่และความถูกต้องของเมตาดาต้า Fastlane deliver และ supply ทำให้การอัปโหลดคำอธิบาย ภาพหน้าจอ และไอคอนพร้อมกับบิลด์เป็นอัตโนมัติ

การตรวจสอบเกต

ก่อนส่งตรวจสอบ ไปป์ไลน์จะดำเนินการตรวจสอบเกต: การตรวจสอบขนาดบิลด์ (APK > 200 MB ถูกปฏิเสธโดย Google Play) การมีอยู่ของการแปลภาษาทั้งหมด การไม่มีสัญลักษณ์ดีบัก ในบิลด์สำหรับเผยแพร่ การตรวจสอบไฟล์แมปปิ้ง ProGuard สำหรับถอดรหัสบันทึกการขัดข้อง หากการตรวจสอบใดล้มเหลว — ไปป์ไลน์จะบล็อกการเผยแพร่

การทดสอบอัตโนมัติสำหรับ CD

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

การทดสอบหน่วย

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

การทดสอบการรวมระบบ

ตรวจสอบการทำงานร่วมกันของส่วนประกอบ: ชั้นเครือข่ายกับ API จริง (หรือเซิร์ฟเวอร์จำลอง) ฐานข้อมูล ระบบไฟล์ การทดสอบ Room DAO สำหรับ Android การทดสอบ Core Data สำหรับ iOS เป็นตัวอย่างของการทดสอบการรวมระบบ การทดสอบเหล่านี้ช้ากว่าการทดสอบหน่วย (1–5 นาที) และดำเนินการในขั้นตอน CD ไม่ใช่ CI ในทุก commit

การทดสอบ UI และภาพหน้าจอ

การทดสอบภาพหน้าจอ (snapshot testing) เปรียบเทียบหน้าจอแอปกับภาพอ้างอิง หากการเปลี่ยนแปลงโค้ดเปลี่ยน UI — การทดสอบล้มเหลว และนักพัฒนาตรวจสอบว่าการเปลี่ยนแปลงนั้นคาดหวังหรือไม่ Android รองรับ Roborazzi และ Paparazzi, iOS — SnapshotTesting โดย Point-Free การทดสอบภาพหน้าจอดำเนินการก่อนการเผยแพร่ซึ่งเป็นส่วนหนึ่งของไปป์ไลน์ CD

แนวปฏิบัติที่ดีที่สุดของ Continuous Delivery

การนำ Continuous Delivery ไปใช้ไม่เพียงต้องการเครื่องมือ แต่ยังต้องการการเปลี่ยนแปลงในวัฒนธรรมของทีม แนวปฏิบัติด้านล่างนี้อิงจากประสบการณ์หลายปีของทีมมือถือจาก Google, Spotify และ Uber และปรับให้เหมาะกับโครงการทุกขนาด

Feature Flags

โค้ดของฟีเจอร์ใหม่ถูกส่งไปยังระบบผลิตแต่ซ่อนอยู่หลังแฟล็ก Feature flags อนุญาตให้ปรับใช้โค้ดก่อนที่ฟีเจอร์จะพร้อมสำหรับผู้ใช้และปิดใช้งานทันทีเมื่อเกิดปัญหา ไลบรารี: LaunchDarkly, Firebase Remote Config, Unleash Feature flags เป็นข้อกำหนดบังคับสำหรับ CD ในโครงการมือถือ

สภาพแวดล้อม staging

ก่อนส่งไปยังระบบผลิต บิลด์จะถูกปรับใช้ใน staging — สภาพแวดล้อมที่เหมือนกับระบบผลิตแต่มีข้อมูลทดสอบ วิศวกร QA ตรวจสอบฟีเจอร์บนบิลด์ staging ที่ติดตั้งผ่าน TestFlight หรือแทร็ก Internal Testing หาก staging ผ่าน — บิลด์ได้รับการอนุมัติให้ส่งตรวจสอบที่ร้านค้า

บันทึกการเผยแพร่และ changelog

CD สร้างบันทึกการเผยแพร่โดยอัตโนมัติตามข้อความ commit Conventional Commits (feat:, fix:, chore:) และแท็ก Git ในรูปแบบ semantic versioning ช่วยให้สามารถแยกวิเคราะห์ประวัติการเปลี่ยนแปลงได้ Fastlane changelog_from_git_commits รวบรวมการเปลี่ยนแปลงระหว่างสองแท็กสุดท้ายและจัดรูปแบบสำหรับร้านค้าแอป

การตรวจสอบหลังการเผยแพร่

CD ไม่สิ้นสุดด้วยการเผยแพร่ — หลังจากการเผยแพร่ การตรวจสอบจะเริ่มต้น: อัตราการขัดข้อง อัตรา ANR สำหรับ Android เวลาเริ่มต้น อัตราความล้มเหลวในการชำระเงิน หากเมตริกเกินขีดจำกัดปกติ — ไปป์ไลน์ CD ควรย้อนกลับการเผยแพร่โดยอัตโนมัติหรือแจ้งทีม เครื่องมือ: Firebase Crashlytics, Sentry, New Relic

// ตัวอย่าง Feature Flag ด้วย Firebase Remote Config สำหรับ CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// การใช้งานในโค้ด
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}