Her sürümde belgeler nasıl otomatik güncellenir

3 Kasım 2026 tarihinde güncellendi

Belgeleri her sürümde otomatik güncellemek için, sürümün kendisinden bir dokümantasyon işi başlatın: yayınlanmış bir GitHub sürümü, bir GitLab sürüm etkinliği, bir Bitbucket etiketi veya genel sürüm notlarınızda yeni bir girdi. İş, sürüm notlarını okur, sürümün etkilediği yardım sayfalarını ve videoları bulur, değişiklikleri taslak haline getirir ve onaylaması için bir kişiye gönderir. Müşteriye yönelik belgeler için bu inceleme adımı, dokümantasyon otomasyonunu güvenli tutan şeydir.

Bu kılavuz, önce herhangi bir araçla (GitHub Actions, GitLab, Bitbucket, sürüm notları sayfası) bu hattın üzerinden geçer, ardından Clevera'nın Autopilot'unun videolar içeren bir yardım merkezi için aynı döngüyü nasıl çalıştırdığını gösterir.

Sürekli dokümantasyon nedir?#

Terimi popülerleştiren Swimm, sürekli dokümantasyonu, belgeleri ara sıra yapılan telafi projeleri yerine geliştirme iş akışının bir parçası olarak aşamalı bir şekilde oluşturmak ve güncellemek olarak tanımlar. Fikir üzerine inşa edilen çoğu araç, artık genellikle "kendi kendini güncelleyen dokümantasyon" olarak satılmakta olup, commit'leri veya pull request'leri izler ve geliştirici belgelerini kodun yanında günceller.

Müşteriye yönelik yardım merkezlerinin farklı bir tetikleyiciye ihtiyacı vardır. Okuyucular bir commit görmez; bir sürüm görürler. Tablo, ödünleşimleri göstermektedir.

Otomasyonun gerekçesi hızdır. DORA'nın 2021 DevOps Durumu araştırması, seçkin ekiplerin düşük performans gösterenlere göre 973 kat daha sık dağıtım yaptığını buldu. Her dağıtım okuyucuların gördüklerini değiştirmez, ancak ekipler kimsenin makaleleri elle tekrar kontrol edemeyeceğinden çok daha sık gönderim yapar. Aynı araştırma, yüksek kaliteli dokümantasyona sahip ekiplerin güvenlik en iyi uygulamalarını uygulama olasılığının 3,8 kat daha fazla olduğunu buldu, bu nedenle belgeler yan bir konu değildir. Ve güncel olmayan belgeler yaygındır: GitHub'ın 2017 Açık Kaynak Anketi'nde, katılımcıların %93'ü eksik veya güncel olmayan dokümantasyonla karşılaştığını ve katılımcıların %60'ı belgelere nadiren katkıda bulunduğunu veya hiç katkıda bulunmadığını söyledi.

1. Adım: Bir dokümantasyon işinin kullanabileceği sürüm notları yazın#

Otomasyon, belgeleri ancak sürüm notları değişikliği tanımladığı kadar iyi güncelleyebilir. İki kural yardımcı olur.

• Değişiklikleri türe göre gruplandırın. Keep a Changelog Eklendi, Değiştirildi, Kullanımdan Kaldırıldı, Kaldırıldı, Düzeltildi ve Güvenlik ifadelerini kullanır. "Eklendi" genellikle yeni bir makale veya video anlamına gelir; "Değiştirildi" ve "Kaldırıldı" ise mevcut içeriğin artık yanlış olduğu anlamına gelir.
• Kullanıcıların gördüklerini görmediklerinden ayırın. GitHub'ın otomatik olarak oluşturulan sürüm notları, birleştirilmiş pull request'leri .github/release.yml içindeki etiketlere göre sıralar ve etiketleri tamamen hariç tutabilir.

# .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" etiketi, eklenecek en yararlı etikettir: dokümantasyon işine hangi öğelerin bir makaleyi bozabileceğini söyler. Ekranı pull-request başlığında da adlandırın ("Faturalandırma ayarları: hatırlatıcıları Otomasyonlara taşı"), böylece değişiklik o ekranı gösteren sayfalarla eşleştirilebilir.

2. Adım: Sürümde belgeleri otomatik güncelleyin: bir iş başlatın#

Her büyük Git barındırıcısı, gönderim yaptığınızda bir iş başlatabilir; GitHub sürümlerinden veya bunların GitLab ve Bitbucket eşdeğerlerinden dokümantasyon güncellemelerini bu şekilde oluşturursunuz. Ayrıntılar farklılık gösterir.

GitHub'da, minimal bir iş akışı şuna benzer:

# .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

created yerine published kullanın: GitHub'ın etkinlik referansına göre, created taslak sürümler için tetiklenmezken, published hem kararlı sürümleri hem de ön sürümleri kapsar. Sürüm notlarını yukarıdaki gibi bir ortam değişkeni aracılığıyla geçirin, doğrudan kabuk komutuna değil, çünkü sürüm metni kullanıcı girdisidir. Ve release-please veya semantic-release gibi bir araç sürümlerinizi varsayılan belirteçle oluşturursa, tetiklediği etkinlikler dokümantasyon iş akışınızı başlatmaz; bunun yerine o araca bir GitHub Uygulaması belirteci veya kişisel erişim belirteci verin.

