Ban đầu chỉ là một đường link
Mục tiêu ban đầu rất nhỏ: đặt một link affiliate cho ổ cứng gắn ngoài vào một bài viết thật để nền tảng affiliate có thể xét duyệt website.
Trang cần có nội dung hữu ích, disclosure rõ ràng về khả năng nhận hoa hồng trước link thương mại, và link phải hoạt động. Link đã được tạo, bài viết cũng đã được commit lên GitHub.
Sau đó vấn đề thật sự xuất hiện.
Code tồn tại trên GitHub không có nghĩa trang đã được xuất bản trên Internet.
Đường triển khai thường dùng qua GitHub Actions tạm thời không khả dụng. Một phương án khác là dùng Cloudflare Worker để chặn riêng URL đó và trả về trang khẩn cấp, nhưng trong điều kiện vận hành hiện tại, đường Worker cũng không dùng được.
Một link affiliate đã biến thành cuộc họp về CI, Workers, Pages, Git integration và Direct Upload.
Gần như chúng ta sắp xây “Sagrada Família Affiliate, tòa số 2”.
Khi tách rõ từng cơ chế deployment, bài toán trở nên đơn giản hơn nhiều.
1. Vì sao phải có trang public thật trước
Hướng dẫn onboarding của Sovrn Commerce cho content site và blog yêu cầu campaign triển khai link Commerce và tạo click trước khi campaign được review để phê duyệt.[3]
Nghĩa là quy trình không chỉ là “được duyệt rồi mới gắn link”. Người review cần nhìn thấy một implementation thực tế.
Sovrn cũng giải thích rằng trang chứa affiliate link phải thông báo rõ mối quan hệ bồi hoàn và disclosure nên xuất hiện trước link hoặc nội dung quảng bá.[4]
Một trang review cơ bản chỉ cần:
- có bài viết thật trên site đã đăng ký;
- bài viết có affiliate link;
- disclosure nằm trước link;
- URL public mở được;
- sau khi triển khai có thể tạo một vài click xác minh.
Điểm quan trọng là: file trong repository chưa phải là trang web public.
2. GitHub Actions không dùng được không có nghĩa Cloudflare Pages cũng không dùng được
GitHub Actions là hệ thống CI/CD của GitHub để chạy build, test và deploy.
Cloudflare Pages có Git integration riêng. Một project Pages có thể kết nối trực tiếp tới GitHub hoặc GitLab; khi có push vào repository đã kết nối, Cloudflare có thể tự build và deploy.[1]
Luồng có thể là:
push lên GitHub → Cloudflare Pages phát hiện commit → Cloudflare build → Cloudflare deploy
Luồng này không cần GitHub Actions workflow.
Vì vậy “không dùng được GitHub Actions” không đồng nghĩa với “không thể tự động xuất bản từ GitHub lên Cloudflare”.
Nếu GitHub Actions là băng chuyền bên trong kho, thì Cloudflare Git integration giống như đơn vị vận chuyển tự đến kho lấy hàng.
Băng chuyền dừng không có nghĩa xe lấy hàng cũng dừng.
3. Trước tiên phải xác định project Pages hiện tại thuộc loại nào
Cloudflare Pages có hai mô hình deployment chính.
| Mô hình | Trigger | Build/deploy ở đâu | Phù hợp khi |
|---|---|---|---|
| Git integration | push GitHub/GitLab | Cloudflare | repository là source of truth và muốn tự động deploy |
| Direct Upload | output đã build sẵn | Wrangler hoặc dashboard | build ở local/CI khác rồi upload kết quả |
Cloudflare ghi rõ một giới hạn quan trọng: project được tạo bằng Git integration không thể đơn giản chuyển thành project Direct Upload thông thường. Project đã tích hợp Git vẫn có thể được deploy thủ công bằng Wrangler, nhưng dashboard drag-and-drop không khả dụng cho project Git-integrated hiện hữu.[1][2]
Chiều ngược lại cũng bị giới hạn: project bắt đầu bằng Direct Upload không thể thêm Git integration trực tiếp vào cùng project. Muốn chuyển sang auto deployment qua Git thì phải tạo Pages project mới.[2]
Vì vậy câu hỏi đầu tiên không nên là “thử mẹo deploy nào?”
Mà là: “Pages project hiện tại là Git integration hay Direct Upload?”
Trả lời được câu này là loại bỏ một nửa mê cung.
4. Nếu là Git integration, không cần khôi phục GitHub Actions chỉ để deploy
Nếu repository đã được kết nối đúng với Cloudflare Pages, đường ngắn nhất không phải Worker hay một dịch vụ CI mới.
Hãy kiểm tra trong Pages project:
- đúng GitHub repository đã được kết nối;
- production branch đúng với branch thực sự dùng để xuất bản;
- automatic build cho branch đó chưa bị tắt;
- build command và output directory đúng với project hiện tại;
- sau push có deployment mới trong màn hình Deployments;
pages.devhiển thị nội dung mới;- custom domain cũng hiển thị cùng phiên bản.
Cloudflare Git integration được thiết kế để build và deploy từ commit của repository đã kết nối.[1]
Nếu luồng này còn hoạt động, hạn chế tạm thời của GitHub Actions không buộc ta xây lại kiến trúc deployment.
Trước khi đào thêm đường hầm khẩn cấp, hãy xem cửa chính có đang mở không.
5. Nếu là Direct Upload, deploy toàn bộ build output chứ không ném lên một trang thủ công
Direct Upload nhận assets đã được build trước. Cloudflare hỗ trợ Wrangler và dashboard drag-and-drop cho project Direct Upload.[2]
Một suy nghĩ rất hấp dẫn là: “Tôi chỉ sửa một bài, sao không upload đúng một file HTML?”
Với static site generator, đó thường là mô hình sai.
Đơn vị deployment là toàn bộ build output, không phải một source file vừa thay đổi. Build có thể tạo lại routing, CSS, JavaScript, search index, metadata và các assets khác.
Luồng an toàn hơn là:
lấy source mới nhất → chạy build của project → kiểm tra output directory → deploy toàn bộ output → kiểm tra URL thật
Với project Node, build có thể là pnpm build và output có thể nằm trong thư mục như dist.
Mục tiêu là tránh biến production thành một thế giới chỉnh tay khác hẳn repository.
6. Nếu Worker không dùng được, hãy xóa nó khỏi sơ đồ
Dùng Worker route để xử lý một URL khẩn cấp là ý tưởng khả thi về kỹ thuật.
Nhưng nếu môi trường hiện tại không cho phép Workers, giữ nó làm kế hoạch dự phòng chính chỉ tăng độ phức tạp.
Quyết định có thể thu nhỏ thành:
- GitHub Actions không khả dụng;
- Worker không khả dụng;
- dùng Pages Git integration hiện có hoặc đường Direct Upload hợp lệ.
Mười cửa thoát hiểm không nhất thiết tốt hơn một cánh cửa biết chắc là mở được.
Đừng xây cả một nền tảng deployment thứ hai chỉ để xuất bản một affiliate link.
7. “Đã publish” phải được chứng minh trên trang thật, không phải bằng commit SHA
Viết code, commit, build thành công và tạo deployment đều chỉ là mốc trung gian.
Kiểm tra cuối cùng phải diễn ra trên URL mà người đọc thật sự truy cập.
Với trang review affiliate, hãy xác minh:
- URL public mở được trong browser session sạch;
- nội dung mới nhất hiển thị;
- disclosure nằm trước affiliate link;
- product link đi đến đúng nơi;
- mobile không bị vỡ;
- nếu cần, tạo vài click xác minh;
- kiểm tra traffic hoặc trạng thái review trên Sovrn.
Sovrn mô tả flow content/blog là implementation, click generation rồi mới review.[3]
Vì vậy điểm bắt đầu không phải “đã vào GitHub”. Điểm bắt đầu là implementation live mà reviewer có thể nhìn thấy.
8. Khi mở rộng quy mô, đừng hard-code affiliate URL vào nội dung biên tập
Một link thủ công thì ổn.
Hàng trăm hoặc hàng nghìn bài thì khác. Nếu mỗi bài đều phải quyết định bằng tay có monetize hay không, đặt ở đâu, sản phẩm nào và thị trường nào, content factory sẽ mọc thêm một ad factory bên cạnh.
Tốt hơn là tách editorial content khỏi commercial metadata.
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Sau đó flow có thể là:
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
Bài viết vẫn là tài sản dài hạn. Product URL, stock, merchant và country routing trở thành các linh kiện có thể thay thế.
Hệ thống affiliate nên giống đường ống thương mại gắn vào bài viết, chứ không phải bê tông trộn vào móng bài viết.
9. Kết luận: khi CI không dùng được, hãy tìm đúng lối vào Cloudflare trước khi xây thêm lâu đài
Mọi chuyện bắt đầu từ một affiliate link HDD.
Link đã có. Disclosure đã có. Source đã ở GitHub.
Nhưng CI thông thường không dùng được, Worker cũng không dùng được.
Nếu tiếp tục thêm cơ chế mới, mục tiêu sẽ biến từ “publish một link” thành “xây một nền tảng deployment khác”.
Decision tree hữu ích thực ra rất nhỏ:
- nếu Pages hiện tại dùng Git integration, dùng native Git build của Cloudflare;
- nếu là Direct Upload, build toàn bộ site và deploy toàn bộ output qua đường được hỗ trợ;
- nếu Worker không dùng được, bỏ khỏi lựa chọn;
- đừng gọi Git commit là production deployment;
- kiểm tra disclosure, link, rendering và click trên URL public thật.
Kiến trúc nguy hiểm nhất không phải kiến trúc có quá ít lựa chọn.
Mà là kiến trúc giữ mãi những lựa chọn đã không còn sử dụng được trên sơ đồ.
