การควบคุมต้นฉบับ

ปรับใช้จากที่เก็บข้อมูลที่คุณใช้อยู่แล้ว — เก้าแห่งสำหรับจัดวาง

เชื่อมต่อบัญชี GitHub หรือ GitLab ที่คุณใช้งานและปรับใช้ได้โดยตรงจากสาขา: ไปยัง Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps หรือ AWS Amplify — หรือบนโฮสติ้งที่มีการจัดการของเราเอง ซึ่งพื้นที่เก็บข้อมูลและไฟล์ของไซต์จะซิงค์กันทั้งสองทิศทาง ทุกการเชื่อมต่อจะแสดงสิทธิ์การเข้าถึงที่จำเป็น ได้รับการตรวจสอบกับ API ของผู้ให้บริการก่อนที่จะจัดเก็บ และจัดเก็บไว้ใน Vault คุณยังสามารถเข้าสู่ระบบด้วย GitHub หรือ GitLab ได้เช่นกัน

คอมมิตที่เคลื่อนที่ไปตามไปป์ไลน์จากที่เก็บข้อมูลไปยังไซต์ที่ใช้งานจริง
  • GitHub + GitLabเชื่อมต่อบัญชีที่คุณมีอยู่แล้ว
  • ปลายทาง 9 รายการโฮสต์ส่วนขอบแปดตัว รวมทั้งฟลีตของเราเอง
  • การซิงค์แบบสองทางทุกไซต์ ทุกบรรทัด
  • จัดเก็บใน Vaultตรวจสอบแล้วเมื่อป้อนข้อมูล ไม่เคยอยู่ในบันทึก
  • ตรวจสอบโทเค็นก่อนที่จะจัดเก็บโทเค็นที่มีขอบเขตมากเกินไปจะไม่มีวันถูกผสานเข้ามา
  • พุชเพื่อปรับใช้ตรวจสอบลายเซ็นแล้ว และระบุหรือไม่ก็ได้
  • แบรนช์ของคุณ บิลด์ของคุณเผยแพร่ไดเรกทอรีหรือเรียกใช้ CI ของคุณเอง
  • ตัดการเชื่อมต่ออย่างสมบูรณ์เราลบฮุกที่เราสร้างขึ้นอย่างแม่นยำ

เชื่อมต่อเพียงครั้งเดียว และดูสิ่งที่คุณกำลังยอมรับ

การเชื่อมต่อคือข้อมูลรับรองที่คุณมอบให้ผู้อื่น ระบบของเราจะแจ้งสิ่งที่จำเป็นต้องใช้ก่อนที่คุณจะสร้าง พิสูจน์ว่าใช้งานได้จริงก่อนที่จะจัดเก็บ และสามารถเพิกถอนสิทธิ์ได้จากทั้งสองฝ่าย

สิทธิพิเศษที่ระบุไว้อย่างชัดเจนล่วงหน้า

ก่อนที่คุณจะสร้างโทเค็น เราจะแจ้งให้คุณทราบว่าโทเค็นต้องทำอะไรได้บ้างและเพราะเหตุใด จะไม่มีการกำหนดขอบเขตแบบครอบคลุมเพียงเพราะของ่ายกว่า และไม่มีการมารู้ทีหลังว่าเราต้องการมากกว่าที่งานจำเป็นต้องใช้

ตรวจสอบกับผู้ให้บริการแล้ว ไม่ได้รับรองโดยอาศัยความเชื่อใจเพียงอย่างเดียว

เราเรียกใช้ API ของผู้ให้บริการโดยตรงด้วยโทเคนของคุณก่อนที่จะจัดเก็บ โทเคนที่ผิด หมดอายุ หรือมีขอบเขตไม่ถูกต้องจะถูกปฏิเสธตั้งแต่ในแบบฟอร์ม แทนที่จะได้รับการยอมรับ แสดงสถานะว่าสมบูรณ์ดี แล้วไปล้มเหลวในการปรับใช้จริงครั้งแรก

จัดเก็บไว้ใน Vault และไม่มีที่อื่น

