変更管理

このガイドでは、カスタマーサポートオペレーションがシステムへの変更をどのように管理・デプロイするかを説明します。私たちは、変更を分類するために、変更対象に基づいた 4 種類のデプロイメントを使用しており、これによって変更がいつ、どのようにデプロイされるかが決まります。

デプロイメントの種類

アドホックデプロイメント

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

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

標準デプロイメント

私たちにとっての標準デプロイメントは、毎月 1 日に行われます。GitLab マイルストーンはこれを中心に組まれています。これらの項目には スケジュールパイプライン を活用しているので、すべて自動化されています。標準デプロイメントに従うリポジトリ内の変更は、デプロイメント日にこれらを通じてシステムに同期されます。

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

例外デプロイメント

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

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

1. リクエスト元が例外デプロイメントを依頼する
2. カスタマーサポートオペレーションのリーダーシップが、例外デプロイメントの影響を詳しく説明するコメントを行う。
   • これは、トピックに関係するさまざまな領域でマージされ「デプロイ待ち」になっているものをレビューすることで行います。
3. カスタマーサポートオペレーションのリーダーシップは、リクエストと影響をレビューして、リクエストの実現可能性と受け入れについての判断を下します。リクエスト元に対して、結果や影響などを提示します。
4. リクエスト元がカスタマーサポートオペレーションのリーダーシップの説明に同意する場合、引き続き進めることを確認します。
5. その後、カスタマーサポートオペレーションが例外デプロイメントを実施します。
   • 実施の正確な方法はさまざまなので、対象項目の固有のドキュメントを参照してください。

特殊デプロイメント

これは、標準・例外・アドホックデプロイメントの範囲外にある、非常に特殊なデプロイメント方法を必要とする領域の分類です。別の言い方をすると、「特殊デプロイメント」はここに定義されていないあらゆるものを受け止めるためのキャッチオールです。詳細については、項目自体のドキュメントページを参照してください。

特殊デプロイメントの例としては、Workato の変更があります。

ページのソースコードを見る - ページの編集 - please contribute.