開発ライフサイクルのシナリオ: AW Computing

AW Computing: ソース制御の設定

リリースマネージャの Nishi は、最初に Git リポジトリを設定する必要があります。リポジトリのデフォルトのブランチは master ブランチで、本番組織のメタデータに対応しています。機能の開発では、Nishi が別個のブランチを作成して、そのブランチを開発チームと共有する必要があります。機能のブランチによって、本番環境のカスタマイズが開発環境の新機能から隔離されます。

Nishi は Git リポジトリの作成後、master ブランチに本番組織のメタデータを設定します。Nishi が行う手順を次に示します。

1. デフォルトの master ブランチを使用して Git の中央リポジトリを作成します。

   この Git リポジトリはリモートにあり、各ユーザが一度コピーする必要があります。

2. ワイルドカードを使用して、組織のすべてのメタデータ型を指定する package.xml マニフェストを準備します。このファイルは、Force.com IDE から、または手動で取得できます (「すべてのメタデータの package.xml を生成する場合のヒント」を参照)。
3. Force.com 移行ツールと package.xml マニフェストを使用して、本番組織からすべてのメタデータを取得します。
4. ダウンロードしたメタデータファイル、package.xml マニフェスト、およびツールの制御ファイルを master ブランチにコミットして、リモートリポジトリに転送します。「Force.com 移行ツールの設定」を参照してください。

これで master ブランチが設定されデータが入力されたため、Nishi は master をベースに新しい機能の作業用のブランチを作成し、このブランチを中央リポジトリに転送します。このブランチを機能ブランチと呼ぶことにします。このブランチは、チームが開発している一連の機能に固有のものです。

開発チームが機能ブランチを使用できるようになりました。チームの各開発者は Git リポジトリをコピーして、各自のシステムにローカルスナップショットを取得する必要があります。次に、各開発者が機能ブランチに切り替えます。Git リポジトリは各ユーザのローカルにあるため、開発者が行った作業でローカルリポジトリにコミットされるものは最終的にリモートリポジトリに転送する必要があります。

AW Computing: 1 人目の開発者が 1 つ目の機能をソース制御に追加する

1. 上級開発者の Andrew は、まず自身の Developer Sandbox を作成します。Andrew の Sandbox には、本番組織のアプリケーションと設定情報のコピーがあります。
2. Andrew は、Force.com IDE を使用して自身の Sandbox 組織に接続します。そして、自身の Sandbox 組織で使用可能なすべてのメタデータを取得して IDE に追加することを選択します。IDE で、この取得の package.xml ファイルが動的に作成されます。
3. Andrew は機能ブランチをコピーして、ローカルコピーを取得します。
4. そのコピーに新しいコンポーネント、Apex コード、および Visualforce ページを追加して、アプリケーションを構築します。これらのコンポーネントはすべて IDE から Sandbox 組織に保存されます。
5. Andrew は最初の機能が完了したら単体テストを実施します。
6. この時点で自身の変更を Git の機能ブランチにコミットしますが、Andrew は最初に、IDE を更新して、自身の IDE 外にある Sandbox ユーザインターフェースに手動で実施した変更を反映させる必要があります。この更新を行うために、Andrew は Force.com IDE で [サーバから更新] コマンドを実行します。
7. Andrew は、ファイルをローカルリポジトリの機能ブランチにコミットした後、git push コマンドを実行してリモートリポジトリにコミットします。これらのファイルは、IDE で作成されたフォルダとそのコンテンツ、および Sandbox のメタデータに対応するフォルダとそのコンテンツで構成されます。

AW Computing: 2 人目の開発者が他の変更を統合する

Jane はチームのもう 1 人の開発者で、アプリケーションに機能を追加したいと考えています。

1. Jane は本番組織をベースに自身の Sandbox を作成します。
2. 機能ブランチをコピーして、Andrew のカスタマイズを含むローカルコピーを取得します。
3. 前の手順で取得したメタデータファイルを自身の Sandbox にリリースするために、Jane は Force.com 移行ツールを使用します。Jane は最初に、移行ツールを設定します。
4. 続いて、Git にある package.xml を使用して Force.com 移行ツールを実行し、Git から最新の変更を自身の Sandbox に取得します。

   これで Jane の Sandbox に Andrew の変更が取り込まれます。

5. Force.com IDE に Jane 自身のカスタマイズを追加します。
6. Jane は、自身が Sandbox ユーザインターフェースで手動で実施した変更を取得するため、Force.com IDE で [サーバから更新] コマンドを実行します。
7. 作業を完了して、変更をテストします。
8. 自身の変更をローカルにコミットします。
9. Git リポジトリを更新する前に、Jane は git fetch および git merge コマンドを実行して、自身のローカルプロジェクトを作成した後に Andrew や他の開発者によってリポジトリにアップロードされた可能性のある変更を取り込みます。  競合がある場合は解決します。
10. Jane は git push コマンドを実行して、自身の変更を Git リポジトリに転送します。

AW Computing: 品質技術者がアプリケーションをテストする

