GitHub Actions (built-in GitHub, free cho public repo): YAML trong .github/workflows/, marketplace lớn nhất, ưu tiên cho dự án đã ở GitHub. GitLab CI (built-in GitLab): .gitlab-ci.yml ở root repo, runner self-host miễn phí, auto-DevOps stack đầy đủ — phù hợp self-hosted enterprise. Jenkins (self-hosted, open-source): pipeline-as-code dùng Jenkinsfile (Groovy DSL), plugin ecosystem khổng lồ nhưng phải tự maintain server + upgrade plugins, hợp công ty có sẵn ops team. CircleCI (cloud-first): docker-based executors, parallelism mạnh, free tier nhỏ — hợp startup chạy nhiều jobs song song. Khi nào chọn cái nào: project ở GitHub → Actions; ở GitLab → GitLab CI (tích hợp issue/CR); enterprise on-premise → Jenkins; cần fast parallel test cloud → CircleCI hoặc Buildkite. Tiêu chí đánh giá: pricing (per-minute vs per-user), runner location (cloud vs self-hosted), secret management, caching primitives, matrix builds, approval gates.

Tránh lock-in: viết pipeline portable (shell scripts trong repo, gọi qua bất kỳ CI nào) — giúp migrate dễ dàng.

Trunk-based development (TBD): mọi developer commit thẳng vào main (hoặc PR ngắn hạn < 1 ngày), feature flag để hide work-in-progress khỏi user.

