การทำงานร่วมกันของทีม OpenAPI จะเริ่มติดขัดทันทีที่สเปกของคุณย้ายเข้าสู่ Git ไม่ใช่เพราะ Git ไม่เหมาะกับสเปก แต่เป็นเพราะ Git เป็นสถานที่ที่เหมาะสมสำหรับสเปกเหล่านั้น เพียงแต่เครื่องมือตรวจสอบของ Git ถูกสร้างขึ้นมาสำหรับวิศวกรที่ตรวจสอบโค้ด ไม่ใช่สำหรับ QA, ฝ่าย frontend หรือผู้จัดการผลิตภัณฑ์ที่จำเป็นต้องมีส่วนร่วมในการออกแบบ API ด้วยเช่นกัน
หากทีมของคุณได้นำวิธีการที่ใช้ไฟล์เป็นหลัก (จัดเก็บสเปก OpenAPI ในรูปแบบ YAML หรือ JSON ใน repository) มาใช้แล้ว คุณอาจเคยประสบปัญหานี้: สเปกมีการควบคุมเวอร์ชันและสามารถตรวจสอบได้ แต่ผู้ที่ไม่ใช่วิศวกรยังคงต้องตรวจสอบการแสดงตัวอย่างของ Stoplight ในเบราว์เซอร์ ถามคำถามผ่าน Slack DMs และรอให้นักพัฒนาอัปเดตไฟล์ก่อนจึงจะสามารถทดสอบอะไรได้ บทความเรื่อง api-spec-as-code ครอบคลุมเหตุผลที่ Git เป็นแหล่งข้อมูลที่ถูกต้องที่สุด (source of truth) บทความนี้จะกล่าวถึงช่องว่างในการทำงานร่วมกันที่ยังคงมีอยู่เมื่อคุณไปถึงจุดนั้น และวิธีที่เครื่องมืออย่าง Apidog มาช่วยเติมเต็มช่องว่างนั้นโดยไม่ต้องดึงสเปกของคุณออกจาก Git
ช่องว่างที่ Git ไม่สามารถปิดได้ด้วยตัวเอง
Git จัดการประวัติการเปลี่ยนแปลง, การแตก branch และความแตกต่างของ pull request สิ่งเหล่านี้เป็นพื้นฐานที่ทรงพลังสำหรับวิศวกร แต่ไม่ตอบสนองความต้องการในการทำงานร่วมกันหลายอย่างที่เกิดขึ้นเมื่อทีมของคุณทั้งหมดเริ่มทำงานจากสเปกที่ใช้ร่วมกัน
ความคิดเห็นระหว่างการออกแบบจากผู้ที่ไม่ใช่วิศวกร วิศวกร QA ที่พบรูปแบบข้อผิดพลาดที่ไม่สอดคล้องกันใน PR diff ไม่สามารถใส่คำอธิบายประกอบ `openapi.yaml` บรรทัดที่ 247 ด้วยคำถามที่เป็นหัวข้อได้อย่างง่ายดาย อินเทอร์เฟซ PR ของ GitHub ใช้ได้ดีสำหรับผู้ตรวจสอบโค้ด แต่ไม่เป็นธรรมชาติสำหรับผู้มีส่วนได้ส่วนเสียที่อ่านสเปกเป็นเอกสาร ไม่ใช่เป็นซอร์สโค้ด
Mock แบบสดที่เชื่อมโยงกับ branch ปัจจุบัน นักพัฒนา frontend มักต้องการ mock server ที่ทำงานได้ก่อนที่การใช้งาน backend จะเสร็จสิ้น ด้วยไฟล์ YAML ดิบใน Git การสร้าง mock นั้นต้องใช้เครื่องมือแยกต่างหากหรือขั้นตอนด้วยตนเอง ไฟล์ดังกล่าวไม่ใช่วัตถุที่รันได้โดยอัตโนมัติ
การกำหนดเส้นทางการแจ้งเตือนตามบทบาท เมื่อทีม backend รวมการเปลี่ยนแปลงที่ส่งผลกระทบ (breaking change) ไปยังสเปกที่ใช้ร่วมกัน ทีมปลายน้ำ (frontend, mobile, QA) จำเป็นต้องรู้ Git webhooks สามารถแจ้งเตือนช่องทาง Slack ได้ แต่จะส่งสัญญาณ "ไฟล์มีการเปลี่ยนแปลง" ทั่วไป การแจ้งเตือนที่รับรู้บทบาทซึ่งบอกว่า "การตอบกลับของ endpoint /payments เปลี่ยนแปลงไป นี่คือผู้ใช้ที่ได้รับผลกระทบ" ต้องใช้ชั้นข้อมูลเพิ่มเติม
การควบคุมการเข้าถึงสำหรับเอกสาร สเปกใน GitHub repo สาธารณะสามารถอ่านได้โดยทุกคน Private repo ช่วยแก้ปัญหานั้นได้ แต่การควบคุมการเข้าถึงในระดับผู้ใช้งาน ซึ่งพาร์ทเนอร์ภายนอกสามารถอ่านเอกสาร endpoint ได้ แต่ไม่สามารถอ่าน Internal Admin API ได้นั้นไม่ใช่สิ่งที่ Git จัดหาให้โดยกำเนิด
ช่องว่างทั้งสี่นี้ไม่ใช่ข้อโต้แย้งต่อต้าน Git แต่เป็นข้อโต้แย้งสำหรับการเชื่อมต่อ Git กับชั้นการทำงานร่วมกัน
สิ่งที่ชั้นการทำงานร่วมกันทำ (และไม่ทำ)
กรอบความคิดที่เป็นประโยชน์ที่นี่คือ: Git ยังคงเป็นแหล่งข้อมูลที่ถูกต้องที่สุด (source of truth); ชั้นการทำงานร่วมกันคือสิ่งที่เชื่อมต่อไฟล์นั้นกับเอกสาร, mocks, การตรวจสอบ, การแจ้งเตือน และรายงาน CI/CD
เครื่องมือในพื้นที่นี้แบ่งออกเป็นสองหมวดหมู่หลัก:
| หมวดหมู่ | ตัวอย่าง | จุดแข็ง | สิ่งที่เพิ่มเติมนอกเหนือจาก Git |
|---|---|---|---|
| แพลตฟอร์มสเปกแบบโฮสต์ | Stoplight, SwaggerHub | UI ที่สวยงาม, ความคิดเห็น, การควบคุมการเข้าถึง | ดูแลสำเนาสเปกของตนเอง; Git เป็นทางเลือก |
| ชั้นการทำงานร่วมกันแบบไฟล์เนทีฟ | Apidog (โหมด Spec-First, รุ่นเบต้า), Redocly | ทำงานจากไฟล์ที่คุณคอมมิต; Git ยังคงเป็นแหล่งข้อมูลหลัก | เพิ่มชั้นการทำงานร่วมกัน, mocks และ CI เหนือไฟล์ |
| ไคลเอนต์ API แบบ Git-native | Bruno, Insomnia | การซิงค์ไฟล์ที่ยอดเยี่ยม, collections-as-code | หยุดที่ชั้นคำขอ; เอกสาร/mocks/รายงานไม่ได้เชื่อมต่อโดยอัตโนมัติ |
การทำความเข้าใจตารางนี้จะช่วยป้องกันข้อผิดพลาดที่พบบ่อย: การเลือกเครื่องมือตามคุณสมบัติเดียวแล้วพบว่ามันอ่อนแอในด้านอื่น
การจัดการ Git ของ Bruno นั้นแข็งแกร่ง แต่หยุดอยู่แค่ที่ชั้นการร้องขอ
Bruno สมควรได้รับการอธิบายอย่างตรงไปตรงมา ก่อนที่คุณจะออกแบบเวิร์กโฟลว์โดยใช้มัน Bruno Ultimate โดยเฉพาะอย่างยิ่ง มีการจัดเก็บคอลเลกชันแบบไฟล์เนทีฟ, การรวม Git ที่แข็งแกร่ง, SSO, SCIM, hooks สำหรับตัวจัดการความลับ และการบันทึกการตรวจสอบ หากความต้องการหลักของคุณคือการดำเนินการร้องขอตามสเปกที่คุณจัดการแยกต่างหาก เรื่อง Git ของ Bruno นั้นมั่นคงอย่างแท้จริง
สิ่งที่ Bruno หยุดอยู่คือที่ชั้นการร้องขอ มันไม่สร้างเอกสาร API โดยอัตโนมัติจากไฟล์ OpenAPI ที่คอมมิตไว้, มันไม่สร้าง mock server ที่รับรู้ branch จากไฟล์นั้น, และมันไม่กำหนดเส้นทางการแจ้งเตือนเฉพาะบทบาทเมื่อเส้นทางสเปกมีการเปลี่ยนแปลง สิ่งเหล่านี้ต้องใช้เครื่องมือโฮสต์แยกต่างหาก หรือแพลตฟอร์มที่เชื่อมโยงการจัดเก็บแบบไฟล์เนทีฟกับคุณสมบัติการทำงานร่วมกัน
ค่าใช้จ่ายในการรวมระบบเป็นเรื่องจริง หากคุณกำลังประเมิน Bruno สำหรับทีมที่ใช้ Stoplight สำหรับเอกสารและ mock server อยู่แล้ว คุณไม่ได้กำลังแทนที่ Stoplight; คุณกำลังเพิ่ม Bruno เข้าไปพร้อมกัน นั่นอาจเป็นการตัดสินใจที่ถูกต้อง แต่ก็ควรระบุสถาปัตยกรรมให้ชัดเจน
Apidog Spec-First Mode เติมเต็มช่องว่างได้อย่างไร
Apidog's Spec-First Mode (ปัจจุบันอยู่ในช่วงเบต้า) ได้รับการออกแบบมาเพื่อสถาปัตยกรรมนี้โดยเฉพาะ คุณคอมมิตไฟล์ openapi.yaml ไปยัง Git; Apidog จะอ่านไฟล์นั้นเป็นแหล่งข้อมูลที่ถูกต้องที่สุด และเพิ่มคุณสมบัติการทำงานร่วมกันโดยไม่ต้องแยกสเปกเข้าสู่ฐานข้อมูลของตนเอง
นี่คือลักษณะของเวิร์กโฟลว์ในการปฏิบัติจริง
ขั้นตอนที่ 1: เชื่อมโยง Git repo ของคุณ
ใน Apidog คุณเชื่อมต่อโปรเจกต์เข้ากับ GitHub, GitLab หรือ Bitbucket repository และชี้ไปยังเส้นทางไฟล์ OpenAPI คู่มือ apidog-git-integration-sync ครอบคลุมขั้นตอนการเชื่อมต่อโดยละเอียด
# openapi.yaml (committed in your repo at api/openapi.yaml)
openapi: "3.1.0"
info:
title: Payments API
version: "2.4.0"
paths:
/payments:
post:
summary: Create a payment
operationId: createPayment
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/PaymentRequest"
responses:
"201":
description: Payment created
content:
application/json:
schema:
$ref: "#/components/schemas/PaymentResponse"
"422":
description: Validation error
content:
application/json:
schema:
$ref: "#/components/schemas/ValidationError"
components:
schemas:
PaymentRequest:
type: object
required: [amount, currency, source]
properties:
amount:
type: integer
description: Amount in smallest currency unit (e.g., cents)
currency:
type: string
enum: [usd, eur, gbp]
source:
type: string
description: Payment method token
PaymentResponse:
type: object
properties:
id:
type: string
status:
type: string
enum: [pending, completed, failed]
ValidationError:
type: object
properties:
code:
type: string
message:
type: string
ขั้นตอนที่ 2: ตรวจสอบและแสดงความคิดเห็นจากสเปก ไม่ใช่จาก diff
เมื่อเชื่อมโยงแล้ว Apidog จะแสดงผลสเปกเป็นเอกสารแบบอินเทอร์แอคทีฟ สมาชิกในทีมสามารถเพิ่มความคิดเห็นได้โดยตรงไปยัง endpoints, schemas และตัวอย่างการตอบกลับ วิศวกร QA ที่ตรวจสอบเส้นทาง POST /payments สามารถตั้งค่าสถานะหัวข้อ idempotency-key ที่หายไปได้โดยไม่ต้องแก้ไขไฟล์ YAML หรือต้องการบัญชี GitHub ที่มีสิทธิ์คอมมิต
ความคิดเห็นจะถูกจัดเรียงเป็นเธรดและแก้ไขได้ เมื่อวิศวกรอัปเดต openapi.yaml และ push คอมมิตใหม่ โปรเจกต์ Apidog ที่เชื่อมโยงจะสะท้อนการเปลี่ยนแปลง การสนทนาจะยังคงติดอยู่กับองค์ประกอบของสเปก ไม่ใช่หมายเลขบรรทัด
ขั้นตอนที่ 3: สร้าง mock เฉพาะ branch โดยอัตโนมัติ
ด้วย Spec-First Mode แต่ละ branch ของสเปกของคุณสามารถสร้าง mock server ที่แยกต่างหากได้ นักพัฒนา Frontend ที่ทำงานกับ branch feature/payment-v2 จะได้รับ URL mock ที่สะท้อน schema ใหม่บน branch นั้น URL mock สำหรับ production จะยังคงเสถียร
สิ่งนี้ช่วยขจัดปัญหา "รอ backend" โดยที่ไม่มีใครต้องรัน npx @stoplight/prism-cli mock openapi.yaml ด้วยตนเอง
ขั้นตอนที่ 4: กำหนดเส้นทางการแจ้งเตือนไปยังทีมที่เหมาะสม
เมื่อเส้นทางหรือ schema ในสเปกมีการเปลี่ยนแปลง (เมื่อรวมเข้าด้วยกัน) Apidog สามารถส่งการแจ้งเตือนไปยังช่องทางที่กำหนดค่าไว้ได้ คุณกำหนดเส้นทางเหตุการณ์การเปลี่ยนแปลง /payments ไปยังช่องทาง Slack ที่ทีม frontend และ mobile ติดตามอยู่ คุณกำหนดเส้นทางเหตุการณ์การเปลี่ยนแปลง /admin ไปยังช่องทางภายในแยกต่างหาก
สำหรับการตั้งค่า Slack และ Teams โปรดดู Slack incoming webhooks และ Microsoft Teams incoming webhooks สำหรับการกำหนดค่า webhook บนแพลตฟอร์มเหล่านั้น การตั้งค่าการแจ้งเตือนของ Apidog ช่วยให้คุณสามารถผูกช่องทางเหล่านี้ตามแท็ก endpoint หรือคำนำหน้าเส้นทาง
สิ่งที่ควรตรวจสอบในการทดลอง: ความละเอียดของการกำหนดเส้นทางการแจ้งเตือน (ต่อแท็กเทียบกับต่อเส้นทาง) และวิธีที่การควบคุมการเข้าถึงสำหรับผู้ใช้งานเอกสารจับคู่กับโครงสร้างบทบาทขององค์กรของคุณ สิ่งเหล่านี้เป็นความสามารถที่ต้องประเมินตามความต้องการเฉพาะของคุณ
การเชื่อมต่อชั้นการทำงานร่วมกันเข้ากับ CI/CD
ชั้นการทำงานร่วมกันจะมีประโยชน์สูงสุดเมื่อเชื่อมต่อกับไปป์ไลน์ของคุณ ไม่ใช่แค่เครื่องมือแชทของทีมคุณเท่านั้น Apidog's CLI ช่วยให้คุณรัน contract tests กับสเปกที่คอมมิตไว้ในขั้นตอน CI เมื่อรวมกับ linter เช่น Spectral หรือ Redocly CLI สำหรับการตรวจสอบสเปก คุณจะได้ไปป์ไลน์ที่บังคับใช้คุณภาพของสเปกและแสดงบริบทการทำงานร่วมกันพร้อมกัน
ขั้นตอน GitHub Actions ทั่วไปอาจมีลักษณะดังนี้:
# .github/workflows/api-spec.yml
name: API spec validation and test
on: [push, pull_request]
jobs:
validate-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate OpenAPI spec (Spectral)
run: |
npm install -g @stoplight/spectral-cli
spectral lint api/openapi.yaml --ruleset .spectral.yaml
- name: Run Apidog contract tests
env:
APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}
run: |
npx apidog-cli run \
--project-id ${{ vars.APIDOG_PROJECT_ID }} \
--test-suite "Payments API smoke" \
--environment staging
OpenAPI spec เป็น การอ้างอิงหลักสำหรับสิ่งที่ API ของคุณสัญญาไว้ การรัน contract tests กับไฟล์ที่คอมมิตหมายความว่า pipeline CI ของคุณจะล้มเหลวหากบริการที่กำลังรันอยู่เบี่ยงเบนไปจาก spec ไม่ใช่แค่เมื่อ unit tests ผ่านเท่านั้น
สำหรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับรูปแบบเวิร์กโฟลว์แบบ Git-native ที่เหมาะกับเรื่องนี้ git-native-api-workflow จะอธิบายวิธีสร้างไปป์ไลน์แบบครบวงจร
การเปรียบเทียบตัวเลือกหลักสำหรับทีมที่ใช้ไฟล์เป็นหลัก
หากคุณกำลังประเมินเครื่องมือหลังจากอ่านบทความนี้ นี่คือการเปรียบเทียบโดยตรงในมิติที่สำคัญสำหรับการทำงานร่วมกันที่อิงตามไฟล์ ความสามารถที่ทำเครื่องหมายด้วยเครื่องหมายคำถามควรค่าแก่การตรวจสอบในการทดลองของคุณเอง เนื่องจากอาจแตกต่างกันไปตามระดับแผนและโครงสร้างการกำหนดค่า
| ความสามารถ | Stoplight | SwaggerHub | Apidog (Spec-First, เบต้า) |
|---|---|---|---|
| Git เป็นแหล่งข้อมูลหลัก | ทางเลือก (สำเนาของตนเองโดยค่าเริ่มต้น) | ทางเลือก | ใช่ (โหมด Spec-First) |
| ความคิดเห็นระหว่างการออกแบบ | ใช่ | ใช่ | ใช่ |
| Mocks เฉพาะ Branch | ใช่ | บางส่วน | ใช่ |
| การเข้าถึงเอกสารตามบทบาท | ใช่ | ใช่ | ตรวจสอบในการทดลอง |
| การนำ Schema กลับมาใช้ซ้ำข้ามโปรเจกต์ | ใช่ | ใช่ | ตรวจสอบในการทดลอง |
| การทดสอบ Contract ของ CI/CD | ผ่าน Prism | จำกัด | ใช่ (Apidog CLI) |
| กฎ Lint แบบกำหนดเอง | ผ่าน Spectral | จำกัด | ตรวจสอบในการทดลอง |
| SSO/SCIM | แผนแบบชำระเงิน | Enterprise | ตรวจสอบในการทดลอง |
| การกำหนดเส้นทางการแจ้งเตือน | ผ่าน webhooks | จำกัด | ใช่ |
| File-native (ไม่มีการคัดลอกซ้ำสอง) | ไม่ | ไม่ | ใช่ (Spec-First) |
สำหรับการเปรียบเทียบที่กว้างขึ้นซึ่งรวมถึง SwaggerHub โปรดดู swaggerhub-vs-apidog-collaboration
คำถามที่พบบ่อย
เราสามารถใช้ Git PR reviews ร่วมกับ Apidog comments ได้หรือไม่?
ได้ เวิร์กโฟลว์ทั้งสองนี้ให้บริการกลุ่มเป้าหมายที่แตกต่างกัน Git PR reviews สำหรับวิศวกรที่ตรวจสอบการเปลี่ยนแปลง YAML; Apidog comments สำหรับผู้มีส่วนได้ส่วนเสียด้านผลิตภัณฑ์, QA และ frontend ที่ตรวจสอบสเปกในฐานะเอกสาร ทั้งสองสามารถทำงานควบคู่กันไปได้โดยไม่มีข้อขัดแย้ง ไฟล์ที่คอมมิตยังคงเป็นแหล่งข้อมูลที่ถูกต้องที่สุดเพียงแหล่งเดียวสำหรับทั้งสอง
จะเกิดอะไรขึ้นหากมีคนแก้ไขสเปกใน Apidog แทนที่จะแก้ไขไฟล์?
ในโหมด Spec-First การแก้ไขที่ทำผ่านอินเทอร์เฟซ Apidog สามารถผลักกลับไปยัง Git เป็นคอมมิตได้ เวิร์กโฟลว์คือ: แก้ไขใน UI, คอมมิตไปยัง branch, ตรวจสอบ PR ใน Git, ผสาน นี่เป็นสิ่งที่ควรยืนยันในการทดลองของคุณ เนื่องจากทิศทางการซิงค์ที่แน่นอน (Apidog-to-Git เทียบกับ Git-to-Apidog) จะส่งผลต่อวิธีที่ทีมของคุณตัดสินใจว่าการแก้ไขมีที่มาอย่างไร สำหรับการแนะนำทีละขั้นตอนของโหมด Spec-First เอง โปรดดู spec-first-mode-apidog-beta-walkthrough
โหมด Spec-First ทำงานร่วมกับ monorepos ที่มีไฟล์ OpenAPI หลายไฟล์ได้หรือไม่?
ไฟล์สเปกหลายไฟล์ต่อโปรเจกต์เป็นรูปแบบ monorepo ที่พบบ่อย Apidog รองรับหลายโปรเจกต์ โดยแต่ละโปรเจกต์จะเชื่อมโยงกับเส้นทางไฟล์ที่แตกต่างกัน ไม่ว่าโปรเจกต์ Apidog เดียวจะสามารถแมปกับไฟล์สเปกหลายไฟล์ได้หรือไม่ หรือกฎ lint แบบกำหนดเองสามารถใช้ร่วมกันระหว่างโปรเจกต์เหล่านั้นได้หรือไม่นั้น ควรทดสอบในการทดลองโดยเทียบกับโครงสร้าง repo เฉพาะของคุณ
สิ่งนี้เปรียบเทียบกับ Redocly สำหรับทีมที่ใช้ไฟล์เป็นหลักอย่างไร?
Redocly CLI มีความแข็งแกร่งสำหรับการ linting สเปก การรวมกลุ่ม และการสร้างเอกสารจากไฟล์ แพลตฟอร์มแบบโฮสต์ของ Redocly เพิ่มคุณสมบัติการตรวจสอบและทีม ความแตกต่างคล้ายกับการเปรียบเทียบ Stoplight: ชั้นการทำงานร่วมกันของ Redocly มีให้ใช้งานในแผนแบบชำระเงิน ความแตกต่างของ Apidog คือการครอบคลุมที่รวม mocks, การทดสอบ contract, การแจ้งเตือน และเอกสารในแพลตฟอร์มเดียวที่อ่านจากไฟล์ที่คอมมิตของคุณ
แล้วเครื่องมือของ OpenAPI Initiative เองล่ะ?
OpenAPI Initiative เผยแพร่สเปกเอง แต่ไม่ได้เผยแพร่แพลตฟอร์มการทำงานร่วมกัน ระบบนิเวศของเครื่องมือที่ใช้สเปกนี้เป็นสิ่งที่คุณกำลังเลือกใช้ เครื่องมือใดๆ ในบทความนี้ที่อ้างว่า "รองรับ OpenAPI" ควรได้รับการทดสอบกับ OpenAPI 3.1 หากนั่นคือเวอร์ชันสเปกของคุณ เนื่องจากเวอร์ชัน 3.1 มีการรองรับที่แตกต่างกัน
สรุป
หากทีมของคุณจัดเก็บสเปก OpenAPI ใน Git แล้ว ปัญหาการจัดการไฟล์ก็ได้รับการแก้ไขแล้ว แต่ปัญหาการทำงานร่วมกันยังคงอยู่ ความคิดเห็นระหว่างการออกแบบจากผู้ที่ไม่ใช่วิศวกร, mock เฉพาะ branch สำหรับ frontend, การแจ้งเตือนที่มุ่งเป้าตามบทบาทเมื่อมีการเปลี่ยนแปลงที่ส่งผลกระทบ, และเอกสารที่ควบคุมการเข้าถึงได้ ล้วนต้องการชั้นข้อมูลที่เชื่อมโยงไฟล์ที่คุณคอมมิตเข้ากับเวิร์กโฟลว์ส่วนที่เหลือของทีม
ชั้นข้อมูลนั้นไม่จำเป็นต้องมาแทนที่ Git ควรจะอ่านจาก Git สร้างขึ้นบน Git และไม่ขัดขวางเมื่อวิศวกรกำลังตรวจสอบโค้ดใน PR
หากการตั้งค่าปัจจุบันของคุณใช้ Stoplight หรือการจัดการเอกสารที่ใช้ร่วมกันเพื่อการทำงานร่วมกัน ในขณะที่ Git จัดการการควบคุมเวอร์ชัน นั่นคือสถาปัตยกรรมที่ Apidog Spec-First Mode ได้รับการออกแบบมาเพื่อรวมเข้าด้วยกัน เนื่องจากยังอยู่ในช่วงเบต้า โปรดทำการทดลองที่เน้นไปที่คุณสมบัติที่ทีมของคุณต้องการมากที่สุด (การควบคุมการเข้าถึงเอกสาร, การนำ schema ข้ามโปรเจกต์กลับมาใช้ซ้ำ, ความละเอียดของการแจ้งเตือน) ก่อนที่จะนำไปใช้ ดาวน์โหลด Apidog และเชื่อมต่อกับ branch ของ repo สเปกที่มีอยู่ของคุณเพื่อดูว่าชั้นการทำงานร่วมกันจะเข้ากับเวิร์กโฟลว์ที่ทีมของคุณมีอยู่แล้วได้อย่างไร