Bỏ qua để đến nội dung

Deploy Sản Phẩm

Level 6 — AI Coding & Vibe Coding Bài 11/12
Thời gian đọc: 6-8 phút

Deploy Sản Phẩm

3 môi trường: Local → Preview (chỉ bạn thấy) → Production (ai cũng truy cập được), với rollback về bản trước nếu có vấn đề. Biến môi trường là nơi secrets (bài 62) thực sự 'sống' khi deploy — mã hóa khi lưu trữ, tách biệt khỏi code.

🎯 Bản chất cốt lõi ⚡️ Thực chiến ứng dụng 🛠️ Quy trình chuẩn 💡 Tối ưu hiệu suất
Chế độ đọc:
Tóm Tắt Nhanh Trong 3 Phút — Trọng Tâm Bài Học
1. Bản chất cốt lõi

Nắm vững nguyên lý và khái niệm nền tảng trước khi đi vào công cụ thực tế.

2. Thực thi chuẩn xác

Áp dụng quy trình từng bước, case study thực chiến và template mẫu có sẵn.

3. Tối ưu & Vận hành

Kiểm tra checklist hoàn thành, né tránh các sai lầm kinh điển để vận hành bền vững.

CHẶNG 1 · BẢN CHẤT & NGUYÊN LÝ

Phần 1: Bản chất & Nguyên lý

Nắm vững các khái niệm nền tảng, cơ chế hoạt động và mô hình tư duy cốt lõi.

1. Mục tiêu học tập

Sau bài này, bạn có thể:

🎯 BẢN CHẤT
Phân biệt đúng development (máy cá nhân) và production (server công cộng, người dùng thật truy cập được).
🏗️ CẤU TRÚC
Giải thích vai trò của biến môi trường (environment variables) như cơ chế thực tế để đưa secrets (đã học bài 62) lên môi trường production một cách an toàn.
⚡️ NGUYÊN LÝ
Thực hiện deploy dự án tích lũy, có URL truy cập công khai.
🛠️ THỰC CHIẾN
Biết dùng bản xem trước (preview) để kiểm tra trước khi đưa ra bản chính thức (production).

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

Mô hình “phần mềm chạy ở đâu” (vendor-neutral, nền tảng cho toàn bài):

  • Development (máy cá nhân) — nơi bạn đã xây và thử nghiệm suốt bài 56-62, chỉ bạn truy cập được.
  • Production (server công cộng) — nơi sản phẩm thật sự chạy cho người dùng khác truy cập, có địa chỉ (domain) công khai.

Deployment là gì: kết quả của 1 lần “build” (đóng gói) thành công cho dự án — mỗi lần deploy tạo ra 1 địa chỉ (URL) để xem sản phẩm đang chạy. Có nhiều cách tạo 1 deployment, phổ biến nhất là qua Git (đã học bài 54): mỗi lần bạn đẩy thay đổi lên kho lưu trữ, hệ thống tự động tạo 1 deployment mới.

3 môi trường thực tế khi deploy (Lớp thực hành, ví dụ cụ thể theo tài liệu chính thức):

  • Local Development — đúng như bạn đã làm suốt bài 56-62.
  • Preview — deploy để kiểm tra/xem trước, không ảnh hưởng tới bản người dùng thật đang thấy — tạo ra khi bạn đẩy thay đổi lên 1 nhánh Git khác nhánh chính.
  • Production — bản chính thức người dùng thật truy cập, có domain chính thức.

Có thể “thăng cấp” (promote) 1 bản Preview thành Production nếu kiểm tra ổn, và quay lại (rollback) bản deploy trước đó an toàn nếu bản mới có vấn đề — đây là lý do quy trình Preview trước Production quan trọng: cho bạn 1 bước kiểm tra trước khi đổi sản phẩm mà người dùng thật đang thấy.

Biến môi trường (environment variables) — nơi secrets thực sự “sống” khi deploy: đây là cầu nối trực tiếp với bài 62. Biến môi trường là cặp key-value cấu hình bên ngoài code, giá trị có thể khác nhau theo từng môi trường (Development/Preview/Production), và được mã hóa khi lưu trữ — an toàn cho cả dữ liệu nhạy cảm như API key/token. Nói cách khác: nguyên tắc “secrets không nằm trong code” (bài 62) thực hiện được chính xác bằng biến môi trường khi deploy.

3. Tại sao nội dung này quan trọng

Đây là bước biến “1 dự án học tập chạy trên máy bạn” thành “1 sản phẩm thật, ai cũng truy cập được” — đúng mục tiêu Project của cả Level 6 (“Xây và deploy một ứng dụng AI hoàn chỉnh”). Không có bài này, mọi công sức từ bài 53-62 vẫn chỉ nằm trên 1 máy tính.

