Bài 34.2: Cấu hình CI/CD cho Next.js

Bài 34.2: Cấu hình CI/CD cho Next.js
Chào mừng trở lại với chuỗi bài blog về Lập trình Web Front-end! Hôm nay, chúng ta sẽ đi sâu vào một chủ đề cực kỳ quan trọng mà mọi developer chuyên nghiệp đều cần biết: Cấu hình CI/CD cho dự án Next.js. Nếu bạn đã từng cảm thấy mệt mỏi với việc phải tự tay build, test, và deploy mỗi khi có thay đổi code, thì CI/CD chính là người bạn đồng hành mà bạn đang tìm kiếm.
CI/CD không chỉ là một thuật ngữ "hot trend" mà còn là một tập hợp các thực hành giúp tự động hóa quá trình phát triển và triển khai ứng dụng của bạn. Với Next.js, một framework mạnh mẽ cho phép cả Server-Side Rendering (SSR), Static Site Generation (SSG), và API routes, việc có một quy trình CI/CD hiệu quả là chìa khóa để đảm bảo chất lượng, tốc độ và sự ổn định.
CI/CD Là Gì và Tại Sao Quan Trọng Với Next.js?
Hãy cùng "mổ xẻ" hai phần của CI/CD:
CI - Continuous Integration (Tích hợp liên tục):
- Đây là quá trình mà các nhà phát triển thường xuyên tích hợp các thay đổi code của họ vào một repository dùng chung (ví dụ:
main
branch). - Sau mỗi lần tích hợp, một quy trình tự động sẽ chạy để build ứng dụng, chạy các bài test (unit tests, integration tests), và kiểm tra linting (kiểm tra cú pháp, định dạng code).
- Mục tiêu: Phát hiện sớm các lỗi tích hợp, lỗi test hoặc lỗi code style, giảm thiểu thời gian debug sau này.
- Với Next.js: Điều này bao gồm việc đảm bảo ứng dụng Next.js của bạn có thể build thành công (
next build
), tất cả các bài test đều passed, và code tuân thủ các quy tắc linting bạn đã đặt ra (ESLint, Prettier).
- Đây là quá trình mà các nhà phát triển thường xuyên tích hợp các thay đổi code của họ vào một repository dùng chung (ví dụ:
CD - Continuous Deployment / Delivery (Triển khai liên tục / Phân phối liên tục):
- Continuous Delivery: Mọi thay đổi code đã qua quy trình CI đều sẵn sàng để được triển khai bất cứ lúc nào. Việc triển khai có thể là thủ công (nhấn nút) hoặc tự động hoàn toàn.
- Continuous Deployment: Mọi thay đổi code đã qua quy trình CI thành công sẽ tự động được triển khai lên môi trường production mà không cần can thiệp thủ công.
- Mục tiêu: Đưa các tính năng mới hoặc sửa lỗi đến tay người dùng nhanh chóng và đáng tin cậy.
- Với Next.js: Điều này có nghĩa là sau khi code được build, test, và linting thành công, nó sẽ tự động (hoặc với một thao tác đơn giản) được đẩy lên các nền tảng hosting như Vercel, Netlify, AWS, hoặc máy chủ của riêng bạn.
Tại sao CI/CD quan trọng cho Next.js?
- Đảm bảo chất lượng: Mỗi thay đổi được kiểm tra tự động.
- Tăng tốc độ phát triển: Giảm thời gian lãng phí vào các tác vụ thủ công.
- Giảm thiểu rủi ro: Phát hiện lỗi sớm, triển khai các thay đổi nhỏ lẻ thường xuyên ít rủi ro hơn triển khai các thay đổi lớn.
- Phản hồi nhanh: Developer biết ngay lập tức nếu thay đổi của họ gây ra lỗi.
- Hỗ trợ các tính năng Next.js: Đảm bảo quá trình build cho SSR, SSG hoạt động chính xác trên môi trường server.
Chọn Lựa Công Cụ CI/CD Phù Hợp
Có rất nhiều nền tảng và công cụ hỗ trợ CI/CD. Đối với các dự án web, đặc biệt là Front-end và Next.js, các lựa chọn phổ biến thường tích hợp chặt chẽ với Git repository của bạn:
- GitHub Actions: Nền tảng CI/CD tích hợp ngay trong GitHub. Miễn phí cho các public repository và có một lượng miễn phí cho private repository. Rất linh hoạt và có cộng đồng lớn.
- GitLab CI: Tích hợp trong GitLab. Tương tự như GitHub Actions.
- Bitbucket Pipelines: Tích hợp trong Bitbucket.
- Vercel / Netlify: Các nền tảng hosting chuyên biệt cho Front-end. Cung cấp CI/CD tích hợp sẵn. Chỉ cần kết nối repository của bạn, Vercel/Netlify sẽ tự động build và deploy mỗi khi bạn push code lên branch được cấu hình. Đây là lựa chọn phổ biến và đơn giản nhất cho nhiều dự án Next.js.
- CircleCI, Jenkins, Travis CI: Các nền tảng CI/CD độc lập, mạnh mẽ và có thể cấu hình cho mọi loại dự án.
Trong bài này, chúng ta sẽ tập trung vào việc cấu hình sử dụng GitHub Actions vì sự linh hoạt và phổ biến của nó, đồng thời cũng nhắc đến cách Vercel/Netlify đơn giản hóa quy trình này.
Cấu Hình CI (Build, Test, Lint) với GitHub Actions
Mục tiêu của bước này là tạo ra một quy trình tự động chạy mỗi khi có code được push hoặc Pull Request được mở. Quy trình này sẽ đảm bảo code của bạn "khỏe mạnh".
GitHub Actions sử dụng các file cấu hình .yml
(YAML) đặt trong thư mục .github/workflows
ở thư mục gốc của dự án bạn.
Ví dụ về một workflow CI cơ bản cho Next.js:
Tạo file: .github/workflows/ci.yml
name: CI Workflow - Build, Test, Lint
on:
push:
branches:
- main # Chạy khi có push lên nhánh main
- develop # Chạy khi có push lên nhánh develop
pull_request:
branches:
- main
- develop # Chạy khi có PR merge vào main hoặc develop
jobs:
build_test_lint:
runs-on: ubuntu-latest # Chọn hệ điều hành để chạy job
steps:
- name: Checkout code
uses: actions/checkout@v4 # Action để clone repository về máy ảo
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20' # Chọn phiên bản Node.js phù hợp với dự án của bạn
cache: 'npm' # Bật cache cho npm dependencies để tăng tốc
- name: Install dependencies
run: npm ci # Sử dụng npm ci để cài đặt dependencies một cách sạch sẽ và nhất quán
- name: Run ESLint
run: npm run lint # Chạy lệnh linting theo package.json của bạn
- name: Run Tests
run: npm run test # Chạy lệnh test theo package.json của bạn
- name: Build Next.js project
run: npm run build # Chạy lệnh build Next.js
env:
NEXT_PUBLIC_MY_VARIABLE: ${{ secrets.MY_PUBLIC_VARIABLE }} # Ví dụ về cách truyền biến môi trường
# Các biến môi trường bí mật (secret) nên được quản lý trong GitHub Secrets
Giải thích Code Ví Dụ (CI):
name: CI Workflow - Build, Test, Lint
: Tên của workflow hiển thị trên giao diện GitHub.on:
: Định nghĩa khi nào workflow này sẽ chạy. Ở đây là khi cópush
lên các nhánhmain
,develop
hoặc khi cópull_request
nhắm đến các nhánh này.jobs:
: Một workflow có thể có nhiều job chạy độc lập hoặc phụ thuộc nhau. Ở đây ta có một job duy nhất làbuild_test_lint
.runs-on: ubuntu-latest
: Chỉ định môi trường chạy job là máy ảo Ubuntu phiên bản mới nhất.steps:
: Danh sách các bước thực hiện trong job.name:
: Tên hiển thị của từng bước.uses: actions/checkout@v4
: Sử dụng một action có sẵn từ Marketplace của GitHub Actions để clone code từ repository.v4
là phiên bản của action.uses: actions/setup-node@v4
: Sử dụng action để cài đặt Node.js trên máy ảo.with:
dùng để cấu hình action, ở đây là chọnnode-version
và bậtcache
chonpm
.run: npm ci
: Chạy một lệnh command line.npm ci
giốngnpm install
nhưng đảm bảo sử dụngpackage-lock.json
để cài đặt phiên bản chính xác, rất tốt cho CI.run: npm run lint
,run: npm run test
,run: npm run build
: Chạy các script đã định nghĩa trong filepackage.json
của bạn. Bạn cần đảm bảo các scriptlint
,test
,build
đã được cấu hình đúng trong dự án Next.js của mình.env:
: Cách truyền các biến môi trường vào bước chạy.secrets.MY_PUBLIC_VARIABLE
là cách truy cập biến bí mật đã lưu trữ trong GitHub Secrets của repository. Điều này rất quan trọng để xử lý các biến môi trường cần thiết cho quá trình build Next.js (ví dụ: các biến bắt đầu bằngNEXT_PUBLIC_
).
Khi bạn push file ci.yml
này lên GitHub, GitHub Actions sẽ tự động nhận diện và chạy workflow mỗi khi điều kiện on
được đáp ứng. Bạn có thể xem kết quả chạy trong tab "Actions" trên repository GitHub của mình. Nếu bất kỳ bước nào (lint, test, build) thất bại, toàn bộ job sẽ thất bại, cảnh báo cho bạn biết có vấn đề với code mới.
Cấu Hình CD (Deployment) với GitHub Actions
Sau khi quy trình CI thành công, chúng ta muốn tự động deploy ứng dụng Next.js lên môi trường hosting. Như đã nói, các nền tảng như Vercel hay Netlify có tích hợp sẵn, nhưng bạn cũng có thể trigger deploy từ GitHub Actions.
Chúng ta sẽ lấy ví dụ deploy lên Vercel sử dụng GitHub Actions, vì đây là một kịch bản rất phổ biến cho Next.js.
Đầu tiên, bạn cần cài đặt Vercel CLI và đăng nhập:
npm install -g vercel
vercel login
Sau đó, liên kết dự án Next.js của bạn với Vercel:
vercel link
(trong thư mục gốc của dự án)
Tiếp theo, bạn cần lấy Vercel API Token. Truy cập Vercel Account Settings -> Generate New Token. Lưu token này cẩn thận!
Trong repository GitHub của bạn, vào Settings -> Secrets and variables -> Actions -> New repository secret. Thêm một secret mới với tên ví dụ là VERCEL_TOKEN
và giá trị là API Token bạn vừa tạo.
Bây giờ, tạo file workflow cho CD: .github/workflows/deploy.yml
(hoặc bạn có thể thêm vào file ci.yml
với điều kiện phụ thuộc vào job CI).
Ví dụ file deploy.yml
:
name: CD Workflow - Deploy to Vercel
on:
push:
branches:
- main # Chỉ deploy khi có push lên nhánh production (main)
jobs:
deploy:
runs-on: ubuntu-latest
# optional: Thêm điều kiện phụ thuộc vào job CI nếu muốn deploy chỉ sau khi CI thành công
# needs: build_test_lint
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Build Next.js project (optional - Vercel Action cũng build)
# Bước này có thể bỏ qua nếu Vercel Action tự build,
# nhưng chạy lại build giúp kiểm tra lần cuối trước khi deploy
run: npm run build
env:
NEXT_PUBLIC_MY_VARIABLE: ${{ secrets.MY_PUBLIC_VARIABLE }} # Truyền biến môi trường cần thiết cho build
- name: Deploy to Vercel
uses: vercel/actions/deploy@v2 # Sử dụng Vercel Action chính thức
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }} # Sử dụng secret đã lưu
prod: true # Đặt là true để deploy lên môi trường production (cho nhánh main)
# project-id: ${{ secrets.VERCEL_PROJECT_ID }} # Tùy chọn: chỉ định Project ID
# org-id: ${{ secrets.VERCEL_ORG_ID }} # Tùy chọn: chỉ định Organization ID
# Tùy chọn: Bước Alias nếu cần đặt tên miền khác cho deployment cụ thể
# - name: Assign Alias to Production Deployment
# uses: vercel/actions/alias@v2
# with:
# vercel-token: ${{ secrets.VERCEL_TOKEN }}
# deployment-id: ${{ steps.deploy.outputs.deployment-id }} # Lấy ID từ bước deploy
# # alias: your-custom-domain.com # Thay bằng domain của bạn
# # Định nghĩa alias cho production thường được cấu hình trong Vercel Project Settings
Giải thích Code Ví Dụ (CD - Deploy to Vercel):
on: push: branches: [main]
: Workflow này chỉ chạy khi có code được push lên nhánhmain
(thường là nhánh production). Bạn có thể cấu hình thêm các nhánh staging nếu cần.needs: build_test_lint
(tùy chọn): Nếu bạn đặt job deploy này trong cùng fileci.yml
, bạn có thể sử dụngneeds
để chỉ định rằng jobdeploy
chỉ chạy sau khi jobbuild_test_lint
hoàn thành thành công.runs-on: ubuntu-latest
: Môi trường chạy.- Các bước
Checkout code
,Set up Node.js
,Install dependencies
tương tự như workflow CI. Build Next.js project (optional)
: Mặc dù Vercel Action sẽ tự build, việc chạynpm run build
trước đó trong workflow có thể giúp kiểm tra lại môi trường build. Tuy nhiên, để đơn giản hóa và tránh build hai lần, bạn có thể bỏ qua bước này và chỉ dựa vào Vercel Action để build.uses: vercel/actions/deploy@v2
: Sử dụng Vercel Action chính thức để thực hiện việc deploy.with: vercel-token: ${{ secrets.VERCEL_TOKEN }}
: Truyền Vercel API Token vào Action thông qua biến bí mật đã lưu trên GitHub. Không bao giờ hardcode token trực tiếp vào file cấu hình!prod: true
: Chỉ định rằng đây là deployment lên môi trường production. Vercel sẽ tự động gán alias (tên miền chính) cho deployment này. Nếu deploy từ nhánh khác (ví dụ:develop
), bạn có thể bỏprod: true
hoặc đặtprod: false
để tạo preview deployment.project-id
vàorg-id
(tùy chọn): Giúp Vercel xác định dự án và tổ chức của bạn nếu có nhiều dự án hoặc tổ chức liên kết với tài khoản Vercel của bạn. Bạn có thể lấy các ID này từ Vercel Dashboard hoặc file.vercel/project.json
sau khi chạyvercel link
. Lưu chúng vào GitHub Secrets.uses: vercel/actions/alias@v2
(tùy chọn): Action này có thể được dùng để gán một alias (tên miền) cụ thể cho một deployment đã hoàn thành. Thường thì Vercel tự động quản lý alias cho production và preview deployments, nên bước này ít khi cần thiết cho kịch bản cơ bản.
Sau khi push file deploy.yml
, mỗi lần bạn push code lên nhánh main
, GitHub Actions sẽ chạy workflow này, trigger Vercel để deploy phiên bản mới nhất của ứng dụng bạn lên production.
Kết Hợp CI và CD
Trong nhiều trường hợp, bạn muốn CD chỉ chạy sau khi CI đã thành công. Bạn có thể làm điều này bằng cách:
- Sử dụng cùng một file workflow: Đặt các job CI và CD trong cùng một file
.yml
và sử dụngneeds
để job CD phụ thuộc vào job CI. - Sử dụng nhiều file workflow và trigger giữa chúng: Mặc dù ít phổ biến hơn cho luồng CI/CD thẳng, bạn có thể trigger một workflow từ một workflow khác (ví dụ: sau khi CI hoàn thành, một workflow CI có thể dispatch một event để trigger workflow CD). Cách 1 dùng
needs
là đơn giản và hiệu quả hơn.
Ví dụ kết hợp CI và CD trong một file .github/workflows/main_workflow.yml
:
name: Main CI/CD Workflow
on:
push:
branches:
- main
- develop
pull_request:
branches:
- main
- develop
jobs:
build_test_lint: # Job CI
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run ESLint
run: npm run lint
- name: Run Tests
run: npm run test
- name: Build Next.js project
run: npm run build
env:
NEXT_PUBLIC_MY_VARIABLE: ${{ secrets.MY_PUBLIC_VARIABLE }}
# ... thêm các biến cần thiết khác cho build
deploy_preview: # Job CD cho môi trường preview (khi PR được mở hoặc push lên develop)
runs-on: ubuntu-latest
needs: build_test_lint # Phụ thuộc vào job CI
if: github.event_name == 'pull_request' || github.ref == 'refs/heads/develop' # Chỉ chạy khi là PR hoặc push lên develop
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
# Không cần chạy build lại ở đây nếu Vercel Action tự build
- name: Deploy Preview to Vercel
uses: vercel/actions/deploy@v2
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
prod: false # Triển khai môi trường preview
# project-id: ${{ secrets.VERCEL_PROJECT_ID }}
# org-id: ${{ secrets.VERCEL_ORG_ID }}
# Alias cho preview deployment thường được Vercel tự động tạo dựa trên tên branch hoặc PR
deploy_production: # Job CD cho môi trường production (chỉ khi push lên main)
runs-on: ubuntu-latest
needs: build_test_lint # Phụ thuộc vào job CI
if: github.ref == 'refs/heads/main' # Chỉ chạy khi push lên nhánh main
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
# Không cần chạy build lại ở đây nếu Vercel Action tự build
- name: Deploy Production to Vercel
uses: vercel/actions/deploy@v2
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
prod: true # Triển khai môi trường production
# project-id: ${{ secrets.VERCEL_PROJECT_ID }}
# org-id: ${{ secrets.VERCEL_ORG_ID }}
Giải thích Code Ví Dụ (Kết hợp CI/CD):
- Workflow này chạy trên
push
vàpull_request
cho cảmain
vàdevelop
. build_test_lint
job chạy đầu tiên cho mọi trường hợp kích hoạt workflow.deploy_preview
job:- Sử dụng
needs: build_test_lint
để đảm bảo CI chạy xong mới deploy. - Sử dụng điều kiện
if: github.event_name == 'pull_request' || github.ref == 'refs/heads/develop'
để chỉ chạy khi có PR hoặc push lên nhánhdevelop
. prod: false
để tạo preview deployment trên Vercel.
- Sử dụng
deploy_production
job:- Sử dụng
needs: build_test_lint
. - Sử dụng điều kiện
if: github.ref == 'refs/heads/main'
để chỉ chạy khi có push lên nhánhmain
. prod: true
để deploy lên production.
- Sử dụng
Với cấu hình này, mỗi khi bạn push code hoặc mở PR, CI sẽ chạy. Nếu CI thành công:
- PR hoặc push lên
develop
sẽ tạo ra một preview deployment. - Push lên
main
sẽ trigger production deployment.
Cân Nhắc Nâng Cao
- Quản lý Biến Môi Trường (Environment Variables): Next.js xử lý biến môi trường rất tốt. Đối với CI/CD, các biến cần cho quá trình build (bắt đầu bằng
NEXT_PUBLIC_
) phải được truyền vào bước build của workflow. Các biến bí mật khác (khóa API backend, database credentials) chỉ cần thiết khi ứng dụng chạy trên server (nếu bạn dùng SSR/API routes) và nên được cấu hình trực tiếp trên nền tảng hosting (Vercel, Netlify, AWS...). Luôn sử dụng GitHub Secrets hoặc cơ chế tương tự trên các nền tảng CI/CD khác để lưu trữ các thông tin nhạy cảm. - Caching: Tận dụng caching trong các workflow CI/CD để tăng tốc độ cài đặt dependencies hoặc kết quả build. Action
actions/cache
là một ví dụ điển hình trong GitHub Actions. - Chiến lược Branching: Quy trình CI/CD hoạt động hiệu quả nhất khi đi kèm với một chiến lược branching rõ ràng (ví dụ: Gitflow hoặc Trunk-Based Development đơn giản). Thường thì các commit vào
main
hoặc tag cụ thể sẽ trigger production deployment, trong khi các commit vàodevelop
hoặc các PR sẽ trigger staging/preview deployment. - Thông báo: Tích hợp các thông báo (Slack, Email) vào workflow để nhận thông báo khi CI/CD thành công hoặc thất bại, giúp team phản ứng nhanh chóng.
- Tích hợp với Testing nâng cao: Ngoài unit/integration test, bạn có thể thêm các bước chạy End-to-End tests (sử dụng Cypress, Playwright) sau khi deploy preview, hoặc kiểm tra hiệu năng (Lighthouse CI).
CI/CD Đơn Giản Hóa với Vercel/Netlify
Nếu bạn host ứng dụng Next.js của mình trên Vercel hoặc Netlify, quy trình CI/CD thậm chí còn đơn giản hơn rất nhiều.
- Kết nối Repository: Chỉ cần vào dashboard của Vercel hoặc Netlify, import dự án từ GitHub/GitLab/Bitbucket và chọn repository Next.js của bạn.
- Tự động nhận diện: Vercel và Netlify tự động nhận diện đây là một dự án Next.js. Họ sẽ tự động cấu hình lệnh build (
next build
) và thư mục output (.next
hoặcout
). - Tự động triển khai: Mặc định, mỗi khi bạn push code lên nhánh production (thường là
main
), Vercel/Netlify sẽ tự động chạy quy trình build và deploy phiên bản mới lên production. - Preview Deployments: Khi bạn mở một Pull Request, họ sẽ tự động tạo một preview deployment độc lập với một URL riêng. Điều này cực kỳ hữu ích cho việc xem xét và thử nghiệm các thay đổi trước khi merge.
- Biến Môi Trường: Bạn quản lý biến môi trường trực tiếp trong cài đặt dự án trên dashboard của Vercel/Netlify.
Với Vercel/Netlify, bạn thường không cần viết file cấu hình .yml
phức tạp cho CI/CD (trừ khi bạn muốn tùy chỉnh rất sâu). Toàn bộ quá trình build, test (nếu có script test trong package.json), và deploy được xử lý "magic" bởi nền tảng này.
Tuy nhiên, việc hiểu cách GitHub Actions (hoặc các công cụ khác) hoạt động vẫn rất quan trọng nếu bạn cần linh hoạt hơn, deploy lên các nền tảng khác, hoặc cần các bước CI phức tạp hơn (ví dụ: quét mã độc, kiểm tra bảo mật...).
Tóm Lại Hành Trình CI/CD Cho Next.js
Để thiết lập CI/CD hiệu quả cho dự án Next.js của bạn, hãy làm theo các bước cơ bản sau:
- Chuẩn bị Dự án: Đảm bảo dự án Next.js của bạn có các script
build
,test
,lint
được cấu hình đúng trongpackage.json
."scripts": { "dev": "next dev", "build": "next build", "start": "next start", "lint": "next lint", "test": "jest" // hoặc bất kỳ lệnh test nào bạn dùng },
- Chọn Nền Tảng: Quyết định sử dụng GitHub Actions, Vercel/Netlify tích hợp, hay một công cụ khác. Với Next.js, Vercel/Netlify thường là điểm khởi đầu dễ dàng nhất.
- Cấu hình CI: Thiết lập một workflow để tự động checkout code, cài đặt dependencies, chạy lint, test và build trên mỗi lần push/PR. Sử dụng file
.github/workflows/ci.yml
nếu dùng GitHub Actions. - Cấu hình CD: Thiết lập một workflow (hoặc thêm bước vào workflow CI) để tự động deploy ứng dụng sau khi CI thành công. Sử dụng
.github/workflows/deploy.yml
và Vercel/actions/deploy nếu dùng GitHub Actions để deploy lên Vercel, hoặc đơn giản là kết nối repository với Vercel/Netlify. - Quản lý Secrets: Lưu trữ các thông tin nhạy cảm (API keys, tokens) dưới dạng secrets trên nền tảng CI/CD của bạn.
- Tinh chỉnh: Cấu hình điều kiện chạy workflow (nhánh nào, sự kiện nào), thêm caching, thông báo, và các bước kiểm tra nâng cao khác khi cần.
Áp dụng CI/CD sẽ biến quá trình phát triển Next.js của bạn từ một chuỗi các bước thủ công tẻ nhạt thành một quy trình nhanh chóng, tự động và đáng tin cậy. Nó giúp cả team tập trung hơn vào việc viết code mới thay vì lo lắng về các vấn đề triển khai hay lỗi tích hợp muộn.
Chúc bạn thành công trong việc xây dựng các quy trình CI/CD mạnh mẽ cho các dự án Next.js của mình! Hẹn gặp lại trong các bài tiếp theo.
Comments