コンテンツにスキップ

変更履歴

目的

変更履歴の目的は、注目すべき変更を記録またはログに記録することです。

トーン

指示的、率直

content_type

changelog

所有権

開発者やエンジニアは、手動またはチームが所有する自動化プロセスを通じて変更履歴を維持します。PCXはレビューを提供しますが、変更履歴の作成や執筆を所有すべきではありません。

ページの構造は、頻度やページの種類によって異なる場合があります。

構造(単一ページ)

変更履歴を作成する際には、Markdownページファイルと対応するYAMLファイルが必要です。これらはsrc/content/changelogsフォルダーにあります。

これらのファイルの組み合わせにより、次のことが可能になります:

Markdownファイル

Markdownファイルには、変更履歴情報を引き出すためのいくつかの特別な値が必要です。これらの値はサンプルページで強調表示されています。

src/content/queues/platform/changelog.mdx
---
pcx_content_type: changelog
title: 変更履歴
changelog_file_name:
- queues
sidebar:
order: 4
---
import { ProductChangelog } from "~/components"
{/* <!-- 実際のコンテンツは/data/changelogs/queues.yamlにあります。新しいエントリをここに表示させるには、そこにファイルを更新してください。詳細については、https://developers.cloudflare.com/style-guide/documentation-content-strategy/content-types/changelog/#yaml-fileを参照してください。 --> */}
<ProductChangelog />

YAMLファイル

product-changelogコンポーネントは、/data/changelogsフォルダー内のファイルに存在するデータをレンダリングします。

  • link 文字列 必須

    • 変更履歴ページへの相対パス、例: "/queues/changelog/"
  • productName 文字列 必須

    • 変更履歴の製品フィルターリストやテンプレートの他の領域に表示する製品名。
  • productLink 文字列 必須

    • 製品のトップレベルドキュメントへのリンク(トップレベルの変更履歴ページにアクセスする場合に便利)。
  • productArea 文字列 必須

    • 関連する製品を文脈の中でまとめて表示するためのロールアップグループ。
  • productAreaLink 文字列 必須

    • 関連する製品を文脈の中でまとめて表示するためのロールアップグループ。関連するRSSフィードをまとめるのに役立ちます。
  • entries オブジェクト 必須

    • publish_date 日付 必須

      • 公開された変更の日付、YYYY-MM-DD形式で。
    • title 文字列 任意

      • 公開された変更の名前。任意ですが、強く推奨されます。
    • description 文字列 必須

      • YAMLの規則に従ったMarkdown文字列。複数行の文字列の場合、エントリを|-で始め、インデントされた新しい行に入力します。
