สรุปสั้นๆ
สภาพแวดล้อมการทำงานของ API ที่เป็น Git-native หมายถึงข้อกำหนด API ของคุณจะอยู่ใน Git ในฐานะแหล่งความจริงเดียว โดยมีการควบคุมเวอร์ชันเต็มรูปแบบ การแยกสาขา (branching) และเวิร์กโฟลว์การขอรวม (merge request) ที่สร้างขึ้นโดยตรงใน แพลตฟอร์มการพัฒนา API ของคุณ ทีมงานจะทำงานในสาขา Sprint ที่แยกออกมาต่างหาก ตรวจสอบการเปลี่ยนแปลงผ่านการขอรวม และซิงค์โดยอัตโนมัติกับพื้นที่เก็บข้อมูล (repositories) ของพวกเขา โหมด Spec-first ของ Apidog นำเสนอเวิร์กโฟลว์นี้ด้วย IDE ในตัวสำหรับการแก้ไขข้อกำหนด OpenAPI, การตรวจสอบความถูกต้องแบบเรียลไทม์ และการผสานรวมกับ GitHub/GitLab/Azure DevOps ได้อย่างราบรื่น
ทำไมทีม API จึงต้องการเวิร์กโฟลว์ที่เป็น Git-Native
ขอพูดตามตรงเลยนะ หลังจากที่ได้นำทีมพัฒนา API มาหลายปี ผมได้เห็นปัญหาการทำงานร่วมกันเดิมๆ เกิดขึ้นซ้ำแล้วซ้ำเล่าในทุกทีม:
- "ข้อกำหนดเวอร์ชันไหนคือเวอร์ชันปัจจุบัน?" — ห้าคนแก้ไข Postman collection เดียวกัน ไม่มีใครรู้ว่าเวอร์ชันไหนคือเวอร์ชันที่ถูกต้อง
- "ทำไม endpoint นี้ถึงเปลี่ยนไป?" — ไม่มีบันทึกการเปลี่ยนแปลง ไม่มีประวัติ ไม่มีวิธีติดตามว่าทำไมพารามิเตอร์ถึงถูกเปลี่ยนชื่อเมื่อสามเดือนที่แล้ว
- "ฉันสามารถทำงานในฟีเจอร์ใหม่โดยไม่ทำให้ข้อกำหนดหลักเสียหายได้หรือไม่?" — ทุกคนแก้ไขข้อกำหนดที่ใช้งานอยู่พร้อมกัน (ความวุ่นวาย) หรือคุณต้องทำสำเนาไฟล์และรวมด้วยตนเองในภายหลัง (มีแนวโน้มที่จะเกิดข้อผิดพลาด)
- "เราจะตรวจสอบการเปลี่ยนแปลง API นี้ได้อย่างไร?" — ส่งส่วนย่อย JSON ใน Slack, แปะภาพหน้าจอใน Jira, ไม่มีกระบวนการตรวจสอบที่เป็นระบบ
ฟังดูคุ้นๆ ไหม?
นี่ไม่ใช่ปัญหาของเครื่องมือ แต่เป็นปัญหาของเวิร์กโฟลว์ และเวิร์กโฟลว์ที่แก้ไขปัญหาทั้งหมดนี้ได้คืออะไร? มันคือเวิร์กโฟลว์เดียวกับที่ทีมโค้ดของคุณใช้อยู่แล้ว: Git
วิศวกรแบ็กเอนด์ของคุณใช้ Git วิศวกรฟรอนต์เอนด์ของคุณใช้ Git ทีม DevOps ของคุณใช้ Git แต่ด้วยเหตุผลบางอย่าง การออกแบบ API มักจะอยู่นอกโลกนั้น — ถูกจำกัดอยู่ในเครื่องมือเฉพาะ, แยกออกจากระบบควบคุมเวอร์ชันที่ขับเคลื่อนทุกสิ่งทุกอย่าง
นั่นคือช่องว่างที่วิธีการ Git-native ของ Apidog เข้ามาเติมเต็ม มันนำข้อกำหนด API ของคุณเข้าสู่เวิร์กโฟลว์ Git แบบเดียวกับที่องค์กรวิศวกรรมทั้งหมดของคุณเชื่อถืออยู่แล้ว
"Git-Native" สำหรับ API หมายถึงอะไรกันแน่?
การพัฒนา API แบบ Git-native ไม่ได้หมายถึงแค่ "การเก็บไฟล์ OpenAPI ของคุณไว้ในพื้นที่เก็บข้อมูล (repository)" ซึ่งเป็นสิ่งที่ทำได้มานานแล้ว และทีมงานก็ยังคงประสบปัญหาการทำงานร่วมกันแบบเดิมๆ อยู่ดี
Git-native ที่แท้จริงหมายถึง:
| การจัดเก็บ Git แบบดั้งเดิม | สภาพแวดล้อมการทำงาน Git-Native |
|---|---|
| ข้อกำหนดอยู่ใน Git แต่คุณแก้ไขในเครื่องมือภายนอก | แก้ไขข้อกำหนดภายในแพลตฟอร์มโดยใช้ Git เป็นแหล่งความจริง |
| การคอมมิตด้วยตนเองหลังจากแก้ไขจากที่อื่น | คอมมิตและพุชโดยตรงจากพื้นที่ทำงาน API |
| ไม่มีแนวคิดของการแยกสาขา API (API branching) | สาขา Sprint สำหรับการพัฒนาฟีเจอร์แบบแยกอิสระ |
| เครื่องมือตรวจสอบโค้ดที่นำมาใช้กับ YAML diffs อย่างไม่เหมาะสม | การขอรวมในตัวที่ออกแบบมาสำหรับการเปลี่ยนแปลง API |
| การซิงค์หยุดทำงานเมื่อมีคนแก้ไขสำเนาภายในของเครื่องมือ | การซิงค์แบบสองทางที่ถือว่า Git เป็นหลัก |
ความแตกต่างคือความลึกของการผสานรวม สภาพแวดล้อมการทำงาน API แบบ Git-native ถือว่าพื้นที่เก็บข้อมูลของคุณเป็น แหล่งข้อมูลที่เชื่อถือได้ ไม่ใช่ปลายทางสำรอง ทุกอย่าง — การแก้ไข, การแยกสาขา, การตรวจสอบ, การทดสอบ — เกิดขึ้นโดยมี Git เป็นพื้นฐาน
ส่วนประกอบหลัก
- โหมด Spec-first — ไฟล์ OpenAPI YAML/JSON ของคุณคืออาร์ติแฟกต์หลัก ไม่ใช่ระเบียนฐานข้อมูลภายใน
- สาขา Sprint — สาขาฟีเจอร์ API ที่ทำงานเหมือนสาขา Git สำหรับโค้ด
- สาขาหลักที่ได้รับการป้องกัน — ความเสถียรในการผลิตผ่านเวิร์กโฟลว์การตรวจสอบที่บังคับใช้
- การขอรวม — การตรวจสอบการเปลี่ยนแปลง API ที่เป็นระบบ พร้อมการเปรียบเทียบก่อน/หลัง
- การซิงค์ด้วย Webhook — การซิงค์อัตโนมัติเมื่อพื้นที่เก็บข้อมูลของคุณได้รับการพุช
นี่ไม่ใช่แนวคิดใหม่ มันคือการนำเวิร์กโฟลว์ Git ที่ได้รับการพิสูจน์แล้วมาใช้กับโดเมนที่ต้องการมันมานานหลายปีแล้ว
ปัญหาของเครื่องมือ API แบบดั้งเดิม
แพลตฟอร์มการพัฒนา API ส่วนใหญ่ทำงานบน โมเดลฐานข้อมูลภายใน:
- คุณสร้าง endpoints ผ่านฟอร์มภาพ
- แพลตฟอร์มจะจัดเก็บทุกอย่างในฐานข้อมูลของตัวเอง
- ส่งออกเป็น OpenAPI เมื่อจำเป็น (มักจะไม่สมบูรณ์หรือล้าสมัย)
- หากคุณต้องการประวัติ Git คุณจะต้องส่งออกด้วยตนเองและคอมมิตเอง
โมเดลนี้ใช้ได้ดีสำหรับบุคคลทั่วไป แต่สำหรับทีมล่ะ? มันสร้างความขัดแย้งพื้นฐาน:
ไม่มีประวัติเวอร์ชันที่แท้จริง
แพลตฟอร์มอาจมี "ประวัติ" แต่ไม่ใช่ประวัติ Git คุณไม่สามารถ:
- ดูว่าใครเปลี่ยนอะไรและเมื่อไหร่ในบันทึกการเปลี่ยนแปลงที่เป็นหนึ่งเดียว
- แยกสาขาและรวมได้อย่างเรียบร้อย
- ย้อนกลับไปยังสถานะที่ทราบโดยใช้คำสั่ง Git มาตรฐาน
- ใช้ไปป์ไลน์ CI/CD ที่คาดหวังเวิร์กโฟลว์ที่ถูกทริกเกอร์โดย Git
ความขัดแย้งในการทำงานร่วมกัน
เมื่อนักพัฒนาหลายคนแก้ไขโปรเจกต์เดียวกัน:
- การเปลี่ยนแปลงอาจเขียนทับกันเองโดยไม่มีการเตือน
- ไม่มีกลไกการแก้ไขข้อขัดแย้งในการรวม
- การแก้ไขแบบ "สด" หมายถึงไม่มีการแยกส่วนสำหรับฟีเจอร์ใหม่ๆ
ช่องว่างในการตรวจสอบ
คุณจะตรวจสอบการเปลี่ยนแปลง API ได้อย่างไร? ในเครื่องมือแบบดั้งเดิม:
- ภาพหน้าจอของ UI
- ส่วนย่อย JSON ที่ส่งออกแล้วคัดลอกลงในเอกสาร
- ไม่มีมุมมอง diff ที่เป็นระบบ
- ไม่มีเวิร์กโฟลว์การอนุมัติพร้อมบันทึกการตรวจสอบ
ความไม่เชื่อมโยงกัน
ข้อกำหนด API ของคุณอธิบายสัญญา (contract) ระหว่างระบบต่างๆ มันมีความสำคัญพอๆ กับโค้ดแอปพลิเคชันของคุณ แต่กลับอยู่นอกระบบควบคุมเวอร์ชันที่ปกป้องทุกสิ่งทุกอย่าง ความไม่เชื่อมโยงกันนั้นคือสาเหตุหลักของปัญหาการทำงานร่วมกันของ API ส่วนใหญ่
แนวทาง Git-Native ของ Apidog: โหมด Spec-first
โหมด Spec-first ของ Apidog พลิกโมเดลเดิม: Git กลายเป็นแหล่งความจริง และแพลตฟอร์มกลายเป็นส่วนต่อประสาน (interface) ของคุณกับมัน
วิธีการทำงาน
- เชื่อมต่อผู้ให้บริการ Git ของคุณ — GitHub, GitLab, Azure DevOps หรือ Bitbucket
- เลือกพื้นที่เก็บข้อมูลและสาขาหลักของคุณ — Apidog จะอ่านข้อกำหนดที่มีอยู่ของคุณหรือเริ่มใหม่
- แก้ไขในพื้นที่ทำงาน Specs — มุมมองโค้ดพร้อมการเน้นไวยากรณ์ หรือมุมมองฟอร์มสำหรับการแก้ไขที่มีโครงสร้าง
- คอมมิตและพุชจาก Apidog — การเปลี่ยนแปลงจะตรงไปยังพื้นที่เก็บข้อมูลของคุณ
- การซิงค์ด้วย Webhook ช่วยให้ทั้งสองฝ่ายสอดคล้องกัน — การพุชไปยัง Git จะซิงค์กลับไปยัง Apidog โดยอัตโนมัติ
พื้นที่ทำงาน Specs
นี่คือจุดที่ประสบการณ์ Git-native โดดเด่น แทนที่จะกรอกฟอร์มที่อัปเดตฐานข้อมูลภายใน คุณจะทำงานกับไฟล์:
- ตัวสำรวจไฟล์ — เรียกดูโครงสร้างพื้นที่เก็บข้อมูลของคุณโดยตรง
- โครงสร้าง API แบบ Tree — เนื้อหา OpenAPI ที่วิเคราะห์แล้ว: endpoints, schemas, definitions
- ตัวแก้ไขโค้ด — ประสบการณ์ IDE เต็มรูปแบบพร้อมการตรวจสอบความถูกต้อง, การเติมโค้ดอัตโนมัติ, การเน้นไวยากรณ์
- ตัวแก้ไขฟอร์ม — สำหรับโหนดที่รองรับ ให้แก้ไขผ่านการควบคุมที่มีโครงสร้างในขณะที่ไฟล์ยังคงเป็นแหล่งข้อมูล
คุณสามารถทำงานทั้งหมดใน YAML/JSON ได้หากเป็นความต้องการของคุณ หรือสลับไปที่มุมมองฟอร์มสำหรับคำจำกัดความ endpoint ที่ซับซ้อน ไม่ว่าจะด้วยวิธีใด ไฟล์ที่อยู่ภายใต้ใน Git คือสิ่งที่สำคัญ
การตรวจสอบความถูกต้องและดูตัวอย่างแบบเรียลไทม์
ตัวแก้ไขประกอบด้วย:
- แผงการตรวจสอบความถูกต้อง — ข้อผิดพลาดทางไวยากรณ์, ฟิลด์ที่จำเป็นขาดหายไป, การละเมิดกฎ OpenAPI จะถูกตรวจจับทันที
- แผงดูตัวอย่าง — ดูว่าข้อกำหนดของคุณแสดงผลเป็นเอกสารอย่างไรก่อนที่จะคอมมิต
- ลองใช้งาน — ทดสอบ endpoints ได้โดยตรงจากคำจำกัดความของข้อกำหนด
ไม่ต้องคอมมิตข้อกำหนดที่เสียและค้นพบข้อผิดพลาดใน CI อีกต่อไป
สาขา Sprint: สาขาฟีเจอร์ API ของคุณ
ในการพัฒนาโค้ด ฟีเจอร์บรานช์เป็นสิ่งที่ไม่สามารถต่อรองได้ คุณจะไม่แก้ไขโค้ดที่ใช้งานจริงโดยตรง แล้วทำไมถึงต้องแก้ไขข้อกำหนด API ที่ใช้งานจริงโดยตรงล่ะ?
สาขา Sprint ของ Apidog นำการแยกส่วนแบบเดียวกันนี้มาสู่การทำงานกับ API
สิ่งที่สาขา Sprint ช่วยให้ทำได้
| สถานการณ์ | ไม่มีสาขา Sprint | มีสาขา Sprint |
|---|---|---|
| การพัฒนา endpoint ใหม่ | แก้ไขข้อกำหนดหลัก, เสี่ยงต่อการทำให้เอกสารและส่วนทดสอบของทุกคนเสียหาย | ทำงานแบบแยกอิสระ, รวมเมื่อมีความเสถียร |
| การทดสอบการเปลี่ยนแปลง API | ผู้ทดสอบทุกคนเห็นงานที่ยังไม่สมบูรณ์ | ผู้ทดสอบสามารถสลับไปที่สาขา Sprint เพื่อการทดสอบที่เน้นเฉพาะ |
| การพัฒนาฟีเจอร์แบบขนาน | หลายฟีเจอร์ชนกันในข้อกำหนดเดียว | แต่ละฟีเจอร์มีสาขาของตัวเอง |
| การย้อนกลับการเปลี่ยนแปลง | ไม่มีกลไกการย้อนกลับที่ชัดเจน | ลบหรือรวมการเปลี่ยนแปลงที่เลือก |
การสร้างสาขา Sprint
- คลิกสวิตช์สาขาข้างๆ APIs
- เลือก New Sprint Branch (สร้างสาขา Sprint ใหม่)
- ตั้งชื่อสำหรับฟีเจอร์ของคุณ (เช่น
user-authentication-v2) - ทำงานแยกออกจากสาขาหลัก
สองวิธีในการเติมข้อมูลลงในสาขา Sprint
วิธีการแบบแมนนวล (API-first):
ใช้ Fork from main (แยกจากหลัก) เพื่อคัดลอก endpoints, schemas หรือส่วนประกอบที่คุณต้องการแก้ไข Apidog จะติดตามความสัมพันธ์ ดังนั้นการรวมในภายหลังจะทราบว่าทรัพยากรใดมีการเปลี่ยนแปลง
วิธีการนำเข้า OAS (code-first):
นำเข้าข้อกำหนด OpenAPI ที่อัปเดตจากแบ็กเอนด์ของคุณ Apidog จะเปรียบเทียบกับสาขาหลักและดึงเฉพาะทรัพยากรที่เปลี่ยนแปลงเท่านั้น ซึ่งจะทำให้สาขา Sprint ของคุณมุ่งเน้นไปที่ความแตกต่างที่แท้จริง
การจับคู่การทดสอบอัตโนมัติ
นี่คือสิ่งที่ทีมส่วนใหญ่มักมองข้าม: เมื่อคุณเปลี่ยน endpoint ในสาขา Sprint การทดสอบที่มีอยู่ของคุณยังคงกำหนดเป้าหมายไปยังเวอร์ชันของสาขาหลัก
Apidog แก้ปัญหานี้โดย:
- การทำเครื่องหมาย endpoint ที่ถูกแก้ไข ในสถานการณ์การทดสอบของคุณ
- ให้ผู้ทดสอบทำสำเนาและปรับการทดสอบสำหรับเวอร์ชันสาขา Sprint
- ตรวจสอบให้แน่ใจว่าการทดสอบตรงกับสาขาที่คุณกำลังทำงานอยู่
สิ่งนี้ป้องกันความล้มเหลวที่พบบ่อย: การรวม endpoint ใหม่โดยไม่ได้อัปเดตการทดสอบ แล้วมาพบว่าไปป์ไลน์ CI เสียหายในอีกหลายวันต่อมา
สาขาที่ได้รับการป้องกันและการขอรวม
สาขาที่ได้รับการป้องกันคือกระดูกสันหลังของความเสถียรในการผลิต ใน Apidog สาขาหลักที่ได้รับการป้องกันหมายถึง:
- ไม่มีการแก้ไขโดยตรง — การเปลี่ยนแปลงต้องมาจากการขอรวม
- การตรวจสอบภาคบังคับ — ผู้ดูแลระบบอนุมัติก่อนรวม
- บันทึกการตรวจสอบ — ทุกการเปลี่ยนแปลงมีบันทึกการตรวจสอบ
เวิร์กโฟลว์การขอรวม
เมื่องานในสาขา Sprint ของคุณพร้อม:
- คลิก Merge (รวม) ในสวิตช์สาขา
- ตรวจสอบการเปลี่ยนแปลงทั้งหมดด้วยสถานะรหัสสี:
- สีเทา — ไม่เปลี่ยนแปลง (ไม่จำเป็นต้องรวม)
- สีส้ม — แก้ไขแล้ว (เปรียบเทียบกับสาขาหลัก)
- สีเขียว — ใหม่ (สร้างในสาขา Sprint)
- สำหรับทรัพยากรที่แก้ไข ดู diff ที่แน่นอนระหว่างเวอร์ชัน Sprint และหลัก
- เลือกสิ่งที่จะรวม
- สร้าง Merge Request (ขอรวม) (สำหรับสาขาที่ได้รับการป้องกัน) หรือ Merge directly (รวมโดยตรง) (สำหรับสาขาที่ไม่ได้รับการป้องกัน)
กระบวนการตรวจสอบ
ผู้ตรวจสอบจะเห็น:
- รายการการเปลี่ยนแปลงทั้งหมด
- การเปรียบเทียบก่อน/หลังสำหรับแต่ละทรัพยากรที่แก้ไข
- บริบทจากสาขา Sprint
พวกเขาสามารถอนุมัติ ปฏิเสธ หรือขอการแก้ไขได้ หากนักพัฒนาอัปเดตสาขา Sprint คำขอรวมจะสะท้อนการเปลี่ยนแปลงใหม่โดยอัตโนมัติ — ไม่จำเป็นต้องสร้างคำขอใหม่
นี่คือเวิร์กโฟลว์การตรวจสอบที่ทีม API ต้องการมานานหลายปี ไม่มีการตรวจสอบที่อิงตามภาพหน้าจออีกต่อไป ไม่มีการสนทนาใน Slack ที่พยายามอธิบายการเปลี่ยนแปลง endpoint อีกแล้ว
การผสานรวม Git อย่างราบรื่น: Commit, Push, Pull
การดำเนินการ Git เกิดขึ้นโดยตรงภายใน Apidog ไม่จำเป็นต้องใช้ไคลเอนต์ Git ภายนอก
Commit & Push
หลังจากแก้ไข:
- คลิก Changes (การเปลี่ยนแปลง) เพื่อตรวจสอบไฟล์ที่แก้ไข, เพิ่ม, ลบ
- เลือกไฟล์ที่จะรวม
- เขียนข้อความคอมมิต
- คลิก Push (พุช) — การเปลี่ยนแปลงจะซิงค์ไปยังพื้นที่เก็บข้อมูลของคุณทันที
Git Pull
เมื่อเพื่อนร่วมทีมพุชการเปลี่ยนแปลงไปยังพื้นที่เก็บข้อมูลที่เชื่อมต่อของคุณ:
- คลิกชื่อสาขาในแถบด้านข้าง Specs
- เลือก Git Pull (ดึง Git) — ไฟล์ล่าสุดจะซิงค์เข้าสู่ Apidog
การซิงค์ด้วย Webhook (แนะนำ)
หากคุณมีสิทธิ์ผู้ดูแลระบบพื้นที่เก็บข้อมูล ให้ติดตั้ง webhook ระหว่างการตั้งค่า:
- การพุชไปยังพื้นที่เก็บข้อมูลของคุณจะเรียกใช้การซิงค์ Apidog โดยอัตโนมัติ
- ไม่จำเป็นต้องดึงด้วยตนเอง
- ทีมจะคงความสอดคล้องกันโดยไม่ต้องใช้ความพยายาม
หากไม่มีการซิงค์ด้วย webhook การดึงด้วยตนเองก็ใช้ได้ดี แต่การซิงค์ด้วย webhook จะขจัดคำถามที่ว่า "ใครมีข้อกำหนดล่าสุด?" ออกไปอย่างสิ้นเชิง
สิ่งที่เปลี่ยนแปลงเมื่อเทียบกับเวิร์กโฟลว์แบบดั้งเดิม
| ก่อนหน้า | หลังจาก |
|---|---|
| นักพัฒนาแก้ไขข้อกำหนดหลักโดยตรง | สาขา Sprint ที่แยกอิสระ |
| ผู้ทดสอบไม่สามารถทดสอบการเปลี่ยนแปลงที่ไม่สมบูรณ์ได้ | สาขาเฉพาะสำหรับการทดสอบ |
| ตรวจสอบผ่านภาพหน้าจอและการสนทนาใน Slack | การขอรวมที่มีโครงสร้างพร้อม diffs |
| ไม่มีการมองเห็นงานที่ทำแบบขนาน | สวิตช์สาขาแสดงงานที่กำลังดำเนินการทั้งหมด |
| การรวมจะเขียนทับโดยไม่มีการแจ้งเตือน | การรวมแบบเลือกพร้อมการแสดงตัวอย่าง |
นี่ไม่ใช่การเพิ่มความซับซ้อน แต่เป็นการเพิ่มโครงสร้างที่ช่วยขจัดความวุ่นวาย
คำถามที่พบบ่อย
ความแตกต่างระหว่างโหมด Spec-first และโปรเจกต์ Apidog ทั่วไปคืออะไร?
โหมด Spec-first ใช้พื้นที่เก็บข้อมูล Git ของคุณเป็นแหล่งความจริง ในขณะที่โปรเจกต์ Apidog ทั่วไปใช้ฐานข้อมูลภายในของ Apidog เป็นหลัก โดยมีการส่งออก Git เป็นรอง ในโหมด Spec-first คุณแก้ไขไฟล์โดยตรง คอมมิตไปยัง Git จาก Apidog และซิงค์โดยอัตโนมัติ ในโหมดปกติ คุณแก้ไขผ่านฟอร์ม และการส่งออก Git เป็นแบบแมนนวลหรือตามกำหนดเวลา
ฉันสามารถเปลี่ยนโปรเจกต์ Apidog ที่มีอยู่เป็นโหมด Spec-first ได้หรือไม่?
ปัจจุบัน โหมด Spec-first ต้องสร้างโปรเจกต์ใหม่ที่เชื่อมต่อกับพื้นที่เก็บข้อมูล Git คุณสามารถนำเข้าข้อกำหนด OpenAPI ของโปรเจกต์ที่มีอยู่ของคุณไปยังโปรเจกต์ Spec-first ใหม่เพื่อย้ายเนื้อหาได้
รองรับผู้ให้บริการ Git รายใดบ้าง?
Apidog รองรับ GitHub, GitLab, Azure DevOps และ Bitbucket สำหรับโปรเจกต์ Spec-first คุณสามารถเชื่อมต่อพื้นที่เก็บข้อมูลจากผู้ให้บริการเหล่านี้ได้ในระหว่างการสร้างโปรเจกต์
ฉันต้องมีสิทธิ์ผู้ดูแลระบบในพื้นที่เก็บข้อมูลของฉันหรือไม่?
จำเป็นต้องมีสิทธิ์ผู้ดูแลระบบสำหรับการติดตั้ง webhook ซึ่งช่วยให้สามารถซิงค์อัตโนมัติเมื่อพื้นที่เก็บข้อมูลของคุณได้รับการพุช หากไม่มีการซิงค์ด้วย webhook คุณยังคงสามารถใช้ Git Pull ด้วยตนเองเพื่อซิงค์การเปลี่ยนแปลงได้ สิทธิ์ในการเขียนก็เพียงพอสำหรับการพุชการเปลี่ยนแปลงจาก Apidog
ฉันสามารถใช้โหมด Spec-first กับพื้นที่เก็บข้อมูลที่ว่างเปล่าได้หรือไม่?
ได้ หากพื้นที่เก็บข้อมูลของคุณไม่มีไฟล์ OpenAPI ที่มีอยู่ Apidog จะเริ่มต้นใหม่ คุณสร้างข้อกำหนดในพื้นที่ทำงาน Specs และพุชไปยังพื้นที่เก็บข้อมูลของคุณ การคอมมิตครั้งแรกจะเป็นการสร้างรากฐานข้อกำหนดของคุณ
สาขา Sprint แตกต่างจากสาขา Git อย่างไร?
สาขา Sprint ใน Apidog สอดคล้องกับสาขา Git ในพื้นที่เก็บข้อมูลของคุณ เมื่อคุณสร้างสาขา Sprint ใน Apidog มันจะสร้างสาขาที่สอดคล้องกันใน Git การเปลี่ยนแปลงในสาขา Sprint จะซิงค์กับสาขา Git นั้น การรวมสาขา Sprint คือการรวมสาขา Git ที่สอดคล้องกัน
จะเกิดอะไรขึ้นหากมีคนแก้ไขพื้นที่เก็บข้อมูล Git โดยตรง?
หากติดตั้งการซิงค์ webhook การพุชไปยัง Git จะกระตุ้นการซิงค์อัตโนมัติไปยัง Apidog หากคุณกำลังทำงานอยู่ใน Apidog และมีคนพุชไปยัง Git คุณจะเห็นสถานะการซิงค์ที่ระบุว่ามีการอัปเดตที่รอดำเนินการ ใช้ Git Pull เพื่อดึงการเปลี่ยนแปลงเหล่านั้นเข้ามาใน Apidog
ฉันสามารถแก้ไขข้อกำหนดได้ทั้งในมุมมองโค้ดและมุมมองฟอร์มหรือไม่?
ได้ พื้นที่ทำงาน Specs มีตัวแก้ไขโค้ดสำหรับการแก้ไข YAML/JSON โดยตรง และมุมมองฟอร์มสำหรับโหนด OpenAPI ที่รองรับ (endpoints, schemas, definitions) คุณสามารถสลับระหว่างมุมมองได้ตามต้องการ ทั้งสองวิธีจะอัปเดตไฟล์ที่อยู่ภายใต้ใน Git
การขอรวมทำงานอย่างไรสำหรับสถานการณ์การทดสอบ?
สถานการณ์การทดสอบจะรวมแยกต่างหากจาก endpoints และ schemas หลังจากรวมทรัพยากร API ไปยังสาขาหลัก ให้เลื่อนเมาส์ไปที่สถานการณ์การทดสอบในสาขา Sprint แล้วเลือก Merge to Main (รวมเข้าสู่หลัก) ปัจจุบันมีเพียงผู้ดูแลระบบโปรเจกต์เท่านั้นที่สามารถรวมสถานการณ์การทดสอบเข้าสู่สาขาหลักที่ได้รับการป้องกันได้