ตอนแรกแค่อยากวางลิงก์เดียว
ตอบสั้น ๆ: ไม่ต้องใช้ GitHub Actions ก็เผยแพร่เว็บบน Cloudflare Pages ได้ ถ้าโปรเจกต์ Pages เชื่อมกับ GitHub ไว้แล้ว ทุกครั้งที่ push โค้ด Cloudflare จะ build และ deploy ให้เอง ส่วนถ้าเป็นโปรเจกต์แบบ Direct Upload (อัปโหลดตรง) ก็ build เว็บทั้งชุดแล้วอัปโหลดผลลัพธ์ด้วย Wrangler นี่คือเรื่องที่ผมอ้อมไปไกลกว่าจะเข้าใจ
งานจริง ๆ เล็กมาก เพื่อให้ผ่านการตรวจเว็บของโปรแกรมแอฟฟิลิเอต ผมต้องวางลิงก์สินค้าฮาร์ดดิสก์พกพาแค่ลิงก์เดียวในบทความจริง ก่อนลิงก์มีข้อความบอกชัด ๆ ว่า "หน้านี้มีลิงก์แอฟฟิลิเอต ถ้าคุณซื้อผ่านลิงก์ เจ้าของเว็บอาจได้ค่าคอมมิชชัน" สร้างลิงก์ ใส่ในบทความ แล้ว commit ขึ้น GitHub
เสร็จแล้ว ผมคิดอย่างนั้น
แต่พอโค้ดขึ้น GitHub ปุ๊บ ความเข้าใจผิดก็โผล่มา
โค้ดอยู่บน GitHub ไม่ได้แปลว่าหน้าเว็บขึ้นออนไลน์แล้ว
GitHub Actions ที่ใช้ประจำ รอบนี้ใช้ไม่ได้ มีคนเสนอว่าให้ใช้ Cloudflare Worker ดักเฉพาะ URL นั้นแล้วส่งหน้าเว็บจากตรงนั้นแทน แต่ภายใต้เงื่อนไขการใช้งานรอบนี้ ทางนั้นก็ใช้ไม่ได้เหมือนกัน
แค่อยากวางลิงก์เดียว กลายเป็นประชุมเรื่อง deploy ไปซะงั้น: "CI ล่ะ? Worker ล่ะ? Pages เชื่อม Git หรือเป็น Direct Upload?"
โปรเจกต์ "ซากราดาฟามีเลียสายแอฟฟิลิเอต อาคาร 2" จึงเริ่มก่อสร้าง
แต่พอแยกดูทีละส่วน เรื่องกลับง่ายขึ้นเยอะ
1. ทำไมต้องมีหน้าเว็บที่เปิดได้จริงก่อน
Sovrn Commerce แนะนำเว็บคอนเทนต์และบล็อกว่า ให้วางลิงก์ Commerce บนเว็บที่สมัครไว้ก่อน แล้วสร้างคลิกสักหน่อย หลังจากนั้นแคมเปญถึงจะเข้าสู่การตรวจ[3]
แปลว่าไม่ใช่ "อนุมัติก่อนแล้วค่อยวางลิงก์" แต่ต้องให้ผู้ตรวจเห็นตัวอย่างจริงที่ใช้งานได้ก่อน
Sovrn ยังขอให้ทุกหน้าที่มีลิงก์แอฟฟิลิเอตบอกผู้อ่านให้ชัดว่าคุณอาจได้เงินจากลิงก์นั้น และข้อความนี้ต้องอยู่ก่อนลิงก์หรือเนื้อหาโปรโมต[4]
ไม่จำเป็นต้องมีเว็บเปรียบเทียบสินค้าหรูหรา เงื่อนไขสั้นนิดเดียว:
- มีบทความจริงบนเว็บที่สมัครไว้
- บทความนั้นมีลิงก์แอฟฟิลิเอต
- ข้อความแจ้งอยู่ก่อนลิงก์
- ใครก็เปิดหน้าได้ผ่าน URL สาธารณะ
- หลังเผยแพร่แล้ว สร้างคลิกทดสอบได้สักหน่อย
จุดสำคัญคือข้อรองสุดท้าย: ไฟล์ใน repository บน GitHub ยังไม่ใช่หน้าเว็บสาธารณะ
2. GitHub Actions ใช้ไม่ได้ ไม่ได้แปลว่า Cloudflare Pages ใช้ไม่ได้
GitHub Actions คือเครื่องมือทำงานอัตโนมัติ (CI/CD) ของ GitHub ใช้รัน build เทสต์ และ deploy อยู่ใน GitHub
ส่วน Cloudflare Pages มีระบบเชื่อม Git ของตัวเอง เชื่อมโปรเจกต์ Pages เข้ากับ GitHub หรือ GitLab ได้โดยตรง พอ push ขึ้น repository นั้นเมื่อไร Cloudflare ก็ build และ deploy เอง[1]
ขั้นตอนเป็นแบบนี้:
push ขึ้น GitHub → Cloudflare Pages เห็น commit ใหม่ → Cloudflare build → Cloudflare deploy
ในสายนี้ไม่มี workflow ของ GitHub Actions เลยสักตัว
ตรงนี้สำคัญ "ใช้ GitHub Actions ไม่ได้" กับ "GitHub ส่งเว็บขึ้น Cloudflare ไม่ได้" เป็นคนละเรื่องกัน
ลองนึกภาพว่า GitHub Actions คือสายพานในโกดังของเราเอง ส่วนระบบเชื่อม Git ของ Cloudflare คือบริษัทขนส่งที่มารับของถึงที่
สายพานหยุดได้ แต่รถขนส่งก็ยังมารับของตามปกติ
3. เรื่องแรก: ดูให้ชัดว่าโปรเจกต์ Pages ของคุณเป็นแบบไหน
ถ้าข้ามขั้นนี้ไป Cloudflare Pages จะกลายเป็นเขาวงกตเร็วมาก
วิธีเผยแพร่หลัก ๆ มีสองแบบ:
| แบบ | อะไรเป็นตัวเริ่ม | ใคร build และ deploy | เหมาะกับ |
|---|---|---|---|
| เชื่อม Git (Git integration) | push ขึ้น GitHub / GitLab | Cloudflare | ยึด repository เป็นหลักและอยากเผยแพร่อัตโนมัติ |
| Direct Upload (อัปโหลดตรง) | ไฟล์ที่ build เสร็จแล้ว | Wrangler หรือแดชบอร์ด | build บนเครื่องตัวเองหรือ CI อื่นแล้วอัปโหลดผลลัพธ์ |
เอกสารทางการของ Cloudflare เขียนไว้ชัดว่า โปรเจกต์ที่สร้างด้วยการเชื่อม Git จะเปลี่ยนเป็นโปรเจกต์ Direct Upload ธรรมดาทีหลังไม่ได้ โปรเจกต์ที่เชื่อม Git แล้วยัง deploy เองด้วย Wrangler ได้ แต่ใช้การลากแล้ววางบนแดชบอร์ดไม่ได้[1][2]
กลับกันก็เหมือนกัน โปรเจกต์ที่เริ่มเป็น Direct Upload จะเพิ่มการเชื่อม Git ทีหลังในโปรเจกต์เดิมไม่ได้ ถ้าอยาก deploy อัตโนมัติจาก Git ต้องสร้างโปรเจกต์ Pages ใหม่[2]
เพราะฉะนั้นคำถามแรกไม่ใช่ "จะ deploy ยังไง?"
แต่คือ: "โปรเจกต์ Pages ตอนนี้ของเราเป็นแบบเชื่อม Git หรือ Direct Upload?"
ตอบข้อนี้ได้ ตัวเลือกครึ่งหนึ่งก็ตัดทิ้งได้เลย
4. ถ้าเป็นแบบเชื่อม Git ไม่ต้องไปชุบชีวิต GitHub Actions เพื่อเผยแพร่
ถ้า repository บน GitHub เชื่อมกับ Cloudflare Pages ไว้ถูกต้องแล้ว ทางที่เร็วที่สุดไม่ใช่ Worker และไม่ใช่ CI ตัวใหม่
ให้เช็กเรื่องเหล่านี้ในโปรเจกต์ Pages:
- เชื่อมกับ repository บน GitHub ที่ถูกต้อง
- branch สำหรับ production เป็น branch ที่อยากเผยแพร่จริง ๆ
- การ build อัตโนมัติของ branch production ไม่ได้ถูกหยุดไว้
- คำสั่ง build และโฟลเดอร์ผลลัพธ์ตรงกับโปรเจกต์ปัจจุบัน
- หลัง push มี deploy ใหม่โผล่ในหน้า Deployments ของ Pages
- เห็นเนื้อหาใหม่ที่ที่อยู่
pages.dev - สุดท้าย โดเมนของคุณเองก็แสดงเนื้อหาใหม่เหมือนกัน
ระบบเชื่อม Git ของ Cloudflare ทำงานโดย build และ deploy จาก commit บน branch ที่เชื่อมไว้[1]
ดังนั้นต่อให้ GitHub Actions ใช้ไม่ได้ชั่วคราว ตราบใดที่การ build ของ Cloudflare เองยังทำงาน เว็บก็ยังอัปเดตได้
สิ่งที่ต้องทำตอนนี้ไม่ใช่สร้างระบบซับซ้อนเพิ่ม แต่คือดูว่า "จุดรับของ" ของ Cloudflare เปิดอยู่หรือเปล่า
5. ถ้าเป็น Direct Upload ให้อัปโหลดผล build ทั้งชุด ไม่ใช่โยนขึ้นไปหน้าเดียว
Direct Upload คือการส่งไฟล์เว็บแบบ static ที่เสร็จทั้งชุดให้ Cloudflare Pages เอกสารทางการอธิบายวิธีอัปโหลดไฟล์ที่ build แล้วด้วย Wrangler หรือผ่านแดชบอร์ด[2]
ตรงนี้มักมีทางลัดอันตรายโผล่มา:
"แก้แค่บทความเดียว อัปโหลดแค่ไฟล์ HTML นั้นไม่ได้เหรอ?"
ถ้าเว็บ static ของคุณ build ทั้งเว็บพร้อมกัน อย่าทำแบบนั้นดีกว่า
เพราะสิ่งที่ deploy ไม่ใช่ "ไฟล์เดียวที่แก้ใน Git" แต่เป็น ผล build ของทั้งเว็บ ณ ตอนนั้น การ build ครั้งหนึ่งมักสร้างรายการหน้า CSS, JavaScript ดัชนีค้นหา รูปภาพ และกฎการเปลี่ยนเส้นทางใหม่ไปพร้อมกัน ถ้ายัดหน้าเดียวเข้าไปเอง เว็บที่ออนไลน์อยู่ก็จะไม่ตรงกับ repository อีกต่อไป
ถ้าใช้ Direct Upload ขั้นตอนพื้นฐานคือ:
ดึงโค้ดล่าสุด → รันคำสั่ง build ของโปรเจกต์ → เช็กโฟลเดอร์ผลลัพธ์ → deploy ผลลัพธ์ทั้งหมด → เปิด URL จริงเพื่อตรวจ
เช่น เว็บ static ที่ทำด้วย Node ก็รันคำสั่ง build ของโปรเจกต์อย่าง pnpm build แล้วอัปโหลดโฟลเดอร์ที่ได้อย่าง dist
ที่สำคัญคืออย่าปล่อยให้เว็บจริงกลายเป็น "โลกคู่ขนานลึกลับที่มีใครแก้ไฟล์ด้วยมือ"
6. ถ้า Worker ใช้ไม่ได้ ก็ตัดทิ้งจากแผนไปเลย
เวลาต้องเผยแพร่หน้าเดียวด่วน ๆ การใช้ Worker ดักเส้นทางนั้นก็ทำได้ในทางทฤษฎี
แต่ถ้าเงื่อนไขการใช้งานไม่อนุญาตให้ใช้ Worker อย่างรอบนี้ การวางแผนวนรอบมันก็ไม่มีประโยชน์
ยิ่งเก็บทาง "เผื่อจะใช้ได้" ไว้ในแบบแปลนมากเท่าไร ดูแลทีหลังก็ยิ่งยาก
- GitHub Actions: ใช้ไม่ได้
- Worker: ใช้ไม่ได้
- งั้นเลือกหนึ่งอย่าง: เชื่อม Git ของ Cloudflare Pages หรือ Direct Upload
แค่นั้นเอง
หาประตูหลักที่เปิดอยู่บานเดียวให้เจอ เร็วกว่าสร้างทางหนีไฟสิบทาง
อย่าสร้างระบบ deploy ชุดที่สองแค่เพื่อเผยแพร่ลิงก์แอฟฟิลิเอตลิงก์เดียว
นี่คือบทเรียนใหญ่ที่สุดของรอบนี้
7. "เผยแพร่แล้ว" ต้องยืนยันที่หน้าจริง ไม่ใช่ดูจากรหัส commit
ความผิดพลาดคลาสสิกของการดูแลเว็บ คือการนับขั้นตอนระหว่างทางว่า "เสร็จแล้ว"
- เขียนโค้ดเสร็จแล้ว
- commit ขึ้น GitHub แล้ว
- build ผ่านแล้ว
- มี deploy โผล่บน Cloudflare แล้ว
ทั้งหมดนี้สำคัญ แต่ผู้อ่านเห็นแค่ URL สุดท้าย
สำหรับหน้าที่ใช้ตรวจแอฟฟิลิเอตแบบรอบนี้ ขั้นเช็กสุดท้ายคือ:
- เปิด URL สาธารณะในหน้าต่างไม่ระบุตัวตนได้
- แสดงบทความเวอร์ชันล่าสุด
- ข้อความแจ้งแอฟฟิลิเอตอยู่ก่อนลิงก์
- ลิงก์สินค้าพาไปหน้าที่ถูกต้อง
- แสดงผลบนมือถือได้ดี
- ถ้าจำเป็น สร้างคลิกทดสอบสักหน่อย
- ดูจำนวนคลิกและสถานะการตรวจในบัญชี Sovrn
Sovrn อธิบายขั้นตอนของแคมเปญสายคอนเทนต์/บล็อกว่า วางลิงก์ สร้างคลิก แล้วค่อยตรวจ[3]
เพราะฉะนั้น "ขึ้น GitHub แล้ว รอตรวจเลย" ยังไม่พอ จะยืนอยู่บนเส้นสตาร์ตได้ ก็ต่อเมื่อผู้ตรวจเห็นลิงก์จริงทำงานบน URL ที่ออนไลน์อยู่
8. ต่อไป อย่าฝังลิงก์แอฟฟิลิเอตตายตัวไว้ในเนื้อบทความ
ลิงก์เดียววางเองก็ไม่มีปัญหา
แต่พอบทความมีเป็นร้อยเป็นพัน แล้วต้องมีคนตัดสินใจทุกครั้งว่า "บทความนี้ใส่โฆษณาไหม? ใส่ตรงไหน? สินค้าอะไร? สำหรับประเทศไหน?" ข้าง ๆ โรงงานคอนเทนต์ก็จะงอกโรงงานโฆษณาขึ้นมาอีกโรง
ขั้นต่อไปคือแยกเนื้อบทความออกจากข้อมูลสร้างรายได้
เช่น ในบทความใส่แค่บล็อกตั้งค่าเล็ก ๆ แบบนี้:
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
แล้วตอนเผยแพร่ค่อยทำตามลำดับนี้:
บทความ → ตัดสินว่าจะสร้างรายได้ไหม → เลือกสินค้า → สร้างลิงก์แอฟฟิลิเอต → แทรกตอนสร้างหน้าเว็บ → วัดผล
เนื้อบทความเก็บไว้เป็นสินทรัพย์ระยะยาว ส่วน URL สินค้า สต็อก ร้านค้า และการแยกตามประเทศ ทำเป็นชิ้นส่วนที่เปลี่ยนได้ตลอด
แบบนี้เวลาลิงก์เสียหรือเปลี่ยนสินค้า ก็ไม่ต้องรื้อเนื้อหาทั้ง 12 ภาษา
ลิงก์แอฟฟิลิเอตไม่ใช่ตัวบทความ
ให้มองมันเป็น "ท่อขายของ" ที่ต่อเข้ากับบทความทีหลัง ดูแลระยะยาวจะมั่นคงกว่าเยอะ
9. สรุป: เมื่อ CI พัง อย่าเพิ่งสร้างปราสาทใหม่ ให้หาทางเข้าจริงของ Cloudflare ก่อน
เรื่องรอบนี้เป็นตัวอย่างที่ดีมาก
ตอนแรกแค่: "วางลิงก์ฮาร์ดดิสก์สักลิงก์เพื่อให้ผ่านการตรวจ"
ลิงก์ทำเสร็จ ข้อความแจ้งเขียนเสร็จ โค้ดก็ขึ้น GitHub แล้ว
แต่พอถึงขั้นขึ้นออนไลน์จริง GitHub Actions ใช้ไม่ได้ จะอ้อมด้วย Worker ก็ไม่ได้อีก
ถ้าตอนนั้นเพิ่มระบบใหม่เข้าไปอีก เป้าหมายจะค่อย ๆ เปลี่ยนจาก "เผยแพร่ลิงก์เดียว" เป็น "ขยายระบบ deploy" โดยไม่รู้ตัว
สุดท้ายแล้ว สิ่งที่ต้องตัดสินใจมีแค่นี้:
- ถ้าโปรเจกต์ Pages เป็นแบบเชื่อม Git ก็ให้ Cloudflare build เอง
- ถ้าเป็น Direct Upload ให้ build ทั้งเว็บแล้วอัปโหลดผล build ตัวจริง
- ถ้า Worker ใช้ไม่ได้ ก็ตัดออกจากตัวเลือก
- อย่าเรียก commit บน GitHub ว่า "เผยแพร่แล้ว"
- เช็กข้อความแจ้ง ลิงก์ การแสดงผล และคลิกบน URL สาธารณะจริง
สิ่งที่อันตรายที่สุดทางเทคนิคไม่ใช่การมีตัวเลือกน้อย
แต่คือการปล่อยตัวเลือกที่ใช้ไม่ได้ค้างไว้ในแบบแปลนตลอดไป