/data/changelogs/queues.yaml
---
link: "/queues/changelog/"
productName: キュー
productLink: "/queues/"
productArea: 開発者プラットフォーム
productAreaLink: /workers/platform/changelog/platform/
entries:
- publish_date: '2023-03-28'
title: コンシューマー同時実行(有効)
description: キューのコンシューマーは、キューに書き込まれるメッセージの数に基づいて[自動的にスケールアップ](/queues/learning/consumer-concurrency/)します。 同時実行を制御または制限するには、コンシューマーのために明示的に[`max_concurrency`](/queues/platform/configuration/#consumer)を定義できます。
- publish_date: '2023-03-15'
title: コンシューマー同時実行(今後)
description: |-
キューのコンシューマーは、キューのバックログが増えるにつれて自動的に同時実行をスケールアップし、全体のメッセージ処理のレイテンシを低下させます。同時実行は、2023-03-28までにすべての既存のキューで有効になります。
**オプトアウトするか、固定の最大同時実行を設定するには、`wrangler.toml`ファイルで`max_concurrency = 1`を設定するか、[キューダッシュボード](https://dash.cloudflare.com/?to=/:account/queues)を介して設定してください。**
**オプトインするには、何も行う必要はありません**: コンシューマーは、メッセージのバックログに追いつくために必要に応じてスケールアウトを開始します。バックログが縮小するにつれて、またはコンシューマーがエラーの高いレートを生成し始めると、スケールバックダウンします。コンシューマーのスケール方法について詳しくは、[コンシューマー同時実行](/queues/learning/consumer-concurrency/)のドキュメントを参照してください。
- publish_date: '2023-03-02'
title: 明示的確認(新機能)
description: |-
メッセージに対してバッチで[個別に確認](/queues/learning/batching-retries/#explicit-acknowledgement)を行うことができるようになりました。
これにより、バッチ内で処理する際にメッセージを配信済みとしてマークでき、コンシューマーがバッチ処理中にエラーをスローした場合に、バッチ全体が再配信されるのを回避できます。これは、外部APIを呼び出したり、データベースにメッセージを書き込んだり、バッチ内の個々のメッセージに対して非冪等のアクションを実行したりする場合に特に便利です。
- publish_date: '2023-03-01'
title: キューごとのスループット向上
description: キューごとのスループット制限が[1秒あたり400メッセージに引き上げられました](/queues/platform/limits/)。
- publish_date: '2022-12-12'
title: アカウントごとの制限の増加
description: キューは、開発者がアカウントごとに最大100のキューを作成できるようになりました。これは、初期のベータ制限であるアカウントごと10からの増加です。この制限は今後も増加し続けます。
- publish_date: '2022-12-13'
title: sendBatchサポート
description: キューのプロデューサー向けのJavaScript APIには、最大100メッセージを一度に送信できる`sendBatch`メソッドが含まれています。

構造(複数ページ)

場合によっては、変更履歴に各エントリのための別のページがあることがあります。一般的な構造は単一ページの変更履歴と同じですが、いくつかの小さな違いがあります。

Markdownファイル

トップレベルページ

トップレベルページには、単一ページの例と同じフロントマターが必要ですが、ページの本文にはショートコードを含めないでください。

個別エントリ

各エントリページには、通常のMarkdownページを作成します。これには、別のスタイルのページや調整は必要ありません。

YAMLファイル

各個別エントリには、変更履歴の.yamlファイルに省略されたエントリが必要です。

/data/changelogs/waf.yaml
---
link: "/waf/change-log/"
productName: WAF
productLink: "/waf/"
productArea: アプリケーションセキュリティ
productAreaLink: /fundamentals/reference/changelog/security/
entries:
- publish_date: '2023-09-18'
scheduled_date: '2023-09-25'
individual_page: true
scheduled: true
link: '/waf/change-log/scheduled-changes/'
- publish_date: '2023-09-18'
individual_page: true
link: '/waf/change-log/2023-09-18/'
...
  • publish_date 日付 必須

    • ページが公開された日付、YYYY-MM-DD形式で。スケジュールされた変更があるページの場合、エントリを追加/更新する際にこのフィールドを更新する必要があります。これにより、変更履歴アイテムが変更履歴リスト(およびフィード)の先頭に配置されます。リリースによるすべてのスケジュールされた変更をクリアする際には、この日付を更新しないでください。この変更はそれほど重要ではありません。
  • individual_page ブール値 必須

    • ページ自体からコンテンツを引き出すために使用されます。YAMLの構造化データではなく。
  • link 文字列 必須

    • 個別ページへのリンク。
  • scheduled ブール値 任意

    • スケジュールされたページに含める必要があります。このコンポーネントは、基盤となるページにコンテンツをレンダリングするため、a) スケジュールされたエントリページごとに1つのスケジュールされたエントリのみを持ち、b) スケジュールされたエントリページにコンテンツがある場合にのみスケジュールされたエントリを持つ必要があります。
  • scheduled_date 日付 必須

    • スケジュールされた変更があるページに含める必要があります。タイトルに今後の変更の日付を表示するのに役立ち、タイトルや関連するRSSフィードをスキャンする人々にとってより実用的な情報を提供します。