Cara memperbarui dokumentasi secara otomatis pada setiap rilis

Diperbarui 3 November 2026

Untuk memperbarui dokumentasi secara otomatis pada setiap rilis, mulailah tugas dokumentasi dari rilis itu sendiri: rilis GitHub yang dipublikasikan, peristiwa rilis GitLab, tag Bitbucket, atau entri baru di changelog publik Anda. Tugas ini membaca catatan rilis, menemukan halaman bantuan dan video yang terdampak oleh rilis tersebut, membuat draf perubahan, dan mengirimkannya kepada seseorang untuk disetujui. Untuk dokumentasi yang ditujukan bagi pelanggan, langkah peninjauan inilah yang menjaga keamanan otomatisasi dokumentasi.

Panduan ini membahas alur kerja tersebut dengan alat apa pun terlebih dahulu (GitHub Actions, GitLab, Bitbucket, halaman changelog), kemudian menunjukkan bagaimana Autopilot Clevera menjalankan siklus yang sama untuk pusat bantuan dengan video.

Apa itu dokumentasi berkelanjutan?#

Swimm, yang mempopulerkan istilah ini, mendefinisikan dokumentasi berkelanjutan sebagai pembuatan dan pembaruan dokumentasi secara bertahap sebagai bagian dari alur kerja pengembangan, alih-alih dalam proyek pengejaran yang sesekali dilakukan. Sebagian besar alat yang dibangun berdasarkan ide ini, yang kini sering dijual sebagai "dokumentasi yang memperbarui diri sendiri", memantau commit atau pull request dan memperbarui dokumentasi pengembang di samping kode.

Pusat bantuan yang ditujukan bagi pelanggan memerlukan pemicu yang berbeda. Pembaca tidak melihat commit; mereka melihat rilis. Tabel ini menunjukkan pertimbangannya.

Alasan untuk otomatisasi adalah kecepatan. Riset State of DevOps 2021 dari DORA menemukan tim elit melakukan deployment 973 kali lebih sering daripada tim berkinerja rendah. Tidak setiap deployment mengubah apa yang dilihat pembaca, tetapi tim merilis jauh lebih sering daripada siapa pun yang dapat memeriksa ulang artikel secara manual. Riset yang sama menemukan tim dengan dokumentasi berkualitas tinggi 3,8 kali lebih mungkin menerapkan praktik terbaik keamanan, jadi dokumentasi bukanlah masalah sampingan. Dan dokumentasi yang kedaluwarsa adalah hal yang umum: dalam Survei Open Source GitHub 2017, 93% responden pernah menemukan dokumentasi yang tidak lengkap atau kedaluwarsa, dan 60% kontributor mengatakan mereka jarang atau tidak pernah berkontribusi pada dokumentasi.

Langkah 1: Tulis catatan rilis yang dapat digunakan oleh tugas dokumentasi#

Otomatisasi hanya dapat memperbarui dokumentasi sebaik catatan rilis yang menjelaskan perubahan tersebut. Dua konvensi dapat membantu.

• Kelompokkan perubahan berdasarkan jenis. Keep a Changelog menggunakan Added, Changed, Deprecated, Removed, Fixed, dan Security. "Added" biasanya berarti artikel atau video baru; "Changed" dan "Removed" berarti konten yang ada sekarang sudah salah.
• Pisahkan apa yang dilihat pengguna dari apa yang tidak mereka lihat. Catatan rilis yang dibuat secara otomatis oleh GitHub mengurutkan pull request yang digabungkan berdasarkan label di .github/release.yml, dan dapat mengecualikan label sepenuhnya.

# .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: ["*"]

Label "ui-change" adalah label yang paling berguna untuk ditambahkan: label ini memberi tahu tugas dokumentasi item mana yang dapat merusak artikel. Beri nama layar di judul pull-request juga ("Pengaturan penagihan: pindahkan pengingat ke Otomatisasi"), sehingga perubahan dapat dicocokkan dengan halaman yang menampilkan layar tersebut.

Langkah 2: Perbarui dokumentasi secara otomatis saat rilis: mulai tugas#

Setiap host Git utama dapat memulai tugas saat Anda melakukan pengiriman, yang merupakan cara Anda menghasilkan pembaruan dokumentasi dari rilis GitHub atau padanannya di GitLab dan Bitbucket. Detailnya berbeda.

Di GitHub, alur kerja minimal terlihat seperti ini:

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

Gunakan published daripada created: menurut referensi peristiwa GitHub, created tidak aktif untuk draf rilis, sedangkan published mencakup rilis stabil dan pra-rilis. Teruskan catatan rilis melalui variabel lingkungan seperti di atas, bukan langsung ke perintah shell, karena teks rilis adalah input pengguna. Dan jika alat seperti release-please atau semantic-release membuat rilis Anda dengan token default, peristiwa yang dipicunya tidak akan memulai alur kerja dokumentasi Anda; berikan alat tersebut token GitHub App atau token akses pribadi sebagai gantinya.

