Ban đầu chỉ định gắn một đường link
Nói ngắn gọn: bạn không cần GitHub Actions để đưa trang lên Cloudflare Pages. Nếu project Pages đã kết nối với GitHub, mỗi lần bạn push code, Cloudflare sẽ tự build và tự deploy. Nếu là project kiểu Direct Upload (tải lên trực tiếp), bạn build toàn bộ trang rồi tải kết quả lên bằng Wrangler. Đây là chuyện mình đi vòng khá xa mới hiểu ra.
Việc cần làm thật ra rất nhỏ. Để qua vòng duyệt website của một chương trình tiếp thị liên kết (affiliate), mình cần gắn đúng một link sản phẩm ổ cứng di động vào một bài viết thật. Ngay trước link có ghi rõ: "Trang này có link affiliate. Chủ trang có thể nhận hoa hồng nếu bạn mua qua link." Tạo link, chèn vào bài, commit lên GitHub.
Xong rồi, mình nghĩ vậy.
Nhưng code vừa lên GitHub thì một hiểu lầm lộ ra.
Code nằm trên GitHub không có nghĩa là trang đã lên mạng.
GitHub Actions mình hay dùng lần này không dùng được. Có người gợi ý: chặn riêng URL đó bằng Cloudflare Worker rồi trả trang về từ đó. Nhưng với điều kiện sử dụng lần này, cách đó cũng không làm được.
Chỉ muốn gắn một link, mà tự nhiên thành một cuộc họp deploy: "CI thì sao? Worker thì sao? Pages đang nối với Git hay là Direct Upload?"
Thế là công trình "Sagrada Família affiliate, tòa số 2" khởi công.
Nhưng khi tách từng phần ra xem, mọi thứ bỗng đơn giản hơn nhiều.
1. Vì sao phải có một trang công khai trước
Sovrn Commerce hướng dẫn các trang nội dung và blog: trước tiên hãy gắn link Commerce lên trang đã đăng ký và tạo ra vài lượt click. Sau đó chiến dịch mới được đưa vào duyệt.[3]
Tức là không phải "duyệt xong rồi mới gắn link". Người duyệt phải được thấy trước một ví dụ thật đang hoạt động.
Sovrn cũng yêu cầu mỗi trang có link affiliate phải nói rõ với người đọc rằng bạn có thể kiếm tiền từ link đó. Lời thông báo này phải hiện ra trước link hoặc nội dung quảng bá.[4]
Không cần một trang so sánh sản phẩm hoành tráng. Điều kiện rất ngắn:
- có một bài viết thật trên trang đã đăng ký;
- bài đó có link affiliate;
- lời thông báo hiện trước link;
- ai cũng mở được trang qua URL công khai;
- sau khi đăng, có thể tạo vài lượt click để kiểm tra.
Điểm quan trọng nằm ở mục áp chót: file trong kho GitHub chưa phải là trang công khai.
2. GitHub Actions ngừng không có nghĩa Cloudflare Pages cũng ngừng
GitHub Actions là công cụ tự động hóa (CI/CD) có sẵn của GitHub. Nó chạy build, test và deploy ngay trong GitHub.
Còn Cloudflare Pages có tính năng kết nối Git riêng. Bạn nối project Pages thẳng với GitHub hoặc GitLab, và mỗi lần push lên kho đó, Cloudflare tự build và tự deploy.[1]
Quy trình như sau:
push lên GitHub → Cloudflare Pages phát hiện commit mới → Cloudflare build → Cloudflare deploy
Trong chuỗi này không hề có workflow GitHub Actions nào.
Đây là điểm mấu chốt. "Không dùng được GitHub Actions" khác với "GitHub không thể đưa trang lên Cloudflare". Đó là hai chuyện khác nhau.
Hình dung thế này: GitHub Actions là băng chuyền trong kho của bạn. Còn tính năng kết nối Git của Cloudflare là shipper tự đến tận nơi lấy hàng.
Băng chuyền có dừng thì shipper vẫn đến lấy như thường.
3. Việc đầu tiên: xem project Pages của bạn thuộc loại nào
Bỏ qua bước này là Cloudflare Pages biến thành mê cung rất nhanh.
Có hai cách đăng trang chính:
| Loại | Kích hoạt bằng gì | Ai build và deploy | Hợp với trường hợp |
|---|---|---|---|
| Kết nối Git (Git integration) | push lên GitHub / GitLab | Cloudflare | lấy kho code làm chuẩn và muốn tự động đăng |
| Direct Upload (tải lên trực tiếp) | file đã build sẵn | Wrangler hoặc bảng điều khiển | build trên máy mình hoặc CI khác rồi tải kết quả lên |
Tài liệu chính thức của Cloudflare ghi rõ: project tạo bằng kết nối Git thì sau này không đổi thành project Direct Upload thông thường được. Project đã nối Git vẫn có thể deploy thủ công bằng Wrangler, nhưng không dùng được tính năng kéo thả trên bảng điều khiển.[1][2]
Ngược lại cũng vậy. Project bắt đầu bằng Direct Upload thì sau này không thêm kết nối Git vào chính project đó được. Muốn deploy tự động từ Git thì phải tạo project Pages mới.[2]
Vì vậy câu hỏi đầu tiên không phải là "deploy thế nào?".
Mà là: "Project Pages hiện tại của mình là kết nối Git hay Direct Upload?"
Trả lời được câu này, một nửa lựa chọn tự loại.
4. Nếu là kết nối Git, không cần cứu GitHub Actions chỉ để deploy
Nếu kho GitHub đã nối đúng với Cloudflare Pages, đường nhanh nhất không phải Worker, cũng không phải một CI mới.
Kiểm tra mấy điều này trong project Pages:
- đang nối đúng kho GitHub;
- nhánh production đúng là nhánh bạn muốn đăng;
- build tự động của nhánh production không bị tạm dừng;
- lệnh build và thư mục đầu ra khớp với project hiện tại;
- sau khi push, màn hình Deployments của Pages có bản deploy mới;
- nội dung mới hiện trên địa chỉ
pages.dev; - cuối cùng, tên miền riêng của bạn cũng hiện đúng nội dung mới đó.
Tính năng kết nối Git của Cloudflare build và deploy dựa trên commit ở nhánh đã nối.[1]
Nên dù GitHub Actions tạm thời không dùng được, chỉ cần bản build của chính Cloudflare còn chạy là trang vẫn cập nhật được.
Việc cần làm lúc này không phải dựng thêm một hệ thống phức tạp. Mà là xem "cửa nhận hàng" của Cloudflare có đang mở không.
5. Nếu là Direct Upload, tải lên cả bộ build chứ không ném lên một trang lẻ
Direct Upload nghĩa là giao cho Cloudflare Pages một bộ file tĩnh hoàn chỉnh. Tài liệu chính thức hướng dẫn cách tải file đã build lên bằng Wrangler hoặc bảng điều khiển.[2]
Lúc này dễ nảy ra một lối tắt nguy hiểm:
"Mình chỉ sửa một bài. Sao không tải mỗi file HTML đó lên thôi?"
Nếu trang tĩnh của bạn được build nguyên khối, tốt nhất đừng làm vậy.
Thứ được deploy không phải "một file đã sửa trong Git", mà là toàn bộ kết quả build của trang tại thời điểm đó. Một lần build thường tạo lại cả danh sách trang, CSS, JavaScript, chỉ mục tìm kiếm, hình ảnh và quy tắc điều hướng. Nhét tay một trang vào là trang đang chạy không còn khớp với kho code.
Với Direct Upload, quy trình cơ bản là:
lấy bản mới nhất → chạy lệnh build của project → kiểm tra thư mục đầu ra → deploy toàn bộ đầu ra → mở URL thật để kiểm tra
Ví dụ trang tĩnh làm bằng Node thì chạy lệnh build của project như pnpm build, rồi tải lên thư mục được tạo ra như dist.
Điều quan trọng là đừng để trang chính thức thành một "thế giới song song" bí ẩn mà ai đó đã sửa tay.
6. Nếu không dùng được Worker, gạch nó khỏi kế hoạch
Khi cần đưa gấp một trang lên, dùng Worker chặn đường dẫn đó về lý thuyết là làm được.
Nhưng nếu điều kiện sử dụng không cho dùng Worker như lần này, thì xoay kế hoạch quanh nó chẳng có ý nghĩa gì.
Càng để nhiều đường "biết đâu dùng được" trên bản vẽ, về sau càng khó bảo trì.
- GitHub Actions: không dùng được
- Worker: không dùng được
- Vậy chọn một: kết nối Git của Cloudflare Pages hoặc Direct Upload
Vậy thôi.
Tìm ra cánh cửa chính đang mở nhanh hơn nhiều so với xây mười lối thoát hiểm.
Đừng dựng thêm một hệ thống deploy thứ hai chỉ để đăng một link affiliate.
Đó là bài học lớn nhất lần này.
7. "Đã đăng" phải được xác nhận trên trang thật, không phải bằng mã commit
Sai lầm kinh điển khi vận hành website là coi một bước giữa chừng là "xong".
- code đã viết xong
- đã commit lên GitHub
- build đã qua
- trên Cloudflare đã có bản deploy
Mấy điều đó đều quan trọng, nhưng người đọc chỉ thấy URL cuối cùng.
Với trang dùng để duyệt affiliate như lần này, bước kiểm tra cuối là:
- mở được URL công khai bằng cửa sổ ẩn danh;
- hiện đúng bản bài viết mới nhất;
- lời thông báo affiliate hiện trước link;
- link sản phẩm dẫn đến đúng trang;
- trên điện thoại hiển thị ổn;
- nếu cần, tạo vài lượt click để kiểm tra;
- xem số lượt click và trạng thái duyệt trong tài khoản Sovrn.
Sovrn mô tả quy trình cho chiến dịch nội dung/blog là: gắn link, tạo click, rồi duyệt.[3]
Nên "đã lên GitHub rồi, chờ duyệt thôi" là chưa đủ. Chỉ khi người duyệt thấy link thật chạy trên URL đang hoạt động, bạn mới đứng ở vạch xuất phát.
8. Về sau, đừng ghi cứng link affiliate vào thân bài
Gắn tay một link thì không sao.
Nhưng khi đã có hàng trăm, hàng nghìn bài, mà lần nào cũng phải có người quyết định "Bài này có gắn quảng cáo không? Gắn ở đâu? Sản phẩm gì? Cho nước nào?", thì bên cạnh xưởng nội dung sẽ mọc thêm một xưởng quảng cáo.
Bước tiếp theo là tách thân bài khỏi dữ liệu kiếm tiền.
Ví dụ mỗi bài chỉ cần một khối cài đặt nhỏ như sau:
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Rồi khi đăng bài, xử lý theo thứ tự này:
bài viết → quyết định có kiếm tiền không → chọn sản phẩm → tạo link affiliate → chèn vào khi tạo trang → đo kết quả
Thân bài giữ làm tài sản lâu dài. URL sản phẩm, tồn kho, cửa hàng, phân luồng theo quốc gia thành các bộ phận có thể thay bất cứ lúc nào.
Nhờ vậy, khi link hỏng hay đổi sản phẩm, bạn không phải lật lại thân bài ở cả 12 ngôn ngữ.
Link affiliate không phải là bài viết.
Hãy coi nó như một "đường ống bán hàng" nối vào bài viết sau. Về lâu dài sẽ vững hơn nhiều.
9. Kết luận: khi CI hỏng, hãy tìm đúng lối vào của Cloudflare trước khi xây thêm lâu đài
Chuyện lần này khá điển hình.
Ban đầu chỉ là: "Gắn một link ổ cứng để đi duyệt thôi."
Link đã có. Lời thông báo đã viết. Code đã lên GitHub.
Nhưng đến bước đăng chính thức, GitHub Actions không dùng được; định đi đường vòng bằng Worker cũng không xong.
Nếu lúc đó thêm một hệ thống mới, mục tiêu sẽ lặng lẽ chuyển từ "đăng một link" sang "mở rộng hệ thống deploy".
Rốt cuộc, chỉ cần quyết mấy điều này:
- project Pages hiện tại là kết nối Git thì để Cloudflare tự build;
- là Direct Upload thì build cả trang rồi tải lên kết quả build chính thức;
- không dùng được Worker thì gạch khỏi danh sách;
- đừng gọi commit trên GitHub là "đã đăng";
- kiểm tra lời thông báo, link, cách hiển thị và lượt click trên URL công khai thật.
Điều nguy hiểm nhất về kỹ thuật không phải là có quá ít lựa chọn.
Mà là để mãi trên bản vẽ những lựa chọn không dùng được.
