GitHub Actions — คืออะไร, ไพพ์ไลน์ CI/CD และระบบอัตโนมัติ

GitHub Actions คืออะไร?

GitHub Actions เป็นแพลตฟอร์มสำหรับทำให้เวิร์กโฟลว์เป็นอัตโนมัติที่สร้างไว้ใน GitHub และเปิดตัวในปี 2019 ช่วยให้คุณกำหนดไพพ์ไลน์ CI/CD ในไฟล์ YAML ที่เก็บไว้โดยตรงในพื้นที่เก็บข้อมูล แต่ละเวิร์กโฟลว์จะถูกกระตุ้นโดยอีเวนต์: push, pull request, การสร้างแท็ก หรือตามกำหนดเวลา แตกต่างจาก Jenkins หรือ TeamCity ไม่จำเป็นต้องมีโครงสร้างพื้นฐานแยกต่างหากเพื่อโฮสต์เซิร์ฟเวอร์ CI

ในบริบทของการพัฒนาแอปมือถือ GitHub Actions จะทำให้การสร้าง APK และ IPA การรัน unit test และ UI test บนอีมูเลเตอร์ การตรวจสอบโค้ดด้วย linter การลงนาม และการเผยแพร่ไปยัง Google Play และ App Store เป็นอัตโนมัติ แพลตฟอร์มให้เวลาฟรี สำหรับพื้นที่เก็บข้อมูลสาธารณะและสำหรับส่วนตัวตามแผนราคา สำหรับโปรเจกต์มือถือโอเพนซอร์ส นี่เป็นโซลูชัน CI/CD ที่สมบูรณ์โดยไม่มีค่าใช้จ่าย

สถาปัตยกรรม GitHub Actions: Workflows, Jobs และ Steps

สถาปัตยกรรมของ GitHub Actions ประกอบด้วยสี่ระดับ Workflow คือไฟล์ YAML หลักที่กำหนดระบบอัตโนมัติ Workflow ประกอบด้วย Jobs แต่ละ Job จะทำงานบน Runner แยกต่างหาก ภายใน Job จะดำเนินการ Steps — คำสั่งตามลำดับหรือการกระทำภายนอก Events กำหนดตัวกระตุ้น: push, pull_request, schedule, workflow_dispatch เวิร์กโฟลว์สามารถถูกกระตุ้นด้วยตนเองผ่านแท็บ Actions ในอินเทอร์เฟซของ GitHub

GitHub มี runners ที่โฮสต์พร้อมระบบปฏิบัติการที่ติดตั้งไว้ล่วงหน้า: Ubuntu, macOS และ Windows สำหรับการสร้าง iOS จำเป็นต้องใช้ macOS-runner สำหรับ Android — Linux หรือ macOS Self-hosted runners ช่วยให้คุณทำงานบนเซิร์ฟเวอร์ของคุณเองด้วยสภาพแวดล้อมที่กำหนดเอง ซึ่งมีประโยชน์สำหรับโปรเจกต์ขนาดใหญ่ที่มีข้อกำหนดฮาร์ดแวร์พิเศษ GitHub ยังรองรับกลุ่ม self-hosted runner สำหรับจัดคิวการทำงานของ jobs

โครงสร้างไฟล์ workflow

ไฟล์ workflow พื้นฐานประกอบด้วยส่วนต่างๆ: name, on (ตัวกระตุ้น), jobs แต่ละ job ระบุ runs-on (ประเภท runner), strategy (เมทริกซ์), steps (รายการการกระทำ) Steps สามารถเป็นคำสั่ง shell หรือการกระทำสำเร็จรูปจากตลาด ซึ่งเชื่อมต่อผ่านไวยากรณ์ owner/repo@version

การสร้างแอปพลิเคชันมือถือใน GitHub Actions

สำหรับการสร้าง Android เวิร์กโฟลว์มักประกอบด้วยขั้นตอน: checkout พื้นที่เก็บข้อมูล, การติดตั้ง JDK, การกำหนดค่าแคช Gradle, การรัน assembleRelease สำหรับ iOS จำเป็นต้องมี macOS-runner, การติดตั้ง Xcode ผ่าน xcode-select, การแก้ไข provisioning profile และการรัน xcodebuild ความซับซ้อนของการสร้าง iOS อยู่ที่การลงนามโค้ดและการจัดการใบรับรอง การตั้งค่าเฉพาะของ Apple รวมถึงการจัดการ provisioning profile ผ่าน apple-actions/import-codesign-certs

