สิทธิพิเศษที่ระบุไว้อย่างชัดเจนล่วงหน้า
ก่อนที่คุณจะสร้างโทเค็น เราจะแจ้งให้คุณทราบว่าโทเค็นต้องทำอะไรได้บ้างและเพราะเหตุใด จะไม่มีการกำหนดขอบเขตแบบครอบคลุมเพียงเพราะของ่ายกว่า และไม่มีการมารู้ทีหลังว่าเราต้องการมากกว่าที่งานจำเป็นต้องใช้
การควบคุมต้นฉบับ
เชื่อมต่อบัญชี GitHub หรือ GitLab ที่คุณใช้งานและปรับใช้ได้โดยตรงจากสาขา: ไปยัง Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps หรือ AWS Amplify — หรือบนโฮสติ้งที่มีการจัดการของเราเอง ซึ่งพื้นที่เก็บข้อมูลและไฟล์ของไซต์จะซิงค์กันทั้งสองทิศทาง ทุกการเชื่อมต่อจะแสดงสิทธิ์การเข้าถึงที่จำเป็น ได้รับการตรวจสอบกับ API ของผู้ให้บริการก่อนที่จะจัดเก็บ และจัดเก็บไว้ใน Vault คุณยังสามารถเข้าสู่ระบบด้วย GitHub หรือ GitLab ได้เช่นกัน
การเชื่อมต่อคือข้อมูลรับรองที่คุณมอบให้ผู้อื่น ระบบของเราจะแจ้งสิ่งที่จำเป็นต้องใช้ก่อนที่คุณจะสร้าง พิสูจน์ว่าใช้งานได้จริงก่อนที่จะจัดเก็บ และสามารถเพิกถอนสิทธิ์ได้จากทั้งสองฝ่าย
ก่อนที่คุณจะสร้างโทเค็น เราจะแจ้งให้คุณทราบว่าโทเค็นต้องทำอะไรได้บ้างและเพราะเหตุใด จะไม่มีการกำหนดขอบเขตแบบครอบคลุมเพียงเพราะของ่ายกว่า และไม่มีการมารู้ทีหลังว่าเราต้องการมากกว่าที่งานจำเป็นต้องใช้
เราเรียกใช้ API ของผู้ให้บริการโดยตรงด้วยโทเคนของคุณก่อนที่จะจัดเก็บ โทเคนที่ผิด หมดอายุ หรือมีขอบเขตไม่ถูกต้องจะถูกปฏิเสธตั้งแต่ในแบบฟอร์ม แทนที่จะได้รับการยอมรับ แสดงสถานะว่าสมบูรณ์ดี แล้วไปล้มเหลวในการปรับใช้จริงครั้งแรก
ไม่อยู่ในโค้ดของเรา ไม่อยู่ในไฟล์สภาพแวดล้อม ไม่อยู่ในบันทึก และไม่อยู่ในบรรทัดคำสั่ง ได้รับการแก้ไขในขณะที่มีการใช้งาน โดยเวิร์กโหลดที่ใช้งานมัน
เชื่อมต่อบัญชีส่วนตัวและบัญชีขององค์กร หรือของสององค์กร แต่ละไซต์จะเลือกว่าจะปรับใช้จากบัญชีใด ดังนั้นที่เก็บข้อมูลของไคลเอนต์และของคุณจึงไม่เคยใช้ข้อมูลประจำตัวร่วมกัน
โฮสต์เอดจ์ที่มีการจัดการแปดแห่งและฟลีตของเราเอง ปลายทางเป็นคุณสมบัติของไซต์ ไม่ใช่ของการเชื่อมต่อ ดังนั้นที่เก็บเดียวกันจึงสามารถเผยแพร่หนึ่งสาขาไปยังโฮสต์ Pages ได้ และอีกไซต์หนึ่งสามารถทำงานบนฮาร์ดแวร์ของเราได้
แบนด์วิดท์ไม่จำกัด อนุญาตให้ใช้งานในเชิงพาณิชย์ และจัดการเอเพ็กซ์โดเมนบนผู้ให้บริการรายเดียวกับที่ดูแลโซน DNS ของคุณเป็นปกติ ด้วยเหตุผลเหล่านี้ จึงเป็นจุดหมายแรกที่เราเลือกใช้
โฮสติ้ง Cloudflare Pages →เผยแพร่ได้โดยตรงจากที่เก็บข้อมูลที่โค้ดมีอยู่แล้ว มีการแจ้งเตือนในบรรทัด Footprint-Free เนื่องจากโครงสร้างพื้นฐาน github.io ที่ใช้ร่วมกันนั้นถือเป็นร่องรอยการเชื่อมโยงในตัวเอง
โฮสติ้ง GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps และ AWS Amplify ล้วนเป็นปลายทางที่คุณสามารถชี้ไซต์ไปหาได้ ด้วยการเชื่อมต่อและประวัติการปรับใช้เดียวกัน
โฮสติ้งเว็บไซต์แบบสแตติก →แอปพลิเคชันเต็มรูปแบบแทนที่จะเป็นชุดบันเดิลที่บิลด์แล้ว — WordPress, PHP, Node นี่คือปลายทางที่ได้รับการซิงค์แบบสองทาง ไฟล์บนเซิร์ฟเวอร์และแบรนช์จึงตรงกันอยู่เสมอ
โฮสติ้งที่มีการจัดการ →ไซต์ที่เผยแพร่ไปยังโฮสต์ที่เราไม่ได้เป็นเจ้าของจะยังคงใช้โควตาที่กำหนดไว้ และยังคงปรากฏในแดชบอร์ดของคุณพร้อมกับการดีพลอย สถานะเวลาทำงาน และข้อมูล SEO ควบคู่ไปกับทุกสิ่งที่คุณใช้งาน
โควตาไซต์ภายนอก →โปรแกรมแก้ไขในเบราว์เซอร์จะทำงานบนไฟล์เดียวกันกับที่การซิงค์แบบสองทางส่งกลับ ดังนั้นการแก้ไขด่วนจากแดชบอร์ดจึงกลายเป็นคอมมิตบนสาขาของคุณ แทนที่จะเป็นการเปลี่ยนแปลงที่ไม่มีใครหาพบในภายหลัง
ตัวแก้ไขเว็บ →การซิงค์แบบสองทาง
เปิดใช้งานแล้วไฟล์ของไซต์เองจะถูกคอมมิตกลับไปยังแบรนช์ของคุณ ในขณะที่คอมมิตบนแบรนช์นั้นจะส่งกลับมายังไซต์ ฟังก์ชันนี้ใช้งานได้กับทุกไซต์ที่เราโฮสต์ในทุกสายการผลิต โดยมีข้อกำหนดเพียงอย่างเดียวคือเครื่องเบื้องหลังต้องสามารถรัน Git กับไฟล์ของเครื่องได้ ซึ่งเป็นการตรวจสอบจากเซิร์ฟเวอร์โดยตรงแทนที่จะอนุมานจากแพ็กเกจ
คุณเป็นผู้เลือกว่าจะซิงค์ไดเรกทอรีใด เนื่องจากลูกค้า WordPress ต้องการติดตามธีมของตน ไม่ใช่ไฟล์หลักสี่หมื่นไฟล์ และระบบจะปิดอยู่จนกว่าคุณจะเปิดใช้งาน: การเปิดใช้งานการซิงค์เป็นการตัดสินใจเกี่ยวกับที่เก็บข้อมูลของผู้อื่น และการย้ายข้อมูลจะต้องไม่ตัดสินใจแทนคุณโดยเด็ดขาด
สองโหมด และความแตกต่างคือตำแหน่งที่บิลด์ทำงาน ทั้งสองสิ้นสุดที่ตำแหน่งเดียวกัน: เรฟที่เราดึงข้อมูลและเผยแพร่ โดยมีคอมมิตที่บันทึกไว้เทียบกับการปรับใช้
GitHub หรือ GitLab ภายใต้การเชื่อมต่อ สิทธิ์จะแสดงรายการก่อนที่คุณจะสร้างโทเค็น และจะได้รับการตรวจสอบกับผู้ให้บริการก่อนที่จะจัดเก็บ
เจ้าของ, ที่เก็บโค้ด (repository), สาขา (branch) และเลือกว่าจะให้เราเผยแพร่ไดเรกทอรีหรือดึงข้อมูลสิ่งที่ CI ของคุณสร้างขึ้น เราจะลงทะเบียน push webhook ให้โดยเป็นส่วนหนึ่งของขั้นตอนนี้
การ push ไปยัง branch ที่กำหนดจะเริ่มการปรับใช้ หรือคุณสามารถปรับใช้ตามความต้องการได้จากแท็บปรับใช้ของไซต์ การบิลด์จะทำงานในพื้นหลัง
ประวัติการปรับใช้จะแสดงว่ามีสิ่งใดถูกเผยแพร่และเมื่อใด เปิดการซิงค์แบบสองทางแล้วการแก้ไขที่คุณทำที่นี่จะส่งกลับไปเป็นคอมมิตบนสาขาของคุณ
เมื่อเกิดข้อผิดพลาด
การเชื่อมต่อที่เก็บข้อมูลที่ดูเหมือนทำงานได้ดีแต่ไม่ได้รับสิ่งใดเลยคือข้อผิดพลาดเงียบแบบคลาสสิก — โทเค็นที่มีขอบเขตไม่ถูกต้อง การส่งข้อมูลที่ถูกบล็อกที่ผู้ให้บริการ เว็บฮุกที่ใครบางคนนำออกด้วยตนเอง ปัญหานี้มองไม่เห็นบนหน้าจออื่น ๆ การ์ดที่เก็บข้อมูลจึงแสดงข้อมูลนี้โดยตรง: เมื่อผู้ให้บริการส่งข้อมูลให้เราล่าสุด และระบุว่าอย่างไร
รายการส่งมอบจะได้รับการตรวจสอบลายเซ็นก่อนที่เราจะดำเนินการ โดยใช้รูปแบบของผู้ให้บริการแต่ละราย แทนที่จะเป็นรูปแบบที่เราสันนิษฐานว่าใช้ได้กับทุกราย รายการส่งมอบที่ไม่ผ่านการตรวจสอบจะถูกปฏิเสธและบันทึกไว้ ไม่ใช่ถูกเพิกเฉยไปอย่างเงียบ ๆ
ข้อมูลประจำตัว
นอกเหนือจากที่อยู่อีเมลและรหัสผ่านแล้ว คุณยังสามารถลงชื่อเข้าใช้บัญชี Zinn Digital® ของคุณด้วย GitHub, GitLab, Google หรือ Microsoft ได้ เลเยอร์ระบุตัวตนจะดำเนินการแฮนด์เชก (handshake) โดยเราจะไม่เห็นรหัสผ่านของผู้ให้บริการของคุณโดยเด็ดขาด และการเชื่อมโยงบัญชีโซเชียลกับบัญชี Zinn® ที่มีอยู่ยังคงต้องได้รับการยืนยันทางอีเมล
การลงชื่อเข้าใช้ด้วย GitHub และการเชื่อมต่อ GitHub สำหรับการปรับใช้นั้นเป็นการตัดสินใจแยกต่างหากและเป็นข้อมูลประจำตัวที่แยกจากกัน การดำเนินการอย่างใดอย่างหนึ่งไม่ได้ส่งผลให้อีกอย่างทำงาน และการลบอย่างใดอย่างหนึ่งไม่ได้เป็นการลบอีกอย่างหนึ่งออกไปด้วย
GitHub และ GitLab เชื่อมต่อบัญชีที่คุณใช้งานอยู่แล้ว และเราสามารถนำโค้ดไปใช้งานจากที่เก็บข้อมูลเหล่านั้น ลงทะเบียน push webhook ให้กับที่เก็บข้อมูลดังกล่าว และ — หากคุณต้องการ — ซิงค์ไฟล์ของไซต์คุณกลับไปอีกทางหนึ่งได้ ทั้งสองอย่างดำเนินการผ่านส่วนเชื่อมโยงบัญชีเดียวกัน ดังนั้นข้อมูลทั้งหมดด้านล่างจึงเป็นจริงสำหรับทั้งสองบริการ
ใช่ และใช้ Google หรือ Microsoft ได้เช่นกัน นอกจากที่อยู่อีเมลและรหัสผ่านแล้ว คุณยังสามารถลงชื่อเข้าใช้บัญชี Zinn Digital® ของคุณด้วยตัวเลือกใดก็ได้ในสี่ตัวเลือกนี้ เลเยอร์ระบุตัวตนจะจัดการการสื่อสารเชื่อมต่อ และเราจะไม่เห็นรหัสผ่านของผู้ให้บริการของคุณ การลงชื่อเข้าใช้ด้วย GitHub เป็นคนละส่วนกับการเชื่อมต่อ GitHub เพื่อการปรับใช้ — คุณสามารถเลือกทำอย่างใดอย่างหนึ่ง ทำทั้งสองอย่าง หรือไม่ทำเลยก็ได้
ไปยัง Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps หรือ AWS Amplify สำหรับไซต์แบบคงที่หรือไซต์ที่ผ่านการบิลด์ — หรือบนโฮสติ้งที่มีการจัดการของเราเอง ซึ่งที่เก็บโค้ดและไฟล์ของไซต์จะซิงค์กันอยู่เสมอในทั้งสองทิศทาง คุณเป็นผู้เลือกปลายทางสำหรับไซต์ ส่วนการเชื่อมต่อกับที่เก็บโค้ดจะเหมือนกันในทั้งสองกรณี
แบบใดก็ได้ ในโหมดเผยแพร่ เราจะใช้บรันช์ตามที่เป็นอยู่และเผยแพร่ไดเรกทอรีที่คุณระบุ ในโหมด CI ไปป์ไลน์ของผู้ให้บริการของคุณจะเรียกใช้คำสั่งบิลด์ของคุณ และคอมมิตเอาต์พุตไปยังบรันช์เผยแพร่ที่แยกต่างหาก ซึ่งเราจะดึงข้อมูลเช่นเดียวกับ ref อื่นๆ วิธีที่สองจะเก็บการบิลด์ของคุณไว้ใน CI ของคุณเอง ซึ่งเป็นที่ที่ข้อมูลลับและการแคชของคุณมีอยู่แล้ว
ตามค่าเริ่มต้นคือใช่ — เราจะลงทะเบียนเว็บฮุกบนที่เก็บข้อมูล และการพุชไปยังสาขาที่คุณระบุจะเริ่มต้นการปรับใช้ คุณสามารถปิดส่วนนั้นและคงเว็บฮุกไว้ได้ ซึ่งมีประโยชน์มากกว่าที่คิด: ระบบยังคงบันทึกการนำส่งอยู่ คุณจึงสามารถดูการพุชของคุณที่เข้ามาได้ก่อนที่จะอนุญาตให้เราดำเนินการกับข้อมูลเหล่านั้น
การแก้ไขที่ทำบนฮาร์ดแวร์ของเราจะกลายเป็นคอมมิตบนสาขาของคุณ และคอมมิตบนสาขาของคุณจะส่งกลับไปยังไซต์ ฟังก์ชันนี้จะปิดอยู่จนกว่าคุณจะเปิดใช้งาน เนื่องจากการเปิดใช้งานคือการตัดสินใจเกี่ยวกับที่เก็บของผู้อื่น และเราจะไม่ตัดสินใจแทนคุณ คุณเป็นผู้เลือกไดเรกทอรีที่จะซิงค์ ซึ่งโดยปกติแล้วจะเป็นธีมหรือปลั๊กอิน ไม่ใช่ไฟล์หลักของ WordPress จำนวนสี่หมื่นไฟล์
ไม่มีสิ่งใดถูกเขียนทับและไม่มีสิ่งใดถูกพุช การซิงค์จะหยุดลง แจ้งให้คุณทราบว่าสาขาได้ก้าวล่วงหน้าเกินกว่าคอมมิตที่เราใช้อ้างอิงแล้ว และถามว่าคุณต้องการฝั่งใด — เก็บที่เก็บข้อมูลไว้ หรือเก็บไซต์ไว้ ไซต์ที่ไม่เคยซิงค์และชี้ไปยังสาขาที่มีคอมมิตอยู่แล้วก็เป็นอีกสถานะหนึ่งเช่นกัน และระบบจะถามแทนที่จะคาดเดาว่าฝ่ายใดถูกต้อง
เราจะแสดงสิทธิ์ที่การเชื่อมต่อต้องการให้คุณทราบก่อนที่คุณจะสร้าง ดำเนินการตรวจสอบโทเค็นกับ API ของผู้ให้บริการโดยตรงเมื่อป้อนข้อมูล — โทเค็นที่ไม่ถูกต้องหรือมีขอบเขตไม่ถูกต้องจึงจะไม่ถูกจัดเก็บเลย — และหลังจากนั้นจึงจะเขียนลงใน Vault ข้อมูลดังกล่าวจะไม่สัมผัสกับโค้ด บันทึก ไฟล์สภาพแวดล้อม หรือบรรทัดคำสั่งของเราเลย เพิกถอนสิทธิ์ที่ผู้ให้บริการหรือลบการเชื่อมต่อที่นี่เมื่อใดก็ได้ที่คุณต้องการ
การ์ดที่เก็บข้อมูลจะแสดงเวลาที่ผู้ให้บริการส่งมอบให้เราครั้งล่าสุดและข้อความที่แจ้ง การไม่เคยส่งมอบคือการวินิจฉัยที่มีประโยชน์ที่สุดเพียงอย่างเดียวบนหน้าจอนั้น เนื่องจาก "เชื่อมต่อแล้วแต่ไม่เคยส่งมอบ" คือลักษณะที่แท้จริงของโทเค็นที่กำหนดขอบเขตไม่ถูกต้องหรือการส่งมอบที่ถูกบล็อก — และไม่สามารถมองเห็นได้จากที่อื่นเลย การส่งมอบทุกครั้งจะได้รับการตรวจสอบลายเซ็นก่อนที่เราจะดำเนินการ
มีให้บริการและมีการตั้งค่าสถานะไว้ GitHub Pages และ GitLab Pages ใช้งานโครงสร้างพื้นฐานของผู้ให้บริการร่วมกัน รวมถึงชื่อโฮสต์สาธารณะ github.io และ gitlab.io และนั่นคือร่องรอย (footprint) ซึ่งเป็นสิ่งเดียวที่สายผลิตภัณฑ์นี้มีขึ้นเพื่อหลีกเลี่ยง สำหรับเครือข่ายที่ไร้ร่องรอย (zero-footprint) ให้ปรับใช้บนโฮสติ้งแบบแยกต่างหากแทน ในส่วนอื่น ๆ ทั้งหมด Pages ถือเป็นระดับชั้นหนึ่ง
เนื่องจากแพ็กเกจฟรีได้รับอนุญาตสำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์เท่านั้น เราอนุมานปลายทางจากบัญชีที่คุณเชื่อมต่อไว้ในส่วนที่ปลอดภัย และ Vercel ได้รับการยกเว้นจากการอนุมานนั้นโดยเจตนา — การเชื่อมต่อบัญชีจะต้องไม่วางไซต์เชิงพาณิชย์ไว้ในที่ที่ใบอนุญาตไม่อนุญาตโดยเด็ดขาด เลือกตัวเลือกนี้แล้วจะทำงานได้เหมือนกับตัวเลือกอื่นๆ ทุกประการ
ใช่ การปรับใช้งานทุกครั้งจะบันทึกคอมมิตที่เผยแพร่ เวลาที่ทำงาน และผลลัพธ์เมื่อเสร็จสิ้น และแท็บการปรับใช้งานของไซต์จะแสดงประวัติพร้อม URL ที่ใช้งานจริงอยู่ข้างๆ การปรับใช้งานจะทำงานในเบื้องหลัง ดังนั้นหน้าเว็บจะอัปเดตเมื่อการบิลด์เสร็จสมบูรณ์ แทนที่จะทำให้คุณต้องนั่งรอสัญลักษณ์โหลดที่หมุนอยู่
เริ่มต้นทดลองใช้งานฟรี 14 วันโดยไม่ต้องใช้บัตร เชื่อมต่อกับ GitHub หรือ GitLab และกำหนดไซต์ไปยังสาขา เผยแพร่ไปยังเอดจ์โฮสต์ หรือบนโฮสติ้งของเราเองโดยไฟล์จะซิงค์ข้อมูลระหว่างกันทั้งสองทาง
เริ่มต้นฟรี