ไม่อยู่ในโค้ดของเรา ไม่อยู่ในไฟล์สภาพแวดล้อม ไม่อยู่ในบันทึก และไม่อยู่ในบรรทัดคำสั่ง ได้รับการแก้ไขในขณะที่มีการใช้งาน โดยเวิร์กโหลดที่ใช้งานมัน

มากกว่าหนึ่งบัญชี โดยเลือกตามแต่ละไซต์

เชื่อมต่อบัญชีส่วนตัวและบัญชีขององค์กร หรือของสององค์กร แต่ละไซต์จะเลือกว่าจะปรับใช้จากบัญชีใด ดังนั้นที่เก็บข้อมูลของไคลเอนต์และของคุณจึงไม่เคยใช้ข้อมูลประจำตัวร่วมกัน

เก้าตำแหน่งที่คลังเก็บข้อมูลสามารถไปอยู่ได้

โฮสต์เอดจ์ที่มีการจัดการแปดแห่งและฟลีตของเราเอง ปลายทางเป็นคุณสมบัติของไซต์ ไม่ใช่ของการเชื่อมต่อ ดังนั้นที่เก็บเดียวกันจึงสามารถเผยแพร่หนึ่งสาขาไปยังโฮสต์ Pages ได้ และอีกไซต์หนึ่งสามารถทำงานบนฮาร์ดแวร์ของเราได้

Cloudflare Pages

แบนด์วิดท์ไม่จำกัด อนุญาตให้ใช้งานในเชิงพาณิชย์ และจัดการเอเพ็กซ์โดเมนบนผู้ให้บริการรายเดียวกับที่ดูแลโซน DNS ของคุณเป็นปกติ ด้วยเหตุผลเหล่านี้ จึงเป็นจุดหมายแรกที่เราเลือกใช้

โฮสติ้ง Cloudflare Pages →

GitHub Pages

เผยแพร่ได้โดยตรงจากที่เก็บข้อมูลที่โค้ดมีอยู่แล้ว มีการแจ้งเตือนในบรรทัด Footprint-Free เนื่องจากโครงสร้างพื้นฐาน github.io ที่ใช้ร่วมกันนั้นถือเป็นร่องรอยการเชื่อมโยงในตัวเอง

โฮสติ้ง GitHub Pages →

GitLab Pages, Netlify, Vercel และอื่น ๆ

GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps และ AWS Amplify ล้วนเป็นปลายทางที่คุณสามารถชี้ไซต์ไปหาได้ ด้วยการเชื่อมต่อและประวัติการปรับใช้เดียวกัน

โฮสติ้งเว็บไซต์แบบสแตติก →

โฮสติ้งที่มีการจัดการของเราเอง

แอปพลิเคชันเต็มรูปแบบแทนที่จะเป็นชุดบันเดิลที่บิลด์แล้ว — WordPress, PHP, Node นี่คือปลายทางที่ได้รับการซิงค์แบบสองทาง ไฟล์บนเซิร์ฟเวอร์และแบรนช์จึงตรงกันอยู่เสมอ

โฮสติ้งที่มีการจัดการ →

ไซต์บน Edge ของผู้อื่น

ไซต์ที่เผยแพร่ไปยังโฮสต์ที่เราไม่ได้เป็นเจ้าของจะยังคงใช้โควตาที่กำหนดไว้ และยังคงปรากฏในแดชบอร์ดของคุณพร้อมกับการดีพลอย สถานะเวลาทำงาน และข้อมูล SEO ควบคู่ไปกับทุกสิ่งที่คุณใช้งาน

โควตาไซต์ภายนอก →

หรือแก้ไขที่นี่

โปรแกรมแก้ไขในเบราว์เซอร์จะทำงานบนไฟล์เดียวกันกับที่การซิงค์แบบสองทางส่งกลับ ดังนั้นการแก้ไขด่วนจากแดชบอร์ดจึงกลายเป็นคอมมิตบนสาขาของคุณ แทนที่จะเป็นการเปลี่ยนแปลงที่ไม่มีใครหาพบในภายหลัง

ตัวแก้ไขเว็บ →

การซิงค์แบบสองทาง

คลังข้อมูลและเว็บไซต์จริงของคุณ สอดประสานกันอย่างลงตัว