Di GitLab dan Bitbucket, padanannya adalah tugas yang berjalan pada tag:

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

Langkah 3: Temukan halaman dan video yang terdampak oleh setiap rilis#

Ini adalah langkah yang dilewati oleh sebagian besar panduan, dan langkah yang menentukan apakah otomatisasi membantu. Catatan rilis mengatakan "Pengingat dipindahkan ke Penagihan → Otomatisasi"; tugas Anda harus mengubahnya menjadi "tiga artikel dan dua video ini sekarang salah".

Tiga metode, dari yang paling sederhana hingga yang paling kuat:

1. Cari label yang diganti namanya. Tarik setiap string UI yang dikutip dari catatan rilis dan cari kata-kata lama di artikel dan skrip video Anda.
2. Simpan inventaris layar. Tandai setiap artikel dan video dengan layar yang ditampilkannya, dan cocokkan nama layar di judul pull-request dengannya. Panduan kami tentang menjaga dokumentasi tetap mutakhir memiliki templat inventaris.
3. Biarkan model membaca setiap kandidat secara lengkap. Berikan catatan rilis dan teks lengkap (atau transkrip) dari setiap halaman kandidat kepada model bahasa, dan minta penilaian: masih benar, perlu perbaikan teks, atau perlu tangkapan layar atau rekaman baru. Membaca seluruh halaman itu penting, karena langkah yang rusak sering kali bukan langkah yang disebutkan dalam catatan rilis.

Perintah untuk penilaian tersebut bisa singkat:

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.

Langkah 4: Buat draf pembaruan#

Untuk teks, draf adalah bagian yang mudah: model mendapatkan catatan rilis, artikel saat ini, dan aturan gaya Anda, lalu mengembalikan versi yang direvisi. Simpan ID dan URL artikel, sehingga Anda memperbarui halaman yang ada alih-alih membuat duplikat yang hampir sama, dan catat rilis mana yang terakhir mengubahnya. Aturan dalam cara menulis artikel pusat bantuan membuat perintah gaya yang bagus.

Tangkapan layar dan video lebih sulit. Model tidak dapat menghasilkan tangkapan layar dari layar yang belum pernah dilihatnya. Anda dapat mengambil gambar baru di rangkaian pengujian UI Anda, merekam ulang alur yang diubah, atau menandai item agar seseorang merekam ulang. Tandai setiap item dalam rencana: perbaikan teks, tangkapan layar baru, atau rekam ulang. Setelah alur yang diubah direkam, mengubah rekaman menjadi dokumentasi memberi Anda langkah-langkah dan tangkapan layar baru dalam satu kali proses.

Langkah 5: Tempatkan seseorang di antara draf dan pembaca#

Deskripsi pull-request ditulis oleh banyak orang dan tidak pernah ditinjau dengan mempertimbangkan pelanggan. Perlakukan deskripsi tersebut, dan catatan rilis, sebagai input yang tidak tepercaya: deskripsi tersebut dapat membawa instruksi yang akan diikuti oleh model. Kirim setiap draf untuk ditinjau.

• Siapa yang menyetujui: pimpinan dukungan atau dokumentasi untuk konten pusat bantuan, seorang insinyur untuk referensi API.
• Apa yang ditunjukkan oleh tinjauan yang baik: setiap halaman yang terdampak dengan perbedaan sebelum dan sesudah, item rilis yang menyebabkannya, dan daftar "tidak ada yang perlu diubah" yang jelas agar peninjau memercayai apa yang dilewati.
• Apa yang harus dipublikasikan secara otomatis: tidak ada yang ditujukan untuk pelanggan pada awalnya. Setelah beberapa rilis berjalan tanpa kejutan, Anda dapat melonggarkan aturan untuk item berisiko rendah seperti perbaikan teks tingkat kesalahan ketik.

Pengaturan mana yang cocok untuk tim Anda?#

Jika tim Anda sudah bekerja di Claude Code, Anda juga dapat memintanya untuk memperbarui dokumentasi setelah rilis melalui MCP; kami membahasnya di cara memperbarui dokumentasi dengan Claude Code setelah setiap rilis.

Cara memperbarui dokumentasi secara otomatis saat rilis dengan Clevera Autopilot#

Clevera adalah platform AI yang mengubah rekaman layar menjadi video panduan bernarasi, artikel bantuan langkah demi langkah, dan halaman di pusat bantuan yang Anda hosting, dalam 74 bahasa. Fitur Autopilot-nya, pada paket Pro dan Custom, menjalankan langkah 2 hingga 5 di atas untuk pusat bantuan Clevera.