4. Cơ chế hoạt động

Phân định AI vs con người:

Điều bạn cần hiểu Điều AI có thể thực hiện Điều bạn phải xác nhận
Development vs Production 2 môi trường khác nhau, thay đổi ở 1 bên không tự động ảnh hưởng bên kia — Bạn đang thao tác đúng ở môi trường nào, đặc biệt trước khi đổi gì ở Production
Deployment Mỗi lần đẩy code lên thường tự động tạo deployment mới Thực hiện các bước triển khai kỹ thuật Sản phẩm thật sự chạy được công khai sau khi deploy, không chỉ “báo thành công”
Preview Bản xem trước không ảnh hưởng người dùng thật Tạo bản Preview để kiểm tra Đã kiểm tra kỹ ở Preview trước khi thăng cấp lên Production
Biến môi trường Đây là nơi secrets thực sự nằm khi deploy, không phải trong code Thiết lập/hướng dẫn cấu hình biến môi trường Secrets đã đúng như đã rà soát ở bài 62 — không có key nào bị hardcode

5. Mental model

Nếu bài 62 là kiểm tra khóa cửa và cất chìa khóa dự phòng đúng chỗ, bài này là lúc bạn mở cửa ngôi nhà cho công chúng — nhưng trước khi mở cửa chính, bạn có 1 “buổi xem nhà thử” riêng tư (Preview) để kiểm tra mọi thứ ổn trước khi công bố địa chỉ (domain) cho mọi người biết (Production).

CHẶNG 2 · THỰC CHIẾN ỨNG DỤNG

Phần 2: Thực chiến ứng dụng

Quy trình thực thi từng bước, case study cụ thể và bộ prompt/template áp dụng ngay.

6. Hướng dẫn từng bước

Áp dụng cho dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.

1
Chọn nền tảng hosting — yêu cầu Claude Code đề xuất 1-2 lựa chọn phù hợp với công nghệ đã chọn ở bài 56 (nhiều nền tảng phổ biến hỗ trợ deploy qua Git tự động, ví dụ Vercel).
2
Kết nối kho lưu trữ Git (đã học bài 54) với nền tảng hosting đã chọn — đây là cách phổ biến nhất để deploy tự động mỗi khi có thay đổi.
3
Thiết lập biến môi trường — chuyển các secrets đã chuẩn bị ở bài 62 (API key cho tính năng AI tóm tắt sắp thêm ở bài 64) vào đúng biến môi trường của nền tảng, không để trong code.
4
Deploy lên môi trường Preview trước — kiểm tra kỹ: các tính năng CRUD đã test (bài 61) có hoạt động đúng trên bản Preview không.
5
Thăng cấp lên Production khi đã xác nhận Preview ổn — lúc này sản phẩm có URL công khai, bất kỳ ai cũng truy cập được.
6
Ghi lại URL production — đây là “địa chỉ nhà” chính thức của dự án tích lũy, sẽ dùng lại khi thêm tính năng AI tóm tắt ở bài 64.

7. Ví dụ thực tế

Vì sao bước Preview không nên bỏ qua: nếu bạn deploy thẳng lên Production mà không qua Preview, 1 lỗi nhỏ (ví dụ quên thiết lập đúng biến môi trường cho API key) có thể khiến người dùng thật gặp lỗi ngay lập tức. Với bước Preview, bạn phát hiện lỗi đó trong 1 môi trường không ai khác nhìn thấy, sửa xong rồi mới thăng cấp — đúng nguyên tắc “con người xác nhận trước khi công khai” xuyên suốt Level 6.

8. Prompt/template/workflow

Dự án đã hoàn thành: [công nghệ đã dùng, ví dụ ngôn ngữ/framework bài 56].
Đề xuất cách deploy dự án này, kết nối với kho Git đã có (bài 54).
Hướng dẫn tôi cách thiết lập biến môi trường cho các secrets sau: [danh
sách secrets đã chuẩn bị ở bài 62].
[ ] Đã deploy thành công lên Preview chưa?
[ ] Đã thử toàn bộ tính năng chính (thêm/xem/xóa ghi chú) trên Preview?
[ ] Secrets đã nằm trong biến môi trường, không nằm trong code?
[ ] Sẵn sàng cho người khác truy cập được sản phẩm?

9. Visual hoặc diagram cần thiết

LocalPreview (riêng tư)Production (công khai)
Hình 6.11 — 3 môi trường nối tiếp: Local → Preview (riêng tư) → Production (công khai), với khả năng rollback về bản deploy trước.