เปิดใช้งานแล้วไฟล์ของไซต์เองจะถูกคอมมิตกลับไปยังแบรนช์ของคุณ ในขณะที่คอมมิตบนแบรนช์นั้นจะส่งกลับมายังไซต์ ฟังก์ชันนี้ใช้งานได้กับทุกไซต์ที่เราโฮสต์ในทุกสายการผลิต โดยมีข้อกำหนดเพียงอย่างเดียวคือเครื่องเบื้องหลังต้องสามารถรัน Git กับไฟล์ของเครื่องได้ ซึ่งเป็นการตรวจสอบจากเซิร์ฟเวอร์โดยตรงแทนที่จะอนุมานจากแพ็กเกจ

คุณเป็นผู้เลือกว่าจะซิงค์ไดเรกทอรีใด เนื่องจากลูกค้า WordPress ต้องการติดตามธีมของตน ไม่ใช่ไฟล์หลักสี่หมื่นไฟล์ และระบบจะปิดอยู่จนกว่าคุณจะเปิดใช้งาน: การเปิดใช้งานการซิงค์เป็นการตัดสินใจเกี่ยวกับที่เก็บข้อมูลของผู้อื่น และการย้ายข้อมูลจะต้องไม่ตัดสินใจแทนคุณโดยเด็ดขาด

  • การแก้ไขบนฮาร์ดแวร์ของเราจะกลายเป็นคอมมิตบนสาขาของคุณ
  • คอมมิตในบรันช์ของคุณจะกลับมาที่ไซต์
  • ซิงค์เพียงไดเรกทอรีเดียว — ธีม, ปลั๊กอิน — ไม่ใช่ทั้งรากเอกสาร
  • ปิดใช้งานตามค่าเริ่มต้น รวมถึงในทุกไซต์ที่มีอยู่แล้ว
ไฟล์ที่เปิดอยู่ในโปรแกรมแก้ไข โดยมีไฟล์เดียวกันแสดงเป็นคอมมิตในที่เก็บข้อมูล

เผยแพร่ไดเรกทอรี หรือให้ CI ของคุณเป็นผู้บิลด์

สองโหมด และความแตกต่างคือตำแหน่งที่บิลด์ทำงาน ทั้งสองสิ้นสุดที่ตำแหน่งเดียวกัน: เรฟที่เราดึงข้อมูลและเผยแพร่ โดยมีคอมมิตที่บันทึกไว้เทียบกับการปรับใช้

  • โหมดเผยแพร่จะใช้สาขาของคุณตามที่เป็นอยู่และเผยแพร่ไดเรกทอรีที่คุณระบุ — การเว้นว่างหมายถึงรากของที่เก็บข้อมูล
  • โหมด CI จะรันคำสั่งบิลด์ของคุณในไปป์ไลน์ของผู้ให้บริการของคุณเอง และคอมมิตผลลัพธ์ไปยังสาขาการเผยแพร่ที่แยกต่างหาก ซึ่งเราจะดึงข้อมูลมาเหมือนกับการอ้างอิงอื่น ๆ
  • สาขาที่การปรับใช้เผยแพร่ออกไปจะได้รับการระบุชื่อไว้อย่างชัดเจนเสมอ ไม่เคยเป็น "สาขาเริ่มต้น" — ค่าเริ่มต้นสามารถเปลี่ยนแปลงได้โดยที่คุณไม่รู้ตัว และประวัติที่ไม่สามารถระบุได้ว่าเผยแพร่จากสาขาใดก็ไม่ใช่ประวัติการทำงานที่แท้จริง
  • การปรับใช้อัตโนมัติจะเปิดใช้งานตามค่าเริ่มต้นและสามารถปิดได้โดยไม่ต้องลบเว็บฮุก เพื่อให้คุณสามารถดูการส่งมอบที่เข้ามาได้ก่อนที่จะอนุญาตให้ดำเนินการ
  • การปรับใช้นั้นจะบันทึกคอมมิต ผลลัพธ์ และเวลาของการดำเนินการเสมอ และทำงานอยู่เบื้องหลัง — หน้าเว็บจะอัปเดตเมื่อการบิลด์เสร็จสมบูรณ์
  • การตัดการเชื่อมต่อจะเป็นการลบเฉพาะเว็บฮุกที่เราสร้างขึ้นตาม id ของเว็บฮุกนั้นเท่านั้น และจะไม่ลบสิ่งอื่นใดในที่เก็บของคุณ

