איך לעדכן תיעוד באופן אוטומטי בכל שחרור גרסה

עודכן ב-3 בנובמבר 2026

כדי לעדכן תיעוד באופן אוטומטי בכל שחרור, התחילו משימת תיעוד מהשחרור עצמו: שחרור GitHub שפורסם, אירוע שחרור ב-GitLab, תג ב-Bitbucket או רשומה חדשה בדף עדכוני הגרסאות הציבורי שלכם. המשימה קוראת את הערות השחרור, מוצאת את דפי העזרה והסרטונים שהשחרור משפיע עליהם, מנסחת את השינויים ושולחת אותם לאדם לאישור. עבור תיעוד המיועד ללקוחות, שלב הסקירה הזה הוא מה ששומר על אוטומציית התיעוד בטוחה.

מדריך זה עובר על תהליך העבודה הזה עם כל כלי (GitHub Actions, GitLab, Bitbucket, דף עדכוני גרסאות), ולאחר מכן מראה כיצד ה-Autopilot של Clevera מריץ את אותו תהליך עבור מרכז עזרה עם סרטונים.

מהו תיעוד רציף?#

Swimm, שהפכה את המונח לפופולרי, מגדירה תיעוד רציף כיצירה ועדכון של תיעוד באופן מצטבר כחלק מתהליך הפיתוח, במקום בפרויקטים מזדמנים של השלמת פערים. רוב הכלים שנבנו על הרעיון הזה, הנמכרים כיום לעיתים קרובות כ-"תיעוד המתעדכן מעצמו", עוקבים אחר commits או pull requests ומעדכנים את תיעוד המפתחים לצד הקוד.

מרכזי עזרה המיועדים ללקוחות זקוקים לטריגר אחר. קוראים לא רואים commit; הם רואים שחרור גרסה. הטבלה מציגה את הפשרות.

הטיעון בעד אוטומציה הוא קצב העבודה. מחקר State of DevOps לשנת 2021 של DORA מצא ש-צוותים עילית פורסים פי 973 בתדירות גבוהה יותר מביצועים נמוכים. לא כל פריסה משנה את מה שהקוראים רואים, אבל צוותים משחררים הרבה יותר ממה שמישהו יכול לבדוק מחדש במאמרים באופן ידני. אותו מחקר מצא ש-צוותים עם תיעוד איכותי היו בעלי סבירות גבוהה פי 3.8 ליישם שיטות עבודה מומלצות לאבטחה, כך שהתיעוד אינו נושא צדדי. ותיעוד מיושן הוא נפוץ: בסקר הקוד הפתוח של GitHub משנת 2017, 93% מהמשיבים נתקלו בתיעוד חסר או מיושן, ו-60% מהתורמים אמרו שהם לעיתים רחוקות או לעולם לא תורמים לתיעוד.

שלב 1: כתבו הערות שחרור שמשימת תיעוד יכולה להשתמש בהן#

אוטומציה יכולה לעדכן תיעוד רק ברמה שבה הערות השחרור מתארות את השינוי. שתי מוסכמות עוזרות.

• קבצו שינויים לפי סוג. Keep a Changelog משתמש ב-Added, Changed, Deprecated, Removed, Fixed ו-Security. "Added" בדרך כלל אומר מאמר או סרטון חדש; "Changed" ו-"Removed" אומרים שהתוכן הקיים כעת שגוי.
• הפרידו בין מה שמשתמשים רואים לבין מה שלא. הערות השחרור שנוצרות אוטומטית של GitHub ממיינות pull requests ממוזגים לפי תווית ב-.github/release.yml, ויכולות להחריג תוויות לחלוטין.

# .github/release.yml
changelog:
  exclude:
    labels: [internal, chore]
  categories:
    - title: New
      labels: [feature]
    - title: Changed in the app
      labels: [ui-change]
    - title: Fixes
      labels: [bug]
    - title: Other changes
      labels: ["*"]

תווית "ui-change" היא התווית השימושית ביותר להוספה: היא אומרת למשימת התיעוד אילו פריטים יכולים לשבור מאמר. תנו שם למסך גם בכותרת ה-pull-request ("הגדרות חיוב: העברת תזכורות לאוטומציות"), כדי שניתן יהיה להתאים את השינוי לדפים שמציגים את המסך הזה.

שלב 2: עדכון אוטומטי של תיעוד בעת שחרור: התחלת משימה#

כל מארח Git מרכזי יכול להתחיל משימה כשאתם משחררים גרסה, וזו הדרך שבה אתם מייצרים עדכוני תיעוד משחרורי GitHub או המקבילות שלהם ב-GitLab וב-Bitbucket. הפרטים שונים.

ב-GitHub, workflow מינימלי נראה כך:

# .github/workflows/docs-on-release.yml
name: Docs on release
on:
  release:
    types: [published]
permissions:
  contents: read
jobs:
  draft-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - name: Draft docs updates for this release
        env:
          TAG: ${{ github.event.release.tag_name }}
          NOTES: ${{ github.event.release.body }}
        run: ./scripts/draft-docs-updates.sh