Phù hợp team CI/CD mature, deploy nhiều lần/ngày, test automation tốt. Git Flow (Vincent Driessen, 2010): branch develop riêng, feature/, release/, hotfix/* — quy trình lớn, hợp legacy software có release cycle dài (3-6 tháng), versioned product. Tại sao TBD thắng cho web modern:

1. Continuous delivery cần main luôn deployable — branch dài hạn rất dễ drift, merge nightmare;
2. feature flag cho phép merge code chưa hoàn chỉnh (ẩn sau flag) — không cần long-running feature branch;
3. review nhanh vì PR nhỏ (< 400 lines);
4. integration sớm phát hiện conflict trước khi tốn kém. Khi vẫn nên dùng Git Flow: phần mềm phát hành phiên bản (mobile app phải qua App Store review, desktop software, library với semver strict, embedded firmware). Practice TBD: short-lived branch (vài giờ tới 1 ngày), PR < 400 lines, CI gate strict (lint + types + tests + build, không skip), feature flag cho mọi tính năng lớn, monitor production aggressive (alerts, error tracking) vì deploy thường xuyên

• CI (Continuous Integration): tự động build và test code mỗi khi push hoặc PR, phát hiện lỗi sớm khi còn dễ fix.
• CD (Continuous Delivery): tự động deploy đến staging sau CI thành công — production deploy cần manual approval; Continuous Deployment: tự động deploy đến production không cần intervention.
• Pipeline stages điển hình: Lint → Type check → Unit tests → Build → Integration tests → Deploy staging → Smoke tests → Deploy production.
• Environment promotion: code di chuyển qua dev → staging → production — mỗi stage có environment variables riêng, không share secrets giữa environments.
• Rollback strategies: blue-green (switch traffic back), feature flags (disable feature không cần redeploy), database migration rollback (down migrations — tại sao mỗi migration cần down script).
• Feature flags: deploy code mới nhưng disable feature — gradually enable cho users, instant rollback không cần redeploy, A/B testing.
• Tools: GitHub Actions (tích hợp tốt với GitHub, marketplace), GitLab CI (built-in, tốt cho self-hosted), Jenkins (flexible nhưng phức tạp maintain), CircleCI, Buildkite (fast self-hosted runners).
• Secrets management: không commit secrets vào code — dùng GitHub Secrets, HashiCorp Vault, AWS Secrets Manager; rotate secrets định kỳ.

GitHub Actions là CI/CD platform tích hợp trong GitHub, trigger bởi events (push, PR, schedule, workflow_dispatch).

• Workflow YAML trong .github/workflows/ với cấu trúc: on (triggers), jobs (chạy parallel mặc định, dùng needs: để sequential), steps (actions hoặc run commands).
• Matrix strategy: chạy job với nhiều combinations — matrix: { node: [18, 20], os: [ubuntu-latest, windows-latest] } tạo 4 parallel jobs tự động; dùng để test cross-platform/cross-version.
• Caching: actions/cache để cache node_modules, build artifacts — key dựa trên hash của package-lock.json để invalidate khi dependencies thay đổi; significant speedup cho install steps.
• Secrets: lưu trong GitHub repo/org Settings → Secrets, access bằng ${{ secrets.MY_SECRET }} — không bao giờ log secrets.
• Reusable workflows: workflow A có thể call workflow B với uses: ./.github/workflows/shared.yml — tránh duplicate CI logic across repos.
• Self-hosted runners: chạy Actions trên máy chủ riêng — tiết kiệm cost cho large workloads, access internal resources, custom hardware (GPU, ARM).
• OIDC tokens: GitHub Actions có thể auth với AWS/GCP/Azure mà không cần long-lived credentials — best practice cho cloud deployments.
• Environments với required reviewers: production deployment cần approval từ reviewer trước khi proceed.

CI/CD (Continuous Integration / Continuous Deployment) là quy trình tự động kiểm tra và deploy code mỗi khi có thay đổi. Pipeline frontend chạy tuần tự để fail-fast:

1. lint + format check (nhanh nhất)
2. type check tsc --noEmit
3. unit tests với coverage threshold
4. production build

Ở tầng staging: deploy preview mỗi PR (Vercel preview URLs rất tiện), chạy E2E tests với Playwright. Deploy production khi merge vào main.

Công cụ phổ biến: GitHub Actions (miễn phí cho open source, tích hợp sẵn GitHub), GitLab CI, hoặc Jenkins/Azure DevOps cho enterprise on-premise.

GitOps = Git là single source of truth cho cả app code lẫn infrastructure state — cluster tự reconcile để match Git, không có ai kubectl apply bằng tay. Nguyên tắc cốt lõi:

1. Declarative — toàn bộ state mô tả bằng YAML/Helm/Kustomize trong Git;
2. Versioned & immutable — mọi thay đổi qua PR, history rõ ràng;
3. Pulled automatically — agent trong cluster pull config từ Git, không push từ CI;
4. Continuously reconciled — agent detect drift và tự sửa. ArgoCD: agent chạy trong K8s cluster, watch Git repo, sync resources tới namespace target

UI đẹp, hỗ trợ multi-cluster, app-of-apps pattern, sync waves, hooks.

Truy cập qua argocd CLI hoặc web UI. Flux (CNCF graduated): nhỏ gọn hơn ArgoCD, không có UI native (dùng Flux extension hoặc Weave GitOps), tích hợp tốt với Kustomize và Helm Controllers, có Image Automation Controller tự bump image tag khi có release mới. Lợi ích GitOps: audit trail (mọi deploy đều có commit), rollback bằng git revert, disaster recovery (cluster gone? re-create từ Git), no CI credentials in cluster (pull thay vì push — bảo mật hơn). Trade-off: thêm 1 component (Argo/Flux) phải maintain; debug khó hơn khi sync fail; phải educate team về branch strategy cho config repo.

Fail-fast = test rẻ chạy trước, test đắt chạy sau; song song hóa tối đa; cache aggressive; chỉ chạy job liên quan tới file thay đổi. Thứ tự stage (rẻ → đắt):

1. Lint + format check (5-10s) — fail trước khi develop test khác;
2. Type check tsc --noEmit (10-30s);
3. Unit tests với watch mode disabled, coverage chỉ trên file thay đổi (30s-2min);
4. Build production (1-3min);
5. Integration tests (2-5min);
6. E2E tests trên staging deploy (5-15min)

Stage sau chỉ chạy nếu stage trước pass. Song song hóa: matrix strategy chạy test split theo file (Jest --shard=1/4), upload coverage artifact → merge ở job cuối. Caching: cache node_modules theo hash của package-lock.json — invalidate khi lock thay đổi; cache Turborepo/Nx outputs để skip rebuild package không đổi (turbo run build --cache-dir=.turbo).

GitHub Actions: actions/cache@v4 với key chuẩn. Affected/changed-only: monorepo dùng nx affected --target=test hoặc turbo run test --filter=...[origin/main] — chỉ test packages bị ảnh hưởng. Concurrency control: GitHub concurrency: group: ci-${{ github.ref }} cancel-in-progress: true — push mới hủy run cũ trên cùng branch. Hidden cost: notification noise (chỉ ping khi main vỡ), flaky test (retry tự động 1 lần, flag để fix sau, không hide bằng --retries=5).

Không commit secrets vào code (kể cả .env); lưu trong native secret store của CI (GitHub Secrets, GitLab Variables) hoặc vault tập trung (HashiCorp Vault, AWS Secrets Manager); rotate định kỳ; dùng OIDC để cấp short-lived token cho cloud thay vì long-lived access key. Best practices:

1. Native CI secrets: GitHub Settings → Secrets and variables → Actions; truy cập qua ${{ secrets.MY_KEY }} — auto-masked trong logs.
2. Environment secrets: secrets gắn với environment (production, staging) → cần approval reviewer trước khi job dùng được.
3. OIDC (recommended cho cloud): GitHub Actions issue OIDC token, AWS/GCP/Azure trust GitHub OIDC → cấp short-lived credentials (15min) — không cần lưu AWS access key static.
4. Secret scanning: GitHub Secret Scanning + push protection (free cho public repo, paid cho private) chặn commit chứa AWS key/Stripe key trước khi push tới remote.
5. gitleaks trong pre-commit hook: scan locally.
6. HashiCorp Vault / AWS Secrets Manager: cho secrets nhạy cảm hơn (DB password production), CI fetch tại runtime với short TTL. Rotation: API keys quan trọng rotate 90 ngày; nếu nghi ngờ leak → revoke ngay, rotate, audit log để xác định blast radius. Sai lầm phổ biến: log toàn bộ env vào CI logs (set -x lộ secret); commit .env rồi delete (vẫn trong Git history — phải BFG repo-cleaner / git filter-repo + force push + rotate); echo secret vào artifact upload công khai

Rolling update (default K8s Deployment): thay pods dần dần, maxSurge: 25%, maxUnavailable: 25% — zero-downtime, dễ hiểu, hợp với stateless service phần lớn case. Recreate: kill toàn bộ pod cũ trước khi start pod mới — có downtime, dùng khi schema migration không backward-compatible (không thể chạy v1 + v2 cùng lúc). Canary: deploy version mới chỉ cho 1-5% traffic, monitor metrics, tăng dần nếu OK — phù hợp release rủi ro cao, có cơ chế rollback nhanh; cần service mesh (Istio/Linkerd) hoặc Argo Rollouts/Flagger để split traffic theo % chính xác. Blue-Green: duy trì 2 môi trường song song, switch traffic instant tại load balancer — rollback < 1s nhưng tốn 2x infra; tốt cho release lớn, smoke test green trước khi switch. Quyết định theo bối cảnh: stateless API thông thường → rolling; release rủi ro (thuật toán mới, big refactor) → canary + feature flag; cần rollback tức thời / downtime không chấp nhận được → blue-green; migration DB phá compat → recreate (chấp nhận maintenance window). Feature flags là layer trên cùng: tách deployment (đẩy code lên prod) khỏi release (bật cho user) — deploy rolling vẫn an toàn vì code mới ẩn sau flag, bật dần qua LaunchDarkly/Unleash mà không cần redeploy.

Build once, deploy many: artifact (Docker image, jar, zip) build 1 lần ở stage CI, promote qua các môi trường (dev → staging → prod) — không bao giờ rebuild từ source ở mỗi môi trường. Tại sao immutable: rebuild ở mỗi env risk subtle drift (npm install cùng package.json nhưng khác lockfile resolution, base image cập nhật lén).

• Image tag bằng commit SHA hoặc semver, không bao giờ overwrite latest cho production. Semantic versioning (semver): MAJOR.MINOR.PATCH — MAJOR khi breaking, MINOR cho feature mới backward-compat, PATCH cho bug fix.
• Pre-release: 1.2.0-rc.1, 2.0.0-beta.3.
• Automated tooling: semantic-release (commit message convention feat:, fix:, BREAKING CHANGE: → tự bump version + tạo changelog + tag Git + publish npm). Container image tag strategy: 3 tag cùng lúc — myapp:1.4.2 (semver), myapp:1.4.2-a3f8c9 (semver + commit SHA cho traceability), myapp:latest (chỉ cho dev/staging, không prod). Artifact registry: GitHub Container Registry, AWS ECR, Google Artifact Registry — lưu image với retention policy (xóa image > 30 ngày trừ tagged release). SBOM (Software Bill of Materials): generate khi build (syft hoặc cosign), lưu cùng artifact để audit compliance và detect vulnerable dependency sau publish.

Client-side hooks (husky + lint-staged): chạy nhanh, kiểm tra cơ bản (format, lint file đã sửa) — UX tốt vì fail trước khi commit.

Server-side CI gate: nguồn chân lý, không thể bypass — luôn phải có vì hook client có thể --no-verify. husky quản lý Git hooks trong package.json/.husky/: pre-commit chạy lint-staged, commit-msg validate conventional commits (commitlint), pre-push chạy test nhanh. lint-staged chạy lệnh chỉ trên file git add đã stage: ví dụ *.ts: eslint --fix, prettier --write — không lint toàn repo (chậm) mà chỉ file thay đổi. Defense in depth:

1. Editor: ESLint extension highlight lỗi realtime;
2. Pre-commit hook: lint + format file staged;
3. Pre-push hook: test fast subset;
4. CI: full lint + type check + test + build — bắt mọi thứ hook client bỏ qua. Conventional Commits: feat: add login, fix(api): handle 401 — chuẩn hóa commit message giúp tự generate changelog với semantic-release. Pitfall: hook client quá nặng (chạy full test) → dev frustrated, dùng --no-verify → mất ý nghĩa

Giữ pre-commit < 5s. CI bypass: cấm push thẳng vào main ở branch protection, require PR + status check pass, require linear history nếu cần.