Salesforceリリーストレイン：リリース管理への実用的なアプローチ
公開: 2022-03-11リリース管理は、その名前が示すように、さまざまな段階と環境でソフトウェアビルドを管理、計画、スケジューリング、および制御するプロセスです。 ソフトウェアリリースのテストと展開を含みます（Humble＆Farley、2011）。
それ自体はかなり大きなトピックであり、開発チームでさまざまなイテレーションを試し、ビジネスニーズや機能リリースを一致させることによってのみ、時間をかけて完成させることができます。 組織のリリーストレインを管理するためのメタデータ管理、CI構築、およびサンドボックス管理の業界慣行について説明します。
しかし、リリーストレインとは何ですか？
リリーストレインは、段階的で予測可能な機能提供手法です。 開発者は、開発環境で行われた変更を取得して本番環境にデプロイするための正式なプロセスを設定する必要があります。
リリーストレインは、大きく3つのセグメントに分けることができます。
- メタデータ管理
- 継続的インテグレーションビルド
- サンドボックス管理
メタデータ管理
メタデータは、他のデータに関する情報を提供するデータです。 Salesforceは、メタデータAPIを介してリッチで強力なメタデータモデルを提供します。 アプリケーションメタデータは、組織のソースコードと構成へのプログラムによるアクセスを提供する一連のメソッドを記述および包含します。
メタデータAPIは、Salesforceでカスタマイズを管理するための最良の方法です。 create 、 read 、 update 、およびdeleteメソッドをサポートします。 変更セット、Force.com IDE、およびAnt Migration Toolを使用して、ある組織から別の組織にメタデータを移行できます。これらはすべてAPIを介した移行を提供するためです。
各ツールには独自の利点があり、1つを選択する際に考慮すべきことがいくつかあります。
表1：メタデータ移行のためのツールの比較
| セットを変更する | Force.com IDE | Ant移行ツール |
|---|---|---|
| 変更セットは、標準のSalesforceUIを介してコンポーネントを配置する方法です。 | Force.com IDE（Eclipse）は、主にApex開発を目的としていますが、デプロイメントの目的で使用できます。 | Ant Migrationは、環境間で変更/メタデータを移行するための強力なコマンドラインツールです。 |
| 通常、少数のコンポーネントの移行に使用されます。 | 開発者は通常、変更をテスト環境またはステージング環境に移行するためにIDEを使用します。 | Ant Migrationは、大規模なペイロードの移行に使用され、SalesforceメタデータAPIの高度な知識が必要です。 |
| 組織間の接続は手動で確立する必要があるため、自動展開には適していません。 | どの組織にも展開するために使用できますが、エラーが発生しやすい手動の手順が必要です。 | 自動展開は非常に簡単にスケジュールできます。 |
| 管理者による使用を目的としています。 | コードの開発が主な用途であるため、セールスフォース開発者を対象としています。 | DevOpsエンジニアを対象としています。 |
| 依存関係の追加は非常に簡単でユーザーフレンドリーです。 | ポイントアンドクリックUIを提供するため、依存関係の追加はやや簡単です。 | 依存関係がないため、通常、デプロイメントは失敗します。 |
| 破壊的な変更は許可されません。 | 破壊的な変更セットを許可しますが、プロセスは非常に面倒です。 | 破壊的な変更セットを許可します。 |
メタデータAPIは、Force.comプラットフォームで変更を開発および移行するときにその目的を果たすのに最適です。 ただし、わずかな問題があります。SalesforceメタデータのすべてがMetadataAPIでサポートされているわけではありません。 公式ドキュメントには、サポートされていないコンポーネントのリストが記載されています。
組織がメタデータAPIでサポートされていない変更を行っている場合は、それらの変更を宛先組織で手動で複製する必要があります。 これらの変更を追跡する最良の方法は、スプレッドシートです。 このアプローチに頼る必要がある場合は、1人でこれらの変更を行い、追跡することを常にお勧めします。
これは、スプレッドシートでこれらの変更を追跡するために使用できる列の一般的なリストです。
- コンポーネントの名前
- コンポーネントのタイプ
- 所有者を変更する
- 機能の説明
- 機能マッピング
- 他のコンポーネントとの依存関係
- レビュー済み/レビュー担当者名
- URL
- 組織名/ID
- 他のコメント
バージョン管理と継続的インテグレーション
変更を本番環境に移行することは、テストおよびステージング環境に変更を適用することを繰り返すだけなので、スムーズなプロセスである必要があります。 それでも、物事が南下する可能性は常にあり、フォールバック計画が必要です。 組織のメタデータのバックアップを保持することは非常に重要であり、それがバージョン管理とCIビルドの目的です。
バージョン管理は、どの組織にとっても絶対に必要です。 これにより、開発者は協調的、効率的、かつ安全な方法で作業できます。 複数の開発者、複数のサンドボックスコードの開発と移行を管理することは、Salesforceの課題です。 Salesforceには、リリースとメンテナンスの独自のスケジュールもあります。 これらのアップデートは新機能を提供しますが、メタデータAPIに変更が加えられ、CIビルドが破損する可能性があります。 したがって、開発者が互いの変更を上書きしている状況は別として、バージョン管理はロールバック戦略の構築に役立ちます。 アプリケーションをForce.comで実行する場合は、ロールバック戦略を立てる必要があります。
次のフロー図は、バージョン管理とCIの実際の構造を示しています。 ダイアグラムが何を表しているかについて簡単に説明します。
- 開発者は、バージョン管理システムで変更をチェックインします。
- CIサーバー/Jenkinsは最新のビルドをCIサンドボックスにデプロイし、テストクラスを実行します。
- 手順2の展開が成功すると、変更がQAブランチにマージされます。
- 次に、CIはQAブランチからQAサンドボックスに最新のコミットをデプロイします。
- テストの失敗によりQAが変更を拒否した場合は、QAが変更をクリアするまで、手順1〜3を再度実行する必要があります。
- 変更がQAでのテストに合格すると、変更はマスターブランチにマージされます。
- マスターブランチからの最新の変更は、マスターサンドボックスにデプロイされます。
組織のニーズに応じて、ブランチを追加することを選択できます。 ただし、上記の構造は、中規模からエンタープライズレベルの開発構造では問題なく機能します。
サンドボックス管理
組織のDevOpsプロセスを最大限に活用するには、サンドボックス構造を設定することが非常に重要です。 さらに深く掘り下げる前に、Salesforceが提供するさまざまな種類のサンドボックスについて説明しましょう。
サンドボックスは、本番メタデータのほぼ正確なコピーです。 サンドボックスは通常、開発、テスト、ステージング、およびトレーニングの目的で使用されます。 サンドボックスには4つのタイプがあり、サンドボックスを選択する際には十分に考慮する必要があります。 フルコピーサンドボックスは多額の費用がかかる可能性があります。
以下は、さまざまなサンドボックスに対してSalesforceによって適用される制限の表です。
表2：限界比較
| デベロッパー | Developer Pro | 部分コピー | フルコピー | |
|---|---|---|---|---|
| 生産データ | 番号 | 番号 | はい | はい |
| データストレージ | 200 MB | 1 GB | 5GB（オブジェクトあたり10Kレコード） | 完全なデータ |
| 更新期間 | 1日 | 1日 | 5日 | 29日 |
サンドボックス間の違いは価格だけではないことがわかります。
開発者サンドボックスには1日の更新期間があるため、開発に適していますが、200 MBのデータしか収容できず、本番データは収容できません。 正反対に、フルコピーサンドボックスには本番データの正確なコピーがあります。 レコードIDも同じです。 これはテストとステージングに最適ですが、29日間の更新期間では、フルコピーのサンドボックスで最新の本番メタデータとデータを取得することが困難になります。
以下の表は、サンドボックスを選択するための経験則として機能します。
表3：サンドボックス選択のユースケース
| デベロッパー | Developer Pro | 部分コピー | フルコピー | |
|---|---|---|---|---|
| 発達 | はい | はい | 番号 | 番号 |
| QA | はい | はい | はい | 番号 |
| 統合テスト | 番号 | 番号 | はい | はい |
| バッチデータテスト | 番号 | 番号 | はい | はい |
| トレーニング | 番号 | 番号 | はい | はい |
| UAT | 番号 | 番号 | はい | はい |
| 負荷テスト | 番号 | 番号 | 番号 | はい |
| 演出 | 番号 | 番号 | 番号 | はい |
| ユーザートレーニング | 番号 | 番号 | 番号 | はい |
以下は、中規模のプロジェクトに採用されている典型的な組織構造です。 エンタープライズレベルのクライアントの場合、組織構造はより複雑になりますが、大まかに以下のモデルに従います。
Salesforceの開発は通常、開発者サンドボックス（赤）で行われ、変更は統合サンドボックス（緑）に移動されます。統合サンドボックスは通常、開発者プロまたは部分コピーサンドボックスです。 次に、複数の統合サンドボックスからの変更が、部分コピーサンドボックスであるロールアップサンドボックス（黄色）に移動されます。
組織に、統合テストと負荷テストを実行する必要があるサードパーティシステムとの統合がある場合は、リリースごとに変更されない安定したデータセットが必要です。 したがって、完全なコピーまたは部分的なコピーのサンドボックスを用意することをお勧めします。
次に、これらの変更は統合テストサンドボックスに移動され、そこでテストが実行されます。 次に、変更はステージングサンドボックスに移動されます。ステージングサンドボックスは、フルコピーのサンドボックスである必要があります。 すべてのテストクラスは、展開前に実行されます。 展開の検証を実行して、問題なく展開が行われることを確認する必要があります。
このプロセスは、変更が複数回のテストと一対の目で行われることを確認するのに役立ちます。 変更の開発、テスト、および展開に多くの時間を必要とするという大きな欠点があります。
多くの場合、バグ修正またはパッチを実行する緊急の必要性があります。 これらを迅速に処理するには、開発者サンドボックスを保持する必要があります。これにより、小さなパッチがロールアップサンドボックスに直接プッシュされます。
前述のように、サンドボックスは本番メタデータのほぼ正確なレプリカですが、完全ではありません。 サンドボックスで無効になっているコンポーネント/機能の公式リストがあります。
サンドボックスを更新する際に考慮すべきもう1つの点は、本番メタデータとデータのみをコピーすることです。 あるサンドボックスから別のサンドボックスにメタデータをコピーする方法はありません。また、メタデータ構成なしで空のサンドボックスを作成する方法もありません（無料の開発者組織など）。 これは、実際の状況では困難になることがあります。 Salesforceはこの問題に対処する計画を立てており、この機能はまもなく一般提供される可能性があります。
さらに、本番環境に機密データがあり、開発チームまたはテストチームがアクセスできないと思われる場合は、完全にコピーされたサンドボックスと部分的にコピーされたサンドボックスのサンドボックステンプレートを作成できます。
展開するときに考慮すべきこと
Salesforceエコシステムにおけるアプリケーションライフサイクル管理の業界慣行について説明しました。 メタデータとサンドボックス管理は、デプロイメントパッケージとペイロードを作成する上で非常に重要な役割を果たします。 大規模で複雑なSalesforceアプリケーションの場合、バージョン管理は、メタデータの変更を確実に追跡するのに役立ち、ロールバック戦略の作成にも役立ちます。
サンドボックス管理は、大規模または複雑なプロジェクトにとって重要です。 しかし、サンドボックスは、Salesforceエコシステムでは、財源と時間の両方の点でコストがかかります。 サンドボックス管理の戦略を策定することは、リリース管理プロセスにとって常に重要です。
次の展開時に覚えておくとよいいくつかの追加のポイントを残しておきます。
- 一度に展開できるのは、10,000ファイルまたは39MBのZIPファイルのみです。 当然、ペイロードが大きすぎる場合は、パッケージを複数の部分に分割してから展開する必要があります。
-
request timeoutエラーが原因でデプロイが失敗する場合は、パッケージからオブジェクト、カスタムフィールド、およびプロファイルを削除してみてください。 これらのコンポーネントの展開には時間がかかります。 - フィールドタイプが変更された場合、またはロール階層が変更された場合は、データの再計算が原因で長い遅延が発生し、完了するまでに時間がかかる可能性があります。
- Salesforceは、システム内のユーザーが現在使用しているコンポーネントをすべてロックします。 その場合にデプロイしようとすると、デプロイは失敗します。
この概要が、Salesforceの次のリリースで役立つことを願っています。