השתמשו ב-published במקום ב-created: לפי הפניית האירועים של GitHub, created לא מופעל עבור שחרורי טיוטה, בעוד ש-published מכסה גם שחרורים יציבים וגם שחרורים מוקדמים. העבירו את הערות השחרור דרך משתנה סביבה כפי שמוצג לעיל, לא ישירות לפקודת ה-shell, מכיוון שטקסט השחרור הוא קלט משתמש. ואם כלי כגון release-please או semantic-release יוצר את השחרורים שלכם עם הטוקן המוגדר כברירת מחדל, אירועים שהוא מפעיל לא יתחילו את ה-workflow של התיעוד שלכם; תנו לכלי הזה טוקן GitHub App או טוקן גישה אישי במקום זאת.

ב-GitLab וב-Bitbucket, המקבילה היא משימה שרצה על תגים:

# .gitlab-ci.yml
draft-docs:
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - ./scripts/draft-docs-updates.sh "$CI_COMMIT_TAG"

# bitbucket-pipelines.yml
pipelines:
  tags:
    'v*':
      - step:
          script:
            - ./scripts/draft-docs-updates.sh "$BITBUCKET_TAG"

שלב 3: מצאו את הדפים והסרטונים שכל שחרור משפיע עליהם#

זהו השלב שרוב המדריכים מדלגים עליו, והוא זה שמחליט אם האוטומציה עוזרת. הערת שחרור אומרת "תזכורות הועברו לחיוב ← אוטומציות"; המשימה שלכם צריכה להפוך את זה ל-"שלושת המאמרים ושני הסרטונים האלה שגויים כעת".

שלוש שיטות, מהפשוטה ביותר לחזקה ביותר:

1. חיפוש תוויות ששונו. חלצו כל מחרוזת ממשק במירכאות מהערות השחרור וחפשו את הניסוח הישן במאמרים ובתסריטי הסרטונים שלכם.
2. ניהול מלאי מסכים. תייגו כל מאמר וסרטון עם המסכים שהוא מציג, והתאימו את שמות המסכים בכותרות ה-pull-request מולו. למדריך שלנו ל-שמירה על תיעוד מעודכן יש תבנית מלאי.
3. תנו למודל לקרוא כל מועמד במלואו. תנו למודל שפה את הערות השחרור ואת הטקסט המלא (או התמלול) של כל דף מועמד, ובקשו פסק דין: עדיין נכון, דורש תיקון טקסט, או דורש צילומי מסך או קטעי וידאו חדשים. קריאת כל הדף חשובה, כי השלב השבור הוא לעיתים קרובות לא זה שהערת השחרור מציינת.

הנחיה (prompt) לפסק דין כזה יכולה להיות קצרה:

You check help articles against a software release.
Release notes: {release_notes}
Article ({url}): {article_text}

Answer in JSON: {"verdict": "still_right" | "text_fix" | "new_screenshots_or_footage",
"reason": "<one sentence quoting the release item>",
"changed_steps": [<step numbers>]}
Only use facts from the release notes. If unsure, answer "text_fix" and say why.

שלב 4: נסחו את העדכונים#

עבור טקסט, הטיוטה היא החלק הקל: המודל מקבל את הערות השחרור, המאמר הנוכחי וכללי הסגנון שלכם, ומחזיר גרסה מתוקנת. שמרו על המזהה (ID) והכתובת (URL) של המאמר, כדי שתעדכנו את הדף הקיים במקום ליצור כמעט-כפיל, ותעדו איזה שחרור שינה אותו לאחרונה. הכללים ב-איך לכתוב מאמרים למרכז עזרה מהווים הנחיית סגנון טובה.

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

שלב 5: שימו אדם בין הטיוטה לבין הקורא#

תיאורי pull-request נכתבים על ידי אנשים רבים ולעולם לא נסקרים מתוך מחשבה על לקוחות. התייחסו אליהם, ולהערות שחרור, כאל קלט לא מהימן: הם יכולים לשאת הוראות שהמודל יבצע. שלחו כל טיוטה לסקירה.

• מי מאשר: מוביל התמיכה או התיעוד עבור תוכן מרכז העזרה, מהנדס עבור תיעוד ה-API.
• מה סקירה טובה מראה: כל דף מושפע עם השוואת לפני-ואחרי, פריט השחרור שגרם לכך, ורשימת "אין מה לשנות" ברורה כדי שהסוקרים יסמכו על מה שדלגו עליו.
• מה לפרסם אוטומטית: שום דבר שפונה ללקוחות בהתחלה. ברגע שכמה שחרורים עברו ללא הפתעות, תוכלו להקל את הכלל עבור פריטים בסיכון נמוך כגון תיקוני טקסט ברמת שגיאות כתיב.

איזה הגדרה מתאימה לצוות שלכם?#

אם הצוות שלך כבר עובד ב-Claude Code, ניתן גם לבקש ממנו לעדכן את התיעוד לאחר שחרור גרסה דרך MCP; אנחנו מסבירים איך לעשות זאת ב-איך לעדכן תיעוד עם Claude Code אחרי כל שחרור גרסה.