Matrix strategy ช่วยให้รันการสร้างบนหลายรุ่นพร้อมกัน ตัวอย่างเช่น: เมทริกซ์กับรุ่น iOS (15.0, 16.0, 17.0) และ Xcode (14, 15) สิ่งนี้ช่วยเร่งการตรวจสอบความเข้ากันได้ของแอปกับระบบปฏิบัติการรุ่นต่างๆ แม้ว่าจะเพิ่มการใช้นาทีของ runners สำหรับโปรเจกต์ที่มีงบประมาณ CI จำกัด สามารถจำกัดเมทริกซ์ให้เฉพาะการกำหนดค่าหลักเท่านั้น

การตั้งค่าสภาพแวดล้อมสำหรับ Android

GitHub Actions มี action setup-java สำหรับการติดตั้ง JDK และ caching สำหรับการแคช Gradle Android SDK ติดตั้งไว้ล่วงหน้าบน Ubuntu runners แล้ว สำหรับระดับ API ที่กำหนดเอง จะใช้ sdkmanager ในขั้นตอนแยกต่างหาก ขอแนะนำให้สร้าง workflows แยกต่างหากสำหรับการสร้าง Android และ iOS เนื่องจากใช้ runners และเครื่องมือสร้างที่แตกต่างกัน

GitHub Marketplace และการกระทำสำเร็จรูป

GitHub Marketplace มีการกระทำมากกว่า 15,000 รายการที่สร้างโดยชุมชนและนักพัฒนาอย่างเป็นทางการ สำหรับการพัฒนาแอปมือถือ หมวดหมู่หลักประกอบด้วย: การลงนามโค้ด (apple-actions/import-codesign-certs), การทดสอบ (react-native-community/action), การปรับใช้ (google-github-actions/release-google-play), การแจ้งเตือน (slackapi/slack-github-action) นอกจากนี้ยังมีการกระทำสำหรับ Firebase App Distribution, การอัปโหลด TestFlight และ Fastlane แต่ละการกระทำมีป้ายกำกับความเข้ากันได้กับระบบปฏิบัติการ runner ที่เฉพาะเจาะจง

แต่ละการกระทำมีรุ่น คำอธิบาย README และใบอนุญาต เมื่อเลือกการกระทำ ควรเลือกการกระทำที่เป็นทางการจากผู้ขาย (Google, Apple, Microsoft) และที่ผ่านการตรวจสอบผ่าน Verified Badge สิ่งสำคัญคือต้องระบุรุ่นหลักที่ตายตัว (actions/checkout@v4) ไม่ใช่ @main เพื่อหลีกเลี่ยงการเปลี่ยนแปลงที่ไม่คาดคิด หากการกระทำที่ต้องการไม่มีใน Marketplace คุณสามารถสร้างการกระทำที่กำหนดเอง — ในพื้นที่เก็บข้อมูล (Docker action หรือ JavaScript action) หรือเผยแพร่ใน Marketplace

การกระทำยอดนิยมสำหรับ CI/CD มือถือ

• actions/checkout — โคลนพื้นที่เก็บข้อมูลไปยัง runner
• actions/setup-java — ติดตั้ง JDK สำหรับการสร้าง Android
• gradle/actions/setup-gradle — กำหนดค่าและแคช Gradle
• apple-actions/import-codesign-certs — นำเข้าใบรับรองสำหรับ iOS
• google-github-actions/submit-release — เผยแพร่ใน Google Play Console

ตัวอย่าง workflow สำหรับโปรเจกต์ iOS

เมื่อพัฒนาแอปพลิเคชัน iOS สิ่งสำคัญคือต้องตั้งค่าการทำงานที่ถูกต้องกับซิมูเลเตอร์และอุปกรณ์ macOS-14 runner มีสภาพแวดล้อมพร้อม Rosetta 2 สำหรับรันการสร้าง Intel บนสถาปัตยกรรม ARM เวิร์กโฟลว์สามารถมีแผนการสร้างหลายแบบ — Debug สำหรับ pull request และ Release สำหรับแท็ก GitHub Actions รองรับการแยกวิเคราะห์ xcresult ผ่าน action xcparse/sonarqube สำหรับแสดงผลการทดสอบ หากต้องการส่งการแจ้งเตือนสถานะการสร้าง สามารถเพิ่ม Slack หรือ Telegram action ได้

การลงนามโค้ดสำหรับ iOS ต้องนำเข้าใบรับรองและ provisioning profiles Apple-actions มีขั้นตอนสำหรับนำเข้าใบรับรอง P12 และติดตั้ง provisioning profile ใบรับรองจะถูกเก็บเป็น secrets ของ GitHub Actions และจะถูกถอดรหัสเฉพาะในขั้นตอนการสร้างเท่านั้น สำหรับการลงนามอัตโนมัติ จะใช้ Fastlane match ซึ่งสามารถเรียกเป็นขั้นตอนแยกต่างหากในเวิร์กโฟลว์