GitLab ve Bitbucket'ta eşdeğeri, etiketler üzerinde çalışan bir iştir:

# .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. Adım: Her sürümün etkilediği sayfaları ve videoları bulun#

Bu, çoğu kılavuzun atladığı ve otomasyonun yardımcı olup olmayacağına karar veren adımdır. Bir sürüm notu "Hatırlatıcılar Faturalandırma → Otomasyonlar'a taşındı" der; işinizin bunu "bu üç makale ve iki video artık yanlış" haline getirmesi gerekir.

En basitten en güçlüye üç yöntem:

1. Yeniden adlandırılan etiketleri arayın. Sürüm notlarındaki tüm tırnak içindeki kullanıcı arayüzü dizelerini çekin ve makalelerinizde ve video senaryolarınızda eski ifadeleri arayın.
2. Bir ekran envanteri tutun. Her makaleyi ve videoyu gösterdiği ekranlarla etiketleyin ve pull-request başlıklarındaki ekran adlarını bununla eşleştirin. Dokümantasyonu güncel tutma kılavuzumuz bir envanter şablonuna sahiptir.
3. Bir modelin her adayı bütünüyle okumasına izin verin. Bir dil modeline sürüm notlarını ve her aday sayfanın tam metnini (veya dökümünü) verin ve bir karar isteyin: hala doğru mu, metin düzeltmesi mi gerekiyor, yoksa yeni ekran görüntüleri veya görüntüler mi gerekiyor. Sayfanın tamamını okumak önemlidir, çünkü bozuk adım genellikle sürüm notunun adlandırdığı adım değildir.

Bu karar için bir istem kısa olabilir:

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. Adım: Güncellemeleri taslak haline getirin#

Metin için taslak kolay kısımdır: model sürüm notlarını, mevcut makaleyi ve stil kurallarınızı alır ve gözden geçirilmiş bir sürüm döndürür. Makalenin kimliğini ve URL'sini koruyun, böylece neredeyse kopya oluşturmak yerine mevcut sayfayı güncellersiniz ve en son hangi sürümün değiştirdiğini kaydedin. Yardım merkezi makalelerinin nasıl yazılacağına dair kurallar iyi bir stil istemi oluşturur.

Ekran görüntüleri ve videolar daha zordur. Bir model, görmediği bir ekranın ekran görüntüsünü üretemez. Ya kullanıcı arayüzü test paketinizde yeni görüntüler yakalarsınız, değiştirilen akışı yeniden kaydedersiniz ya da öğeyi bir kişinin yeniden kaydetmesi için işaretlersiniz. Plandaki her öğeyi işaretleyin: metin düzeltmesi, yeni ekran görüntüsü veya yeniden kaydetme. Değiştirilen akış kaydedildikten sonra, kaydı dokümantasyona dönüştürmek size tek seferde yeni adımlar ve ekran görüntüleri verir.

5. Adım: Taslak ile okuyucu arasına bir kişi koyun#

Pull-request açıklamaları birçok kişi tarafından yazılır ve asla müşteriler düşünülerek incelenmez. Onlara ve sürüm notlarına güvenilmeyen girdi olarak davranın: bir modelin izleyeceği talimatlar taşıyabilirler. Her taslağı incelemeye gönderin.

• Kim onaylar: yardım merkezi içeriği için destek veya dokümantasyon lideri, API referansı için bir mühendis.
• İyi bir inceleme neyi gösterir: öncesi ve sonrası farkı ile etkilenen her sayfa, buna neden olan sürüm öğesi ve gözden geçirenlerin atlananlara güvenmesi için net bir "değiştirilecek bir şey yok" listesi.
• Otomatik olarak ne yayınlanmalı: başlangıçta müşteriye yönelik hiçbir şey. Birkaç sürüm sürpriz olmadan geçtikten sonra, yazım hatası düzeyindeki metin düzeltmeleri gibi düşük riskli öğeler için kuralı gevşetebilirsiniz.

Hangi kurulum ekibinize uygun?#

Ekibiniz halihazırda Claude Code içinde çalışıyorsa, MCP üzerinden bir sürümden sonra dokümanları güncellemesini de isteyebilirsiniz; bunu her sürümden sonra Claude Code ile dokümanlar nasıl güncellenir rehberimizde adım adım açıklıyoruz.

Clevera Autopilot ile sürümde dokümantasyon nasıl otomatik güncellenir#

Clevera, bir ekran kaydını anlatımlı bir nasıl yapılır videosuna, adım adım bir yardım makalesine ve barındırılan yardım merkezinizdeki bir sayfaya 74 dilde dönüştüren bir AI platformudur. Pro ve Custom planlarında bulunan Autopilot özelliği, yukarıdaki 2'den 5'e kadar olan adımları bir Clevera yardım merkezi için çalıştırır.

