Content last updated 2026-07-14

変更管理

変更管理に関するドキュメント

このガイドでは、Customer Support Systems がシステムへの変更を管理・デプロイする方法を説明します。変更する項目に基づいて変更を分類するために 4 種類のデプロイタイプを使用しており、これにより変更をいつ、どのようにデプロイするかが決まります。

デプロイの種類

一部の項目については、特定の日付にデプロイする意味がほとんどありません。これらの項目は、リポジトリ（またはシステム自体）に変更が加えられたときにデプロイされます。

アドホックデプロイの例として、Zendesk のマクロ変更があります。

私たちの標準デプロイは、毎月 1 日に実施します。GitLab マイルストーンはこれを中心に設定します。これらの項目にはスケジュールされたパイプラインを使用するため、すべて自動化されます。標準デプロイに続くリポジトリの変更はすべて、デプロイ日にこれらを通じてシステムに同期されます。

標準デプロイの例として、Zendesk のトリガー変更があります。

通常は標準デプロイを使用する項目について、本来該当するデプロイ日よりも前に実施する必要がある状況があります。

このような状況が発生した場合、一般的なプロセスは次のように進めます。

リクエスト者が例外デプロイを依頼する
Customer Support Systems のリーダーシップが、例外デプロイによる影響を詳述するコメントを作成します。
- これは、対象のトピックが含むさまざまな領域で、マージ済みかつ「デプロイ待ち」のものをレビューして行います。
Customer Support Systems のリーダーシップは、リクエストと影響をレビューして、リクエストの実現可能性と受諾可否を決定します。結果、影響などをリクエスト者に提示します。
リクエスト者が Customer Support Systems のリーダーシップの説明に同意した場合、引き続き進めることを確認します。
Customer Support Systems が例外デプロイを実行します。
- 正確な方法は異なる場合があるため、対象の項目に関する個別のドキュメントを参照してください。

これは、標準、例外、アドホックデプロイの範囲外にあり、非常に固有のデプロイ方法を必要とする領域の分類です。別の表現をすると、「特別デプロイ」はここで定義されていないあらゆるものを包括する分類です。詳細については、項目自体のドキュメントページを参照してください。

特別デプロイの例として、Workato の変更があります。