• Pemicu. Resep Jaga pusat bantuan saya tetap terkini saat kami merilis memantau Rilis atau Perubahan yang digabungkan di repositori, atau Halaman changelog yang dibaca setiap hari atau minggu. GitHub terhubung melalui aplikasi read-only; GitLab (gitlab.com) dan Bitbucket Cloud terhubung dengan cara yang sama jika tersedia. Clevera memeriksa repositori sekitar satu jam sekali. Ia membaca catatan rilis, tag, serta judul dan deskripsi pull-request, tidak pernah kode Anda.
• Pencocokan. Setiap proses memeriksa hingga 40 video dan artikel pusat bantuan serta membaca setiap bagian yang terdampak secara penuh.
• Penyusunan Draf. Setiap item mendapatkan keputusan: masih benar, perbaikan teks yang ditampilkan sebelum dan sesudah, atau rekam ulang dengan langkah-langkah baru. Perekaman ulang memerlukan Gunakan aplikasi saya: alamat aplikasi Anda dan, jika diperlukan, login (akun uji coba berfungsi paling baik). Video baru menggantikan yang lama di tautan yang sama, jadi, seperti halnya pengeditan LiveSync, sematan dan halaman pusat bantuan menampilkannya tanpa tautan baru.
• Tinjauan. Setiap proses menunggu Anda. Anda menghapus centang pada apa yang tidak Anda inginkan dan klik Jalankan, atau klik Minta perubahan untuk rencana baru. Rencana kedaluwarsa setelah tujuh hari, dan proses berikutnya akan mengambil semua yang terjadi sejak saat itu.

Memantau dan merencanakan bersifat gratis; setiap baris rencana menunjukkan kreditnya, dan proses umum memakan biaya 10 hingga 150 kredit. Loop yang sama tersedia untuk video tanpa pusat bantuan melalui Perbarui video saya saat produk berubah, dan Rekam video untuk setiap fitur baru mengusulkan panduan baru untuk apa yang ditambahkan setiap rilis (lihat cara membuat video catatan rilis untuk versi manual).

Di mana Clevera bukan alat yang tepat: ia tidak menghasilkan referensi API dari kode atau menulis CHANGELOG.md Anda. Untuk bagian itu, lihat perbandingan kami tentang generator changelog AI, atau server MCP untuk dokumentasi jika Anda ingin agen AI mengedit dokumentasi di platform lain.

Mulai gratis untuk membangun pusat bantuan dan video terlebih dahulu; Autopilot disertakan dengan Pro. Langkah-langkah penyiapan ada di artikel bantuan Hubungkan GitHub atau repositori lain ke Autopilot.

FAQ#

Bisakah dokumentasi memperbarui dirinya sendiri secara otomatis saat kami merilis?#

Deteksi dan penyusunan draf bisa otomatis: rilis memulai pekerjaan yang menemukan halaman yang terdampak dan menyusun draf perbaikannya. Penerbitan harus tetap menjadi keputusan manusia untuk dokumentasi yang menghadap pelanggan, karena catatan rilis tidak selalu menyatakan apa yang Anda maksudkan untuk dilakukan pembaca.

Haruskah dokumentasi diperbarui pada setiap commit atau setiap rilis?#

Untuk pusat bantuan, setiap rilis. Commit dan pull request berubah terus-menerus dan sering kali berada di balik fitur flag; rilis adalah saat pembaca benar-benar melihat perubahannya. Dokumentasi pengembang yang berada di samping kode dapat mengikuti pull request.

Bagaimana cara memicu GitHub Action saat rilis diterbitkan?#

Gunakan on: release dengan types: [published]. Jika rilis dibuat oleh alur kerja lain menggunakan GITHUB_TOKEN default, itu tidak akan memulai alur kerja Anda; gunakan token GitHub App atau token akses pribadi untuk alat rilis.

Bagaimana jika kami tidak menerbitkan rilis di GitHub?#

Gunakan sinyal yang Anda miliki: peristiwa rilis GitLab, pipeline tag Bitbucket, atau pekerjaan terjadwal yang membaca halaman changelog publik Anda atau feed RSS-nya. Autopilot Clevera dapat memantau halaman changelog setiap hari atau minggu untuk kasus ini.

Bisakah tangkapan layar dan video diperbarui secara otomatis juga?#

Tangkapan layar dapat diambil dalam pengujian UI pada setiap build. Video memerlukan alur yang diubah untuk direkam ulang; perekam AI dapat menjalankan kembali instruksi yang disimpan terhadap UI baru, dan Autopilot dapat melakukan ini untuk video Clevera saat Anda memberikan alamat aplikasi Anda (dan login jika aplikasi Anda memerlukannya). Tonton hasil rekaman baru sebelum menyetujuinya.