• Tetikleyici. Sürüm yayınladığımızda yardım merkezimi güncel tut tarifi, bir deponun Sürümlerini veya Birleştirilmiş değişikliklerini ya da günlük veya haftalık okunan Değişiklik günlüğü sayfasını izler. GitHub, salt okunur bir uygulama aracılığıyla bağlanır; GitLab (gitlab.com) ve Bitbucket Cloud, mevcut oldukları yerlerde aynı şekilde bağlanır. Clevera depoyu yaklaşık saatte bir kontrol eder. Sürüm notlarını, etiketleri ve çekme isteği başlıkları ile açıklamalarını okur, kodunuzu asla okumaz.
• Eşleştirme. Her çalıştırma, yardım merkezindeki 40'a kadar videoyu ve makaleyi kontrol eder ve etkilenen her birini tamamen okur.
• Taslak Oluşturma. Her öğe bir karara varır: hala doğru, öncesi ve sonrası gösterilen bir metin düzeltmesi veya yeni adımlarla yeniden kaydet. Yeniden kaydetme işlemi Uygulamamı kullan gerektirir: uygulamanızın adresi ve gerekiyorsa bir oturum açma bilgisi (bir test hesabı en iyi sonucu verir). Yeni video, eskisinin yerini aynı bağlantıda alır, böylece LiveSync düzenlemelerinde olduğu gibi, gömülü içerikler ve yardım merkezi sayfaları yeni bağlantılara gerek kalmadan bunu gösterir.
• İnceleme. Her çalıştırma sizi bekler. İstemediklerinizi işaretleyip Çalıştır'a tıklayabilir veya yeni bir plan için Değişiklik iste'ye tıklayabilirsiniz. Bir plan yedi gün sonra sona erer ve bir sonraki çalıştırma o zamandan beri olan her şeyi alır.

İzleme ve planlama ücretsizdir; bir planın her satırı kredilerini gösterir ve tipik bir çalıştırma 10 ila 150 kredi tutar. Aynı döngü, yardım merkezi olmayan videolar için Ürün değiştiğinde videolarımı güncelle aracılığıyla kullanılabilir ve Her yeni özellik için bir video kaydet, her sürümün eklediği özellikler için yeni bir nasıl yapılır videosu önerir (manuel sürüm için sürüm notları videosu nasıl yapılır kısmına bakın).

Clevera'nın doğru araç olmadığı durumlar: koddan API referansı oluşturmaz veya CHANGELOG.md yazmaz. Bu taraf için AI değişiklik günlüğü oluşturucuları karşılaştırmamıza veya başka bir platformda bir AI ajanının dokümanları düzenlemesini istiyorsanız dokümantasyon için MCP sunucuları kısmına bakın.

Önce yardım merkezini ve videoları oluşturmak için ücretsiz başlayın; Autopilot Pro planıyla birlikte gelir. Kurulum adımları Autopilot'a GitHub veya başka bir depo bağlama yardım makalesindedir.

SSS#

Dokümantasyon sürüm yayınladığımızda otomatik olarak güncellenebilir mi?#

Algılama ve taslak oluşturma otomatik olabilir: bir sürüm, etkilenen sayfaları bulan ve düzeltmeleri taslak haline getiren bir işi başlatır. Müşteriye yönelik dokümanlar için yayınlama kararı insanda kalmalıdır, çünkü sürüm notları her zaman okuyuculardan ne yapmalarını istediğinizi tam olarak yansıtmayabilir.

Dokümanlar her commit'te mi yoksa her sürümde mi güncellenmeli?#

Yardım merkezleri için her sürümde. Commit'ler ve çekme istekleri sürekli değişir ve genellikle özellik bayraklarının arkasında kalır; sürüm, okuyucuların değişikliği gerçekten gördüğü zamandır. Kodun yanında yaşayan geliştirici dokümanları çekme isteklerini takip edebilir.

Bir sürüm yayınlandığında GitHub Action'ı nasıl tetiklerim?#

on: release ile types: [published] kullanın. Sürüm, varsayılan GITHUB_TOKEN kullanılarak başka bir iş akışı tarafından oluşturulursa, iş akışınızı başlatmaz; sürüm aracı için bir GitHub Uygulaması belirteci veya kişisel erişim belirteci kullanın.

GitHub'da sürüm yayınlamıyorsak ne olur?#

Elinizdeki sinyali kullanın: GitLab sürüm etkinlikleri, Bitbucket etiket işlem hatları veya herkese açık değişiklik günlüğü sayfanızı ya da RSS beslemesini okuyan zamanlanmış bir iş. Clevera'nın Autopilot'ı tam olarak bu durum için bir değişiklik günlüğü sayfasını günlük veya haftalık olarak izleyebilir.

Ekran görüntüleri ve videolar da otomatik olarak güncellenebilir mi?#

Ekran görüntüleri her derlemede UI testlerinde yakalanabilir. Videoların değişen akışının yeniden kaydedilmesi gerekir; bir AI kaydedici, kaydedilmiş bir talimatı yeni UI üzerinde yeniden çalıştırabilir ve Autopilot, uygulamanızın adresini (ve gerekiyorsa oturum açma bilgilerini) verdiğinizde Clevera videoları için bunu yapabilir. Onaylamadan önce yeni çekimi izleyin.