จากคลังข้อมูลสู่เว็บไซต์จริง

  1. เชื่อมต่อบัญชี

    GitHub หรือ GitLab ภายใต้การเชื่อมต่อ สิทธิ์จะแสดงรายการก่อนที่คุณจะสร้างโทเค็น และจะได้รับการตรวจสอบกับผู้ให้บริการก่อนที่จะจัดเก็บ

  2. ชี้ไซต์ไปยังที่เก็บข้อมูล

    เจ้าของ, ที่เก็บโค้ด (repository), สาขา (branch) และเลือกว่าจะให้เราเผยแพร่ไดเรกทอรีหรือดึงข้อมูลสิ่งที่ CI ของคุณสร้างขึ้น เราจะลงทะเบียน push webhook ให้โดยเป็นส่วนหนึ่งของขั้นตอนนี้

  3. ผลัก หรือกดปุ่ม

    การ push ไปยัง branch ที่กำหนดจะเริ่มการปรับใช้ หรือคุณสามารถปรับใช้ตามความต้องการได้จากแท็บปรับใช้ของไซต์ การบิลด์จะทำงานในพื้นหลัง

  4. รับชมและซิงค์กลับหากคุณต้องการ

    ประวัติการปรับใช้จะแสดงว่ามีสิ่งใดถูกเผยแพร่และเมื่อใด เปิดการซิงค์แบบสองทางแล้วการแก้ไขที่คุณทำที่นี่จะส่งกลับไปเป็นคอมมิตบนสาขาของคุณ

เมื่อเกิดข้อผิดพลาด

"เชื่อมต่อแล้วแต่ไม่เคยส่งถึง" คือสถานะที่เราจะแจ้งให้คุณทราบอย่างแน่นอน

การเชื่อมต่อที่เก็บข้อมูลที่ดูเหมือนทำงานได้ดีแต่ไม่ได้รับสิ่งใดเลยคือข้อผิดพลาดเงียบแบบคลาสสิก — โทเค็นที่มีขอบเขตไม่ถูกต้อง การส่งข้อมูลที่ถูกบล็อกที่ผู้ให้บริการ เว็บฮุกที่ใครบางคนนำออกด้วยตนเอง ปัญหานี้มองไม่เห็นบนหน้าจออื่น ๆ การ์ดที่เก็บข้อมูลจึงแสดงข้อมูลนี้โดยตรง: เมื่อผู้ให้บริการส่งข้อมูลให้เราล่าสุด และระบุว่าอย่างไร

รายการส่งมอบจะได้รับการตรวจสอบลายเซ็นก่อนที่เราจะดำเนินการ โดยใช้รูปแบบของผู้ให้บริการแต่ละราย แทนที่จะเป็นรูปแบบที่เราสันนิษฐานว่าใช้ได้กับทุกราย รายการส่งมอบที่ไม่ผ่านการตรวจสอบจะถูกปฏิเสธและบันทึกไว้ ไม่ใช่ถูกเพิกเฉยไปอย่างเงียบ ๆ

  • เวลาและข้อความการจัดส่งล่าสุด บนการ์ด
  • ระบุว่า "ไม่เคยส่งมอบ" ไม่ได้เว้นว่างไว้
  • ตรวจสอบลายเซ็นตามผู้ให้บริการเรียบร้อยแล้วก่อนที่สิ่งใดจะทำงาน
  • ฮุกที่เราสร้างไว้จะถูกลบออกตามรหัสประจำตัวเมื่อคุณตัดการเชื่อมต่อ
การส่งเว็บฮุกมาถึงและได้รับการตรวจสอบก่อนที่จะทริกเกอร์สิ่งใดๆ

ข้อมูลประจำตัว

ลงชื่อเข้าใช้ด้วย GitHub หรือ GitLab — หรือ Google หรือ Microsoft