チームの品質技術者である Robert が、Andrew と Jane の変更をテストします。Jane と同じプロセスに従って、自身の Sandbox を作成し、Git から変更を取得します。次に、Apex テストメソッドを追加して、これらのテストを実行し、必要に応じて追加のアドホックテストを実行します。Robert が自身のテストを Git の機能ブランチに追加します。

AW Computing: アプリケーションの同時開発中に技術者が変更を同期する

チームの他の技術者が同じアプリケーションで作業を行う必要がある場合や、アプリケーションをテストする必要がある場合、それらの技術者は Jane と同じプロセスに従って Git から変更を各自の Sandbox にリリースし、その後新しい変更を Git に再度コミットする必要があります。

次の図は、チームメンバーが所有する Sandbox と、変更がどのようにソース制御リポジトリと同期されるかを示しています。この図の Dev Sandbox は、Developer Sandbox を表しています。

AW Computing: インテグレーションおよび共有テスト

カスタマイズが完了し、完全にテストされました。チームは、外部システムから取得した組織のデータがこれらのカスタマイズで処理されることを確認するために、より綿密なテストを実行します。テストを実行するために、Robert は Partial Copy Sandbox を作成し、Git リポジトリからリリースを行ことで、最新のカスタマイズをその Sandbox にリリースします。Robert は Partial Copy Sandbox に対して Sandbox テンプレートを使用します。テンプレートを使用すると、コピーするデータを選択でき、Sandbox のサイズや内容が制御されます。Robert は次のプロセスを行います。

1. Partial Copy Sandbox を作成し、Sandbox テンプレートを使用して値を入力します。
2. Force.com 移行ツールおよび Git の package.xml ファイルを使用して、最新のカスタマイズを Git からこの Sandbox にリリースします。
3. 統合テストを実行する可能性のあるすべてのユーザを対象に、この Sandbox にユーザアカウントを作成します。
4. バグが検出された場合は、Force.com IDE を使用して Developer Sandbox で修正を行ってから、Git にコミットすることをお勧めします。

また Robert は、テストチーム以外の他の従業員がテストに使用する共有 QA Sandbox を作成します。共有 QA Sandbox は Developer Sandbox であるため、データやサポートデータテンプレートはありません。Robert は、この Sandbox にアクセスする可能性のあるすべてのユーザを対象に、複数のユーザアカウントを作成します。

AW Computing: ユーザ受け入れテストおよびトレーニング

統合テストおよび共有テストが完了したため、アプリケーションを他の従業員と共有できます。

1. リリースマネージャの Nishi は、ユーザ受け入れテスト用の Partial Copy Sandbox を設定して、その Sandbox に Git からカスタマイズをリリースします。

   このプロセスは、インテグレーション Sandbox の設定に似ています。カスタマイズには、追加テストの結果を受けてチームが行った最新のバグ修正が含まれます。

2. 企業の他のチームが新しい変更を検証したり、新しい機能を試したりすることができます。次に例を示します。
   • プロダクトマネージャは一定のアドホックテストを実行して、機能が実装されていることを確認したり、デモを作成したりできます。
   • トレーニング講師は、アプリケーションが本番組織にロールアウトされる前に、新しいアプリケーションを使用して正式なトレーニング教材を作成できます。

ユーザ受け入れテスト Sandbox で問題が検出された場合は、Developer Sandbox で修正を行い、Git にコミットします。

AW Computing: ステージング環境および本番組織への最終リリース

アプリケーションがテストおよびレビューされ、アプリケーションを本番組織にリリースできる準備ができました。承認されたアプリケーションを本番組織にリリースする前に、テストリリースのほか、最終的な回帰テスト、パフォーマンステスト、およびストレステストを実行する必要があります。この目的のために、ステージング用の中間 Sandbox 環境を設定します。この Sandbox は本番組織に似たもので、本番組織に含まれるすべての設定とデータが取り込まれています。

1. リリースマネージャの Nishi は、ステージング用の Full Sandbox を作成します。
2. Nishi は、アプリケーションをステージング Sandbox 環境にリリースし、すべての Apex テストを実行して、リリースのシミュレーションを行います。
3. QA チームが、ストレスおよびパフォーマンステストおよび最終的な回帰テストを実行します。

   Force.com プラットフォームの Sandbox と本番組織ではハードウェアが異なるため、Sandbox でのパフォーマンステストの結果が本番組織と異なることがあります。それでも、ステージング Sandbox でパフォーマンステストを実行すると、パフォーマンス上の問題 (本番組織と全く同じでないとしても) や、Apex ガバナ制限に起因するエラーを見つけるのに役立ちます。

   メモ

リリースマネージャがリリースを完了し、ステージング Sandbox で正常な結果が得られたら、本番組織へのリリースをスケジュールし、スケジュールされた時間に本番組織への最終リリースを実行します。

AW Computing: パッチ環境でバグを修正する

1. アプリケーションが本番組織にリリースされた後、Andrew は Developer Sandbox を更新して、本番組織から最新の変更を取得します。
2. 自身の Developer Sandbox で修正を行い、その変更を Git のパッチブランチにアップロードします。
3. リリースマネージャの Nishi が、Force.com 移行ツールを使用して、Git からステージング Sandbox への検証リリースを実行します。
4. Nishi が Git から本番組織へのホットフィックスリリースを実行します。