10. Bài tập thực hành

  1. Yêu cầu Claude Code đề xuất nền tảng hosting phù hợp cho dự án của bạn và giải thích lý do.
  2. Kết nối kho Git của bạn với nền tảng đã chọn.
  3. Thiết lập biến môi trường cho các secrets đã chuẩn bị ở bài 62.
  4. Deploy lên Preview, tự tay thử lại toàn bộ tính năng chính.
  5. Thăng cấp lên Production — lưu lại URL công khai của dự án.
CHẶNG 3 · TỐI ƯU & BẢO TRÌ

Phần 3: Tối ưu & Checklist

Checklist kiểm tra mức độ sẵn sàng, nhận diện các bẫy sai lầm và nguyên tắc vàng vận hành.

11. Checklist

12. Lỗi thường gặp

⚠️ LƯU Ý QUAN TRỌNG
Deploy thẳng lên Production, bỏ qua Preview — mất bước kiểm tra quan trọng, lỗi có thể ảnh hưởng người dùng thật ngay lập tức.
⚠️ LƯU Ý QUAN TRỌNG
Copy trực tiếp secrets vào code “để deploy nhanh” thay vì dùng biến môi trường — đúng rủi ro đã cảnh báo ở bài 62.
⚠️ LƯU Ý QUAN TRỌNG
Quên rằng thay đổi biến môi trường không tự áp dụng cho deployment cũ đã tồn tại — cần deploy lại sau khi đổi biến môi trường quan trọng.
⚠️ LƯU Ý QUAN TRỌNG
Không lưu lại/nhớ URL Production — khó quay lại kiểm tra hoặc chia sẻ sản phẩm.

15. Best practices

Nguyên tắc 1
Luôn deploy qua Preview trước, thăng cấp lên Production sau khi đã kiểm tra kỹ.
Nguyên tắc 2
Thiết lập biến môi trường ngay khi deploy lần đầu, không để “tạm dùng giá trị test trong code rồi sửa sau.”
Nguyên tắc 3
Ghi lại URL Production ở nơi dễ tìm — đây sẽ là địa chỉ chính thức dùng lại ở bài 64 khi thêm tính năng mới.
16. Nội dung nâng cao (không bắt buộc)

Khả năng rollback (quay lại bản deploy trước) an toàn là 1 lớp bảo vệ bổ sung cho nguyên tắc “luôn có thể hoàn tác” đã học ở bài 57 (Checkpoint) — khác biệt quan trọng: Checkpoint hoàn tác thay đổi file trên máy bạn; rollback hoàn tác toàn bộ bản deploy đang chạy công khai — 2 cơ chế hoàn tác ở 2 tầng khác nhau của cùng 1 dự án.

Thông tin chuyên sâu & Nguồn tham khảo
⚠️ 13. Giới hạn & khi nào KHÔNG nên áp dụng
  • Bài này không dạy chọn nền tảng hosting “đúng nhất” cho mọi trường hợp — nhiều lựa chọn hợp lý khác nhau tồn tại, ví dụ trong bài chỉ mang tính minh họa, không phải khuyến nghị duy nhất.
  • Bài này không dạy vận hành production quy mô lớn (scaling, giám sát nâng cao, xử lý nhiều triệu người dùng) — vượt xa phạm vi 1 dự án cá nhân mới bắt đầu.
  • Với sản phẩm xử lý dữ liệu thật của nhiều người dùng, cần thêm các bước tuân thủ pháp lý/quyền riêng tư không nằm trong phạm vi bài này.
🔐 14. An toàn & quản trị (Safety/Governance)

Nguyên tắc bất biến của Level 6 áp dụng rõ nhất ở bài này: AI có thể thực hiện các bước deploy kỹ thuật, nhưng con người luôn là người xác nhận sản phẩm thật sự chạy được công khai trước khi coi là hoàn tất. Đặc biệt quan trọng: xác nhận secrets đã đúng vị trí (biến môi trường, không phải code) trước khi thăng cấp lên Production, không phải sau.

📚 17. Nguồn tham khảo

Deploying to Vercel + Environment Variables, Vercel (vercel.com/docs) — khái niệm deployment, 3 môi trường Local/Preview/Production, biến môi trường như cơ chế lưu secrets an toàn khi deploy. Nguồn đã được đối chiếu để thay thế đúng cách nguồn cũ S17 (chỉ nhắc Netlify/Supabase thoáng qua, không đủ chi tiết cho bài học độc lập) · Dẫn chiếu (không trích dẫn mới): bài 54 (Git), bài 56 (ranh giới dừng ở prototype cục bộ), bài 57 (Checkpoint, phân biệt với rollback), bài 62 (secrets, biến môi trường).