איך לעדכן תיעוד אוטומטית בעת שחרור גרסה עם Clevera Autopilot#

Clevera היא פלטפורמת AI שהופכת הקלטת מסך לסרטון הדרכה עם קריינות, מאמר עזרה מפורט ודף במרכז העזרה המארח שלך, ב-74 שפות. תכונת ה-Autopilot שלה, הזמינה בתוכניות Pro ו-Custom, מבצעת את שלבים 2 עד 5 לעיל עבור מרכז עזרה של Clevera.

• טריגר. המתכון שמור על מרכז העזרה שלי מעודכן כשאנחנו משחררים גרסה עוקב אחר שחרורי גרסאות או שינויים ממוזגים של מאגר, או דף עדכונים שנקרא מדי יום או שבוע. GitHub מתחברת דרך אפליקציה לקריאה בלבד; GitLab (gitlab.com) ו-Bitbucket Cloud מתחברות באותה דרך היכן שזמין. Clevera בודקת את המאגר בערך פעם בשעה. היא קוראת הערות שחרור, תגיות וכותרות ותיאורים של pull-requests, לעולם לא את הקוד שלך.
• התאמה. כל הרצה בודקת עד 40 מהסרטונים והמאמרים במרכז העזרה וקוראת כל אחד מהם במלואו.
• ניסוח. כל פריט מקבל החלטה: עדיין תקין, תיקון טקסט שמוצג לפני ואחרי, או הקלטה מחדש עם השלבים החדשים. הקלטה מחדש דורשת את השתמש באפליקציה שלי: כתובת האפליקציה שלך, ואם היא דורשת זאת, כניסה למערכת (חשבון בדיקה עובד הכי טוב). הסרטון החדש מחליף את הישן באותו קישור, כך שכמו בעריכות LiveSync, הטמעות ודפי מרכז עזרה מציגים אותו ללא קישורים חדשים.
• סקירה. כל הרצה ממתינה לך. אתה מסיר סימון ממה שאינך רוצה ולוחץ על הרץ, או לוחץ על בקש שינויים עבור תוכנית חדשה. תוכנית פוקעת לאחר שבעה ימים, וההרצה הבאה אוספת את כל מה שקרה מאז.

מעקב ותכנון הם בחינם; כל שורה בתוכנית מציגה את הקרדיטים שלה, והרצה טיפוסית עולה 10 עד 150 קרדיטים. אותו לופ זמין לסרטונים ללא מרכז עזרה דרך עדכן את הסרטונים שלי כשהמוצר משתנה, ו-הקלט סרטון לכל תכונה חדשה מציע הדרכה חדשה למה שכל שחרור גרסה מוסיף (ראו איך להכין סרטון הערות שחרור לגרסה הידנית).

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

התחל בחינם כדי לבנות קודם את מרכז העזרה והסרטונים; Autopilot מגיע עם Pro. שלבי ההגדרה נמצאים במאמר העזרה חבר את GitHub או מאגר אחר ל-Autopilot.

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

האם תיעוד יכול להתעדכן אוטומטית כשאנחנו משחררים גרסה?#

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

האם התיעוד צריך להתעדכן בכל commit או בכל שחרור גרסה?#

עבור מרכזי עזרה, בכל שחרור גרסה. Commits ו-pull requests משתנים ללא הרף ולעיתים קרובות נמצאים מאחורי דגלי תכונות; שחרור גרסה הוא הרגע שבו הקוראים באמת רואים את השינוי. תיעוד מפתחים שחי לצד הקוד יכול לעקוב אחר pull requests.

איך אני מפעיל GitHub Action כשמתפרסם שחרור גרסה?#

השתמש ב-on: release עם types: [published]. אם השחרור נוצר על ידי תהליך עבודה אחר המשתמש ב-GITHUB_TOKEN המוגדר כברירת מחדל, הוא לא יפעיל את תהליך העבודה שלך; השתמש ב-GitHub App token או ב-personal access token עבור כלי השחרור.

מה אם אנחנו לא מפרסמים שחרורי גרסאות ב-GitHub?#

השתמש באות שיש לך: אירועי שחרור של GitLab, צינורות תיוג של Bitbucket, או משימה מתוזמנת שקוראת את דף העדכונים הציבורי שלך או את עדכון ה-RSS שלו. ה-Autopilot של Clevera יכול לעקוב אחר דף עדכונים מדי יום או שבוע בדיוק למקרה הזה.

האם ניתן לעדכן אוטומטית גם צילומי מסך וסרטונים?#

ניתן לצלם צילומי מסך בבדיקות UI בכל build. סרטונים צריכים הקלטה מחדש של התהליך שהשתנה; מקליט AI יכול להריץ מחדש הוראה שמורה מול ה-UI החדש, ו-Autopilot יכול לעשות זאת עבור סרטוני Clevera כאשר אתה נותן לו את כתובת האפליקציה שלך (וכניסה למערכת אם האפליקציה שלך דורשת זאת). צפה בהקלטה החדשה לפני אישורה.