ลองพิจารณาเวิร์กโฟลว์สำหรับแอป iOS ใน Swift ที่สร้างโปรเจกต์ รันทดสอบ และสร้างงานสร้างที่เก็บถาวร เวิร์กโฟลว์ใช้ macOS-14 runner, Xcode 15.4 และการกระทำสำหรับการจัดการใบรับรอง

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

การแคช dependencies ใน GitHub Actions

การแคชช่วยลดเวลาการสร้างโดยเก็บ dependencies ระหว่างการรันเวิร์กโฟลว์ GitHub มีการแคชในตัวผ่าน actions/cache สำหรับ Gradle จะแคช ~/.gradle, สำหรับ CocoaPods — Pods/, สำหรับ SPM — .build/ คีย์แคชประกอบด้วยแฮชของไฟล์รายการ dependencies — เมื่อ dependencies เปลี่ยนแปลง แคชจะถูกทำให้ใช้ไม่ได้โดยอัตโนมัติ

ควรให้ความสนใจเป็นพิเศษกับกลยุทธ์การกู้คืนแคช (restore-keys) หากไม่พบคีย์ที่แน่นอน GitHub Actions จะพยายามจับคู่บางส่วนผ่าน restore-keys สิ่งนี้มีประโยชน์เมื่อ dependencies เปลี่ยนแปลงเพียงรายการเดียว — แคชยังคงใช้งานได้บางส่วน สำหรับ Gradle ขอแนะนำเพิ่มเติมให้เปิดใช้งาน Gradle Build Cache ซึ่งแคชผลลัพธ์การสร้างระหว่างโมดูลต่างๆ ของโปรเจกต์

ตัวอย่างการแคช Gradle

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

ประสิทธิภาพของแคชสำหรับโปรเจกต์ Android: การสร้างครั้งแรกโดยไม่ใช้แคช — 8–12 นาที การสร้างครั้งต่อไปด้วยแคช — 2–4 นาที สำหรับ iOS กับ CocoaPods การประหยัดจะคล้ายกัน ขอแนะนำให้รวม actions/cache กับ setup-gradle action จาก Gradle เพื่อการจัดการแคชที่เหมาะสมที่สุด สำหรับ dependencies npm ใน React Native จะใช้ actions/cache กับการแฮช package-lock.json ด้วยการกำหนดค่าแคชที่เหมาะสม สามารถลดเวลาการสร้างได้ถึง 70%

GitHub Actions รองรับตัวแปรสภาพแวดล้อมในระดับ workflow, job และ step ตัวแปรสภาพแวดล้อมสามารถถูกแทนที่ได้: ระดับ step มีลำดับความสำคัญสูงสุด สำหรับข้อมูลที่เป็นความลับ ให้ใช้ secrets เสมอ — พวกมันถูกเข้ารหัสด้วย AES-256 และไม่แสดงในบันทึก นอกจากนี้ยังมีกฎการป้องกันสภาพแวดล้อม — การอนุมัติด้วยตนเองที่จำเป็นก่อนการปรับใช้ เพื่อความปลอดภัยเพิ่มเติม สามารถกำหนดค่าการอนุมัติที่จำเป็นจากผู้ใช้หรือทีมที่เฉพาะเจาะจง

GitHub Actions ยังรองรับ Reusable Workflows — ไพพ์ไลน์ที่ใช้ซ้ำได้ซึ่งสามารถเรียกจากเวิร์กโฟลว์อื่นๆ สิ่งนี้ช่วยให้สร้างเวิร์กโฟลว์การสร้างแบบรวมศูนย์และนำกลับมาใช้ใหม่ในพื้นที่เก็บข้อมูลทั้งหมดขององค์กร Reusable workflow ถูกเรียกด้วยบรรทัดเดียวและสามารถรับพารามิเตอร์นำเข้าและ secrets สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับการกำหนดมาตรฐานแนวทางปฏิบัติ CI/CD ในทีมขนาดใหญ่

ความปลอดภัยและแนวทางปฏิบัติที่ดีที่สุด

เมื่อกำหนดค่า GitHub Actions สำหรับโปรเจกต์มือถือ สิ่งสำคัญคือต้องปฏิบัติตามหลักการรักษาความปลอดภัย OIDC (OpenID Connect) ช่วยให้คุณกำจัดข้อมูลประจำตัวที่มีอายุยาวนานและรับโทเค็นชั่วคราวสำหรับผู้ให้บริการคลาวด์ ห้ามใช้ secrets เป็นข้อความธรรมดาในสคริปต์ — GitHub Actions จะปกปิด secrets โดยอัตโนมัติในบันทึก

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