変更履歴
変更履歴の目的は、注目すべき変更を記録またはログに記録することです。
指示的、率直
changelog
開発者やエンジニアは、手動またはチームが所有する自動化プロセスを通じて変更履歴を維持します。PCXはレビューを提供しますが、変更履歴の作成や執筆を所有すべきではありません。
ページの構造は、頻度やページの種類によって異なる場合があります。
変更履歴を作成する際には、Markdownページファイルと対応するYAMLファイルが必要です。これらはsrc/content/changelogsフォルダー ↗にあります。
これらのファイルの組み合わせにより、次のことが可能になります:
- 伝統的な変更履歴コンテンツをHTMLページにレンダリングする。
- 変更履歴コンテンツを使用してRSSフィードをプログラム的に作成する。
- すべての変更履歴コンテンツをCloudflare全体の変更履歴に引き出す。
Markdownファイルには、変更履歴情報を引き出すためのいくつかの特別な値が必要です。これらの値はサンプルページで強調表示されています。
---pcx_content_type: changelogtitle: 変更履歴changelog_file_name: - queuessidebar: 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 />product-changelogコンポーネントは、/data/changelogsフォルダー ↗内のファイルに存在するデータをレンダリングします。
-
link文字列 必須- 変更履歴ページへの相対パス、例:
"/queues/changelog/"。
- 変更履歴ページへの相対パス、例:
-
productName文字列 必須- 変更履歴の製品フィルターリストやテンプレートの他の領域に表示する製品名。
-
productLink文字列 必須- 製品のトップレベルドキュメントへのリンク(トップレベルの変更履歴ページにアクセスする場合に便利)。
-
productArea文字列 必須- 関連する製品を文脈の中でまとめて表示するためのロールアップグループ。
-
productAreaLink文字列 必須- 関連する製品を文脈の中でまとめて表示するためのロールアップグループ。関連するRSSフィードをまとめるのに役立ちます。
-
entriesオブジェクト 必須-
publish_date日付 必須- 公開された変更の日付、
YYYY-MM-DD形式で。
- 公開された変更の日付、
-
title文字列 任意- 公開された変更の名前。任意ですが、強く推奨されます。
-
description文字列 必須- YAMLの規則に従ったMarkdown文字列。複数行の文字列の場合、エントリを
|-で始め、インデントされた新しい行に入力します。
- YAMLの規則に従ったMarkdown文字列。複数行の文字列の場合、エントリを
-
---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ページを作成します。これには、別のスタイルのページや調整は必要ありません。
各個別エントリには、変更履歴の.yamlファイルに省略されたエントリが必要です。
---link: "/waf/change-log/"productName: WAFproductLink: "/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フィードをスキャンする人々にとってより実用的な情報を提供します。