> For AI agents: the site index is at [llms.txt](https://draftpunkdocs.io/llms.txt). Every page has a Markdown version at the same path plus `.md`.

מדריך

# מה זה Documentation CI/CD?

עודכן לאחרונה: 22 באוקטובר 2026

**Documentation CI/CD** היא שיטה לעדכון תיעוד באותו אופן שצוותי פיתוח משחררים קוד: כל שינוי במוצר מפעיל אוטומטית עדכון תיעוד, שעובר בדיקות ושער אישור אנושי לפני שהוא מתפרסם.

השם שאול מ־CI/CD בפיתוח תוכנה (אינטגרציה רציפה ומסירה רציפה), שבו כל שינוי בקוד נבנה, נבדק ומשוחרר דרך פייפליין אוטומטי. Documentation CI/CD מיישם את אותו רעיון על מרכזי עזרה, מאגרי ידע ותיעוד למפתחים, כך שהתיעוד משתנה כשהמוצר משתנה, ולא שבועות אחר כך.

## איך עובד פייפליין של Documentation CI/CD

לפייפליין טיפוסי יש חמישה שלבים. השלב הרביעי, השער האנושי, הוא מה שהופך אותו ל־CI/CD ולא לפרסום אוטומטי.

חמשת השלבים של פייפליין Documentation CI/CD.

טריגר ← טיוטה ← בדיקה ← אישור (שער אנושי) ← פרסום. השינוי הבא במוצר מפעיל את הפייפליין מחדש.

1. **טריגר.** שינוי מאותת שייתכן שהתיעוד צריך עדכון: Pull Request שמוזג, טיקט שעובר ל־Done, בקשה בערוץ צ׳אט, או שאלת תמיכה שחוזרת על עצמה.
2. **טיוטה.** הפייפליין קורא את השינוי ואת ההקשר שלו (ה־diff בקוד, הטיקט, כל מפרט מקושר) וכותב טיוטה למאמר חדש או עדכון למאמר קיים. רוב הפייפליינים משתמשים במודל AI בשלב הזה.
3. **בדיקה.** הטיוטה נבדקת לפני שמישהו סוקר אותה: סגנון הבית, טענות שלא ניתן היה לאמת, והשפעה, כלומר מאמרים אחרים שאותו שינוי הפך ללא מעודכנים.
4. **אישור.** אדם עם שיקול דעת בתיעוד סוקר את הטיוטה ומאשר, עורך או דוחה אותה.
5. **פרסום.** שינויים שאושרו עולים לאוויר. עדכון למאמר קיים מחליף את הגרסה החיה במקום, באותה כתובת.

## מה Documentation CI/CD הוא לא

מבלבלים אותו לעיתים קרובות עם שני רעיונות קרובים. כל אחד מהם עונה על שאלה אחרת.

|  | Documentation CI/CD | Docs-as-code | עוזר כתיבה מבוסס AI |
| --- | --- | --- | --- |
| עונה על | מתי ואיך התיעוד משתנה | איפה התיעוד נמצא | מי כותב את הטקסט |
| מתחיל כש | המוצר משתנה | כותב מבצע commit | מישהו מבקש |
| שער אנושי | חובה | Code review | אופציונלי |

Documentation CI/CD יכול לרוץ על מאגר docs-as-code או על מאגר ידע מתארח. ובלי שער האישור, זה לא CI/CD, אלא סתם פרסום אוטומטי. גם לפייפליינים של תוכנה יש שערים.

## למה צוותים מאמצים את זה

- **התיעוד מפגר אחרי קצב השחרורים.** כשהפיתוח משחרר כל יום והתיעוד מתעדכן ידנית, הפער גדל עם כל גרסה.
- **עוזרי תמיכה מבוססי AI עונים מתוך מרכז העזרה.** מאמר לא מעודכן הופך לתשובה שגויה ללקוח.
- **פחות כותבים מכסים יותר מוצר.** הפייפליין מטפל בזיהוי ובטיוטות הראשונות, כך שהכותבים משקיעים את הזמן שלהם בשיקול דעת ובבדיקה.

## אבני הבניין

- **טריגרים** שמחוברים למקומות שבהם קורה השינוי: מאגרי קוד, מערכות ניהול משימות, צ׳אט ומערכות תמיכה.
- **הקשר:** ה־diff, הטיקט והמפרטים המקושרים שמהם נבנית כל טיוטה.
- **ניתוח השפעה:** איתור כל מאמר ששינוי משפיע עליו, לא רק המובן מאליו.
- **בדיקות איכות:** בדיקת סגנון אוטומטית, למשל בכלי קוד פתוח כמו Vale, ורשימה של טענות שהטיוטה לא הצליחה לאמת.
- **שער אישור** עם מאשר מוגדר ותיעוד ביקורת.
- **פרסום** לפלטפורמה שהתיעוד כבר נמצא בה.

## שאלות נפוצות

### האם Documentation CI/CD זה אותו דבר כמו Continuous Documentation?

יש חפיפה. Continuous Documentation בדרך כלל מתאר שמירה על סנכרון בין התיעוד לקוד, לרוב בתוך מאגר הקוד. Documentation CI/CD מתאר את הפייפליין המלא, מהטריגר ועד פרסום מאושר, כולל תיעוד שנמצא מחוץ למאגר, כמו מרכז עזרה.

### האם זה מחייב להעביר את התיעוד ל־Git?

לא. הפייפליין יכול לפרסם למאגר ידע או למרכז עזרה מתארח דרך ה־API שלו, וגם למאגר docs-as-code.

### מי מאשר את השינויים?

בדרך כלל כותב טכני, או מנהל המוצר כשאין כותב. המאשר הוא השער. שום דבר לא מתפרסם בלי האישור שלו.

Draft Punk מפעיל Documentation CI/CD כשירות מנוהל לצוותי B2B SaaS וסייבר, על מאגר הידע שהם כבר משתמשים בו. [איך זה עובד](https://draftpunkdocs.io/he/#how).

[→ חזרה ל־Draft Punk](https://draftpunkdocs.io/he/)