מדריך
מה זה Documentation CI/CD?
עודכן לאחרונה: 22 באוקטובר 2026
Documentation CI/CD היא שיטה לעדכון תיעוד באותו אופן שצוותי פיתוח משחררים קוד: כל שינוי במוצר מפעיל אוטומטית עדכון תיעוד, שעובר בדיקות ושער אישור אנושי לפני שהוא מתפרסם.
השם שאול מ־CI/CD בפיתוח תוכנה (אינטגרציה רציפה ומסירה רציפה), שבו כל שינוי בקוד נבנה, נבדק ומשוחרר דרך פייפליין אוטומטי. Documentation CI/CD מיישם את אותו רעיון על מרכזי עזרה, מאגרי ידע ותיעוד למפתחים, כך שהתיעוד משתנה כשהמוצר משתנה, ולא שבועות אחר כך.
איך עובד פייפליין של Documentation CI/CD
לפייפליין טיפוסי יש חמישה שלבים. השלב הרביעי, השער האנושי, הוא מה שהופך אותו ל־CI/CD ולא לפרסום אוטומטי.
- טריגר. שינוי מאותת שייתכן שהתיעוד צריך עדכון: Pull Request שמוזג, טיקט שעובר ל־Done, בקשה בערוץ צ׳אט, או שאלת תמיכה שחוזרת על עצמה.
- טיוטה. הפייפליין קורא את השינוי ואת ההקשר שלו (ה־diff בקוד, הטיקט, כל מפרט מקושר) וכותב טיוטה למאמר חדש או עדכון למאמר קיים. רוב הפייפליינים משתמשים במודל AI בשלב הזה.
- בדיקה. הטיוטה נבדקת לפני שמישהו סוקר אותה: סגנון הבית, טענות שלא ניתן היה לאמת, והשפעה, כלומר מאמרים אחרים שאותו שינוי הפך ללא מעודכנים.
- אישור. אדם עם שיקול דעת בתיעוד סוקר את הטיוטה ומאשר, עורך או דוחה אותה.
- פרסום. שינויים שאושרו עולים לאוויר. עדכון למאמר קיים מחליף את הגרסה החיה במקום, באותה כתובת.
מה 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 וסייבר, על מאגר הידע שהם כבר משתמשים בו. איך זה עובד.