Phần 1 — Tổng quan: CI/CD, GitHub Actions và các khái niệm cốt lõi

Series GitHub Actions Toàn Tập — 8 phần:

1. Phần 1 — Tổng quan: CI/CD, GitHub Actions và các khái niệm cốt lõi ← bạn đang đọc

2. Phần 2 — Workflow YAML đầu tiên và Triggers nâng cao

3. Phần 3 — Secrets, Variables và Environment protection

4. Phần 4 — Matrix builds, Caching và Artifacts

5. Phần 5 — Self-hosted Runner: cài đặt, security, auto-scaling

6. Phần 6 — Reusable Workflows và Composite Actions

7. Phần 7 — Pipeline thực tế: Next.js + Docker + VPS deploy

8. Phần 8 — Best practices, Debug và OIDC hardening

Mở đầu

GitHub Actions là nền tảng CI/CD tích hợp sẵn vào GitHub: không cần dựng server, không cần cài plugin, không cần webhook — chỉ cần đặt một file YAML trong .github/workflows/ là đã có pipeline tự động build, test, deploy.

Series này gồm 8 phần, đi từ khái niệm cơ bản đến vận hành pipeline production (multi-environment, OIDC, debug). Trong Phần 1, ta trả lời 2 câu hỏi nền tảng: CI/CD là gì và GitHub Actions tổ chức mọi thứ qua những khái niệm nào.

1. CI/CD là gì? Tại sao cần GitHub Actions?

CI/CD là viết tắt của:

• CI (Continuous Integration) — Tích hợp liên tục: mỗi lần commit code, hệ thống tự động build, chạy test, kiểm tra lint để phát hiện lỗi sớm.

• CD (Continuous Delivery / Deployment) — Phân phối / triển khai liên tục: code sau khi qua CI sẽ được đóng gói (build image, artifact) và đẩy lên server staging/production một cách tự động.

Trước khi có GitHub Actions, bạn thường phải dùng Jenkins, GitLab CI, CircleCI, Travis CI... — mỗi cái lại cần server riêng, học một cú pháp riêng, quản lý plugin riêng. GitHub Actions sinh ra để giải quyết tất cả các vấn đề đó: tích hợp thẳng vào repo, không cần server (nếu dùng runner của GitHub), cú pháp YAML đơn giản và có sẵn marketplace hàng nghìn action dùng lại được.

Ưu điểm nổi bật

2. Các khái niệm cốt lõi

Trước khi viết workflow đầu tiên, bạn phải nắm 5 khái niệm sau:

2.1. Workflow

Một workflow là một quy trình tự động được định nghĩa bằng file YAML, đặt trong thư mục .github/workflows/ của repo. Mỗi workflow trả lời cho câu hỏi: “Khi nào chạy? Chạy cái gì?”.

2.2. Event (Trigger)

Event là sự kiện kích hoạt workflow. Phổ biến nhất:

• push — khi có commit mới được đẩy lên branch.

• pull_request — khi mở/cập nhật PR.

• schedule — chạy theo cron (vd: mỗi đêm).

• workflow_dispatch — chạy thủ công từ UI GitHub.

• release — khi tag/release mới được tạo.

2.3. Job

Một job là một nhóm các bước (steps) chạy chung trên một runner. Mỗi job mặc định chạy song song với các job khác — muốn chạy tuần tự thì khai báo needs:.

2.4. Step

Mỗi step là một lệnh đơn lẻ — có thể là một câu shell (run:) hoặc gọi một action có sẵn (uses:).

2.5. Runner

Runner là máy thực sự chạy job. Có 2 loại:

1. GitHub-hosted runner — máy ảo do GitHub cung cấp (Ubuntu, Windows, macOS). Mỗi job khởi tạo máy mới, sạch hoàn toàn. Tiện nhưng có giới hạn thời gian và không truy cập được mạng nội bộ.

2. Self-hosted runner — máy bạn tự dựng (VPS, on-premise server, máy ở nhà). Tự do về tài nguyên, dùng được mạng nội bộ, nhưng phải tự bảo trì.

Tóm tắt

Trong phần này bạn đã nắm:

• CI/CD là gì, vì sao tự động hoá build/test/deploy lại quan trọng.

• Vì sao GitHub Actions thay thế được Jenkins/GitLab CI/Travis cho phần lớn workflow.

• 5 khái niệm cốt lõi: Workflow → Event → Job → Step → Runner.

• Khác biệt giữa GitHub-hosted runner (tiện, ephemeral) và self-hosted runner (linh hoạt, có quyền truy cập mạng nội bộ).

Trong Phần 2, ta sẽ viết workflow YAML đầu tiên, giải thích từng dòng cú pháp, rồi đi sâu vào các trigger nâng cao: lọc theo path, chạy theo cron, và chạy thủ công với input qua workflow_dispatch.

Phần 2: Workflow YAML đầu tiên và Triggers nâng cao →