นอกเหนือจากที่อยู่อีเมลและรหัสผ่านแล้ว คุณยังสามารถลงชื่อเข้าใช้บัญชี Zinn Digital® ของคุณด้วย GitHub, GitLab, Google หรือ Microsoft ได้ เลเยอร์ระบุตัวตนจะดำเนินการแฮนด์เชก (handshake) โดยเราจะไม่เห็นรหัสผ่านของผู้ให้บริการของคุณโดยเด็ดขาด และการเชื่อมโยงบัญชีโซเชียลกับบัญชี Zinn® ที่มีอยู่ยังคงต้องได้รับการยืนยันทางอีเมล

การลงชื่อเข้าใช้ด้วย GitHub และการเชื่อมต่อ GitHub สำหรับการปรับใช้นั้นเป็นการตัดสินใจแยกต่างหากและเป็นข้อมูลประจำตัวที่แยกจากกัน การดำเนินการอย่างใดอย่างหนึ่งไม่ได้ส่งผลให้อีกอย่างทำงาน และการลบอย่างใดอย่างหนึ่งไม่ได้เป็นการลบอีกอย่างหนึ่งออกไปด้วย

  • ลงชื่อเข้าใช้ด้วย GitHub, GitLab, Google และ Microsoft
  • พาสคีย์และการยืนยันตัวตนแบบสองปัจจัยในบัญชีเดียวกัน
  • ข้อมูลประจำตัวสำหรับลงชื่อเข้าใช้และการปรับใช้จะแยกจากกัน
สิทธิ์การเข้าถึงที่ได้รับมอบหมายสำหรับทีมของคุณ
ผู้ใช้หลายคนลงชื่อเข้าใช้บัญชีเดียวด้วยผู้ให้บริการที่แตกต่างกัน

คำถามที่พบบ่อย

ฉันสามารถเชื่อมต่อกับผู้ให้บริการระบบควบคุมเวอร์ชันรายใดได้บ้าง

GitHub และ GitLab เชื่อมต่อบัญชีที่คุณใช้งานอยู่แล้ว และเราสามารถนำโค้ดไปใช้งานจากที่เก็บข้อมูลเหล่านั้น ลงทะเบียน push webhook ให้กับที่เก็บข้อมูลดังกล่าว และ — หากคุณต้องการ — ซิงค์ไฟล์ของไซต์คุณกลับไปอีกทางหนึ่งได้ ทั้งสองอย่างดำเนินการผ่านส่วนเชื่อมโยงบัญชีเดียวกัน ดังนั้นข้อมูลทั้งหมดด้านล่างจึงเป็นจริงสำหรับทั้งสองบริการ

ฉันสามารถลงชื่อเข้าใช้ด้วย GitHub หรือ GitLab ได้หรือไม่?

ใช่ และใช้ Google หรือ Microsoft ได้เช่นกัน นอกจากที่อยู่อีเมลและรหัสผ่านแล้ว คุณยังสามารถลงชื่อเข้าใช้บัญชี Zinn Digital® ของคุณด้วยตัวเลือกใดก็ได้ในสี่ตัวเลือกนี้ เลเยอร์ระบุตัวตนจะจัดการการสื่อสารเชื่อมต่อ และเราจะไม่เห็นรหัสผ่านของผู้ให้บริการของคุณ การลงชื่อเข้าใช้ด้วย GitHub เป็นคนละส่วนกับการเชื่อมต่อ GitHub เพื่อการปรับใช้ — คุณสามารถเลือกทำอย่างใดอย่างหนึ่ง ทำทั้งสองอย่าง หรือไม่ทำเลยก็ได้

ฉันสามารถปรับใช้ที่เก็บได้ที่ไหน

ไปยัง Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps หรือ AWS Amplify สำหรับไซต์แบบคงที่หรือไซต์ที่ผ่านการบิลด์ — หรือบนโฮสติ้งที่มีการจัดการของเราเอง ซึ่งที่เก็บโค้ดและไฟล์ของไซต์จะซิงค์กันอยู่เสมอในทั้งสองทิศทาง คุณเป็นผู้เลือกปลายทางสำหรับไซต์ ส่วนการเชื่อมต่อกับที่เก็บโค้ดจะเหมือนกันในทั้งสองกรณี

คุณสามารถสร้างเว็บไซต์ให้ฉันได้ไหม หรือต้องสร้างไว้ล่วงหน้าแล้ว?

แบบใดก็ได้ ในโหมดเผยแพร่ เราจะใช้บรันช์ตามที่เป็นอยู่และเผยแพร่ไดเรกทอรีที่คุณระบุ ในโหมด CI ไปป์ไลน์ของผู้ให้บริการของคุณจะเรียกใช้คำสั่งบิลด์ของคุณ และคอมมิตเอาต์พุตไปยังบรันช์เผยแพร่ที่แยกต่างหาก ซึ่งเราจะดึงข้อมูลเช่นเดียวกับ ref อื่นๆ วิธีที่สองจะเก็บการบิลด์ของคุณไว้ใน CI ของคุณเอง ซึ่งเป็นที่ที่ข้อมูลลับและการแคชของคุณมีอยู่แล้ว

การ push จะปรับใช้อัตโนมัติหรือไม่?

ตามค่าเริ่มต้นคือใช่ — เราจะลงทะเบียนเว็บฮุกบนที่เก็บข้อมูล และการพุชไปยังสาขาที่คุณระบุจะเริ่มต้นการปรับใช้ คุณสามารถปิดส่วนนั้นและคงเว็บฮุกไว้ได้ ซึ่งมีประโยชน์มากกว่าที่คิด: ระบบยังคงบันทึกการนำส่งอยู่ คุณจึงสามารถดูการพุชของคุณที่เข้ามาได้ก่อนที่จะอนุญาตให้เราดำเนินการกับข้อมูลเหล่านั้น

การซิงค์แบบสองทางคืออะไร

การแก้ไขที่ทำบนฮาร์ดแวร์ของเราจะกลายเป็นคอมมิตบนสาขาของคุณ และคอมมิตบนสาขาของคุณจะส่งกลับไปยังไซต์ ฟังก์ชันนี้จะปิดอยู่จนกว่าคุณจะเปิดใช้งาน เนื่องจากการเปิดใช้งานคือการตัดสินใจเกี่ยวกับที่เก็บของผู้อื่น และเราจะไม่ตัดสินใจแทนคุณ คุณเป็นผู้เลือกไดเรกทอรีที่จะซิงค์ ซึ่งโดยปกติแล้วจะเป็นธีมหรือปลั๊กอิน ไม่ใช่ไฟล์หลักของ WordPress จำนวนสี่หมื่นไฟล์

จะเกิดอะไรขึ้นหากทั้งสองฝ่ายมีการเปลี่ยนแปลง?

ไม่มีสิ่งใดถูกเขียนทับและไม่มีสิ่งใดถูกพุช การซิงค์จะหยุดลง แจ้งให้คุณทราบว่าสาขาได้ก้าวล่วงหน้าเกินกว่าคอมมิตที่เราใช้อ้างอิงแล้ว และถามว่าคุณต้องการฝั่งใด — เก็บที่เก็บข้อมูลไว้ หรือเก็บไซต์ไว้ ไซต์ที่ไม่เคยซิงค์และชี้ไปยังสาขาที่มีคอมมิตอยู่แล้วก็เป็นอีกสถานะหนึ่งเช่นกัน และระบบจะถามแทนที่จะคาดเดาว่าฝ่ายใดถูกต้อง

โทเค็นการเข้าถึงของฉันได้รับการปกป้องอย่างไร?

เราจะแสดงสิทธิ์ที่การเชื่อมต่อต้องการให้คุณทราบก่อนที่คุณจะสร้าง ดำเนินการตรวจสอบโทเค็นกับ API ของผู้ให้บริการโดยตรงเมื่อป้อนข้อมูล — โทเค็นที่ไม่ถูกต้องหรือมีขอบเขตไม่ถูกต้องจึงจะไม่ถูกจัดเก็บเลย — และหลังจากนั้นจึงจะเขียนลงใน Vault ข้อมูลดังกล่าวจะไม่สัมผัสกับโค้ด บันทึก ไฟล์สภาพแวดล้อม หรือบรรทัดคำสั่งของเราเลย เพิกถอนสิทธิ์ที่ผู้ให้บริการหรือลบการเชื่อมต่อที่นี่เมื่อใดก็ได้ที่คุณต้องการ

ฉันจะทราบได้อย่างไรว่าคุณได้รับ push ของฉันจริงหรือไม่

การ์ดที่เก็บข้อมูลจะแสดงเวลาที่ผู้ให้บริการส่งมอบให้เราครั้งล่าสุดและข้อความที่แจ้ง การไม่เคยส่งมอบคือการวินิจฉัยที่มีประโยชน์ที่สุดเพียงอย่างเดียวบนหน้าจอนั้น เนื่องจาก "เชื่อมต่อแล้วแต่ไม่เคยส่งมอบ" คือลักษณะที่แท้จริงของโทเค็นที่กำหนดขอบเขตไม่ถูกต้องหรือการส่งมอบที่ถูกบล็อก — และไม่สามารถมองเห็นได้จากที่อื่นเลย การส่งมอบทุกครั้งจะได้รับการตรวจสอบลายเซ็นก่อนที่เราจะดำเนินการ

ฉันสามารถใช้การปรับใช้ Pages บนสาย Footprint-Free ได้หรือไม่?

มีให้บริการและมีการตั้งค่าสถานะไว้ GitHub Pages และ GitLab Pages ใช้งานโครงสร้างพื้นฐานของผู้ให้บริการร่วมกัน รวมถึงชื่อโฮสต์สาธารณะ github.io และ gitlab.io และนั่นคือร่องรอย (footprint) ซึ่งเป็นสิ่งเดียวที่สายผลิตภัณฑ์นี้มีขึ้นเพื่อหลีกเลี่ยง สำหรับเครือข่ายที่ไร้ร่องรอย (zero-footprint) ให้ปรับใช้บนโฮสติ้งแบบแยกต่างหากแทน ในส่วนอื่น ๆ ทั้งหมด Pages ถือเป็นระดับชั้นหนึ่ง

เหตุใดฉันจึงต้องเลือก Vercel อย่างชัดเจน

เนื่องจากแพ็กเกจฟรีได้รับอนุญาตสำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์เท่านั้น เราอนุมานปลายทางจากบัญชีที่คุณเชื่อมต่อไว้ในส่วนที่ปลอดภัย และ Vercel ได้รับการยกเว้นจากการอนุมานนั้นโดยเจตนา — การเชื่อมต่อบัญชีจะต้องไม่วางไซต์เชิงพาณิชย์ไว้ในที่ที่ใบอนุญาตไม่อนุญาตโดยเด็ดขาด เลือกตัวเลือกนี้แล้วจะทำงานได้เหมือนกับตัวเลือกอื่นๆ ทุกประการ

ฉันสามารถดูได้หรือไม่ว่ามีการปรับใช้อะไรและเมื่อใด

ใช่ การปรับใช้งานทุกครั้งจะบันทึกคอมมิตที่เผยแพร่ เวลาที่ทำงาน และผลลัพธ์เมื่อเสร็จสิ้น และแท็บการปรับใช้งานของไซต์จะแสดงประวัติพร้อม URL ที่ใช้งานจริงอยู่ข้างๆ การปรับใช้งานจะทำงานในเบื้องหลัง ดังนั้นหน้าเว็บจะอัปเดตเมื่อการบิลด์เสร็จสมบูรณ์ แทนที่จะทำให้คุณต้องนั่งรอสัญลักษณ์โหลดที่หมุนอยู่

ปรับใช้จากที่เก็บของคุณ

เริ่มต้นทดลองใช้งานฟรี 14 วันโดยไม่ต้องใช้บัตร เชื่อมต่อกับ GitHub หรือ GitLab และกำหนดไซต์ไปยังสาขา เผยแพร่ไปยังเอดจ์โฮสต์ หรือบนโฮสติ้งของเราเองโดยไฟล์จะซิงค์ข้อมูลระหว่างกันทั้งสองทาง

เริ่มต้นฟรี