開発ライフサイクルガイド
Force.com プラットフォームでのエンター
プライズ開発
バージョン 35.0, Winter ’16
@salesforcedocs
最終更新日: 2015/9/1
© Copyright 2000–2015 salesforce.com, inc. All rights reserved. Salesforce およびその他の名称や商標は、salesforce.com,
inc. の登録商標です。本ドキュメントに記載されたその他の商標は、各社に所有権があります。
目次
第 1 章: Force.com 開発ライフサイクルの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
本番組織での開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Sandbox を使用した開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Sandbox 組織について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
組織間での変更の移行について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
クイックスタート: Sandbox および変更セットの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Developer Sandbox の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
リリース接続の承認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
送信変更セットの作成およびアップロード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
受信変更セットの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
受信変更セットのリリース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
第 2 章: 開発環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
開発とテストの分離 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
統合、テスト、およびステージングを含む複数プロジェクトの開発 . . . . . . . . . . . . . . . . 8
開発環境の種別について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sandbox の使用方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sandbox の考慮事項と制限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
開発 Sandbox の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
環境の連動関係の更新 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ユーザテンプレートの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Sandbox の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
第 3 章: 開発ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Force.com アプリケーションビルダーツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Force.com IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
メタデータ API について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Force.com 移行ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
データローダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
第 4 章: 開発の変更の追跡および同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
本番組織での変更プロセスの確立 . . . . . . . . . . . .
手動による変更の追跡 . . . . . . . . . . . . . . . .
Force.com 移行ツールを使用した変更の追跡 .
Force.com IDE を使用した変更の追跡 . . . . . .
変更の同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数の Sandbox の同期 . . . . . . . . . . . . . . . .
開発環境全体での変更の統合 . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
24
25
25
25
26
目次
第 5 章: リリース管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
エンタープライズアプリケーションの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
並行開発プロジェクトのスケジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
リリーストレインでのアプリケーションの配信 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Salesforce のアップグレードが配信スケジュールに与える影響 . . . . . . . . . . . . . . . . 31
第 6 章: 環境間の変更のマージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
変更の手動移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
メタデータファイルの移行方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
リリース時間に影響する要因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
開発状況の監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
リリースの連動関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
バッチでのファイルの移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
まとめてリリースするファイルの決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Force.com IDE を使用したファイルのバッチリリース . . . . . . . . . . . . . . . . . . . . . . . 41
Force.com 移行ツールを使用したファイルのバッチ移行方法 . . . . . . . . . . . . . . . . . 43
コンポーネントの削除と名前変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
AppExchange の使用した変更の移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
本番組織へのリリース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
リリースのスケジュール設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
プロファイルを使用したメンテナンス更新の制御 . . . . . . . . . . . . . . . . . . . . . . . . 46
バグ修正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
第 7 章: 高度な開発ライフサイクルシナリオ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ソース制御システムとリリースツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
開発者ライフサイクルと Sandbox 環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
パッチリリース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
開発ライフサイクルのシナリオ: AW Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
継続的インテグレーションプロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
API でサポートされていないメタデータの処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Force.com 移行ツールの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
本番リリースの考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Sandbox 環境の更新 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
第1章
Force.com 開発ライフサイクルの概要
Force.com プラットフォームでのアプリケーション開発は、簡単でわかりやすく、非常に生産的です。開発者
は、Web インターフェースのポイント & クリックツールを使用して、アプリケーションコンポーネント (カス
タムオブジェクトや項目、ワークフロールール、Visualforce ページ、Apex クラスおよびトリガなど) を定義でき
ます。簡単な変更であれば、ただちに実装してリリースでき、本番組織の他のユーザに影響を与えることがあ
りません。より複雑な機能については、完全にテストされるまで開発状況のままにし、テスト後、本番組織の
すべてのユーザにリリースすることができます。
ただし、何人かの開発者が協力して、大規模なエンタープライズアプリケーションを構築する場合、こうした
開発手法はどのように機能するでしょうか。高度にカスタマイズされたロジックやユーザインターフェースを
備えた複雑なアプリケーションを開発する場合、1 つの環境だけで構成しても意味がありません。こうしたア
プリケーションの開発には時間がかかります。また、アプリケーションが意図したとおりに機能し、ユーザの
ニーズを満たすようにするには、より本格的な手法が必要になります。
また、この中間に位置するものも多数あります。プロジェクトがさほど大きくなく、開発者が日常の管理業務
の傍ら一人で開発していることもあります。そのような状況でも、Sandbox を開発環境として使用する利点が
あります。たとえば、Sandbox では、エンドユーザに影響を与えることなくカスタマイズやコードを開発でき
ます。従来のプロジェクトベースの開発は、Force.com での開発に新たな可能性をもたらしますが、開発や移
行、同期のための新しいプロセスも必要になります。
アーキテクト、システム管理者、開発者、マネージャのいずれであれ、このガイドにより、Force.comプラット
フォームでアプリケーションを開発およびリリースする準備を整えることができます。はじめに、Developer
Sandbox と変更セットを使用したごく基本的なシナリオについて解説します。後続の章では、より複雑なエン
タープライズシナリオに応じたその他の開発環境やツール、プロセスについて説明します。
本番組織での開発
新機能を開発する最も簡単な方法は、Salesforce Web ユーザインターフェースを使用して本番組織をカスタマイ
ズすることです。強力で使いやすい宣言型ツールを使用して、新しいオブジェクトやアプリケーションを開発
できます。このシナリオでは、すべての開発が本番組織で行われるため、開発環境やテスト環境を別個に用意
する必要がありません。このプロセスでは、開発ライフサイクル全体を最も速く完了できますが、できること
が限られています。たとえば、本番組織で直接 Apex コードを作成することはできません。
1
Force.com 開発ライフサイクルの概要
Sandbox を使用した開発
典型的な開発ライフサイクルは次のようになります。
1. 機能要件を計画します。
2. Salesforce Web ツールを使用して開発を実施します。プロファイルを使用してリリース準備が整うまで変更
を非表示にします。
3. プロファイルを更新して、変更を適切なユーザに公開します。
4. 変更についてエンドユーザに通知します。
この方法では、1 人システム開発者が効率的に新規ダッシュボード、レポート、メールテンプレートの開発
や、既存のオブジェクトへの新規カスタム項目の追加を行うことができます。ただし、より複雑で複数のチー
ムメンバーが参加する開発では、より本格的なアプリケーションライフサイクルシナリオが適しています。
Sandbox を使用した開発
若干複雑な開発タスクや、本番組織から隔離する必要がある開発タスクの場合、別個の開発環境 (通常は Sandbox)
を使用できます。このシナリオでは、開発とテストのすべてを環境環境で行ってから、変更を本番環境に移行
します。
本番組織と Sandbox 組織で同時に開発プロジェクトを実施している場合、本番組織に加えた設定の変更を追跡
して、Sandbox に複製することを検討してください。Sandbox のカスタマイズが最新ではない場合、Sandbox か
らカスタマイズを移行するときに、意図せずに本番の新しい変更をこれらの古いカスタマイズで置き換えてし
まうことがあるため、これは重要です。
2
Force.com 開発ライフサイクルの概要
Sandbox 組織について
典型的な開発ライフサイクルは次のようになります。
1. 開発環境を作成します。
2. Salesforce Web ツールやローカルツールを使用して開発を実施します。
3. 開発環境内でテストします。
4. 本番組織の変更を開発環境に複製します。
5. 開発したものを本番組織にリリースします。
典型的な開発プロジェクトとして、次のようなものがあります。
• 新規のカスタムオブジェクト、タブ、およびアプリケーション
• 他のシステムとの統合
• Apex、Visualforce、ワークフロー、または新しい入力規則を含むアプリケーション
Sandbox 組織について
Sandbox は、本番組織のコピーです。Sandbox には、本番組織と同じメタデータ (カスタムオブジェクトと項目
の種別、アプリケーション、ワークフローなどの設定情報) が含まれます。このメタデータ (Full Sandbox の場合
はデータも) が本番組織とは隔離された新しい組織にコピーされます。Sandbox で実行する操作は、本番組織に
は影響しません。
Sandbox は、Enterprise Edition、Unlimited Edition、および Performance Edition で使用できます。Unlimited Edition および
Performance Edition では、種別が異なる複数の Sandbox のコピーを作成できます。Salesforce 本番組織のデータやア
プリケーションを損なうことなく、Sandbox を使用して、開発、テスト、トレーニングなどを行うことができ
ます。Sandbox が本番組織から隔離されているのと同様、個々の Sandbox インスタンスは他のすべての Sandbox
インスタンスから隔離されています。
3
Force.com 開発ライフサイクルの概要
組織間での変更の移行について
組織間での変更の移行について
設定の変更を組織間で送信する最も簡単な方法は、変更セットを使用することです。現在の組織から別の組織
にカスタマイズを送信するには、送信変更セットを作成します。送信した変更セットは、受信側の組織で受信
変更セットとして表示されます。
変更セットには、[設定] メニューから行える変更のみが含まれます。また、カスタマイズ可能なコンポーネン
トのうち、変更セットでサポートされないものもあります。また、変更セットを使用して、コンポーネントの
名前を変更したりコンポーネントを削除したりすることはできません。変更セットでサポートされない変更を
行った場合、他の組織で実行した手順をもう一度行うことで、その変更を手動で移行できます。変更セットで
使用可能なコンポーネントについての詳細は、Salesforce オンラインヘルプを参照してください。
他のコンポーネントと連動するコンポーネントもあります。たとえば、カスタムオブジェクトのカスタム項目
は、そのカスタムオブジェクトの存在に依存します。そのカスタム項目を、連動するカスタムオブジェクトが
含まれない組織に移行しようとすると、リリースが失敗します。変更セットを作成すると、連動関係を簡単に
表示および追加して、すべての必要なコンポーネントを確実に移行することができます。
2 つの組織間で変更セットを送信するには、リリース接続が必要です。変更セットは本番組織と関連付けられ
ている組織間でのみ送信できます。たとえば、本番組織と Sandbox 間、または同じ組織から作成された 2 つの
Sandbox 間で変更セットを送受信できます。
リリース接続だけでは、変更セットを組織間で送信することはできません。変更セットの送受信を行うために
は、各組織が認証されている必要があります。このセキュリティレベルの強化によって、コードプロモーショ
ンパスを適用し、組織の設定メタデータが間違って上書きされるのを防ぎます。
クイックスタート: Sandbox および変更セットの使用
次の手順に従って、Developer Sandbox を作成し、そこで行った設定の変更を変更セットを使用して本番組織に
移行します。
• Developer Sandbox の作成
4
Force.com 開発ライフサイクルの概要
Developer Sandbox の作成
• リリース接続の承認
• 送信変更セットの作成およびアップロード
• 受信変更セットの検証
• 受信変更セットのリリース
Developer Sandbox の作成
Developer Sandbox を使用して、リリース準備の準備ができるまで、変更を本番組織から隔離します。
Sandbox は、Enterprise Edition、Unlimited Edition、および Performance Edition でのみ使用できます。
1. [設定] から、[Sandbox] をクリックします。
2. [新規 Sandbox] をクリックします
3. Sandbox の名前と説明を入力します。
4. Sandbox の種別に [開発者] を選択します。
5. [コピー開始] をクリックします
組織の規模によっては、この処理にしばらく時間がかかることがあります。Sandbox のコピーが完了する
と、メール通知を受け取ります。
6. 通知メールのリンクをクリックして Sandbox にアクセスします。
.sandbox_name をユーザ名に追加することで、test.salesforce.com/login.jsp から Sandbox にログ
インできます。たとえば、本番組織のユーザ名が [email protected] の場合、「test」という名前の Sandbox
のユーザ名は [email protected] になります。
メモ: Salesforce は、Sandbox のユーザ名を自動的に変更しますが、パスワードは変更しません。
開発プロジェクトで使用する前に変更セットを試してみる場合は、カスタム項目を含むテスト用のカスタムオ
ブジェクトを Developer Sandbox に作成します。これらのカスタマイズは、次のステップでリリースし、完了後
に削除できます。
リリース接続の承認
Sandbox またはその他の組織から変更セットを受信する前に、変更を受信する組織でリリース接続を承認しま
す。
1. 変更セットを受信する組織にログインします。通常、これは Sandbox に関連付けられた本番組織です。
2. [設定] で、[リリース] > [リリース接続] をクリックします。
3. 変更セットを送信する組織の横にある [編集] をクリックします。通常、これは Sandbox 組織です。
4. [変更着信を許可] を選択して、[保存] をクリックします。
送信変更セットの作成およびアップロード
通常、送信変更セットは Sandbox 組織で作成し、本番組織にリリースします。ただし、開発ライフサイクルに
よっては、関連する組織間でどの対象に変更を移行するかを選択する場合もあります。
5
Force.com 開発ライフサイクルの概要
受信変更セットの検証
1. [設定] で、[リリース] > [送信変更セット] をクリックします。
2. [新規] をクリックします。
3. 変更セットの名前を入力し、[保存] をクリックします。
4. [変更セットコンポーネント] セクションで、[追加] をクリックします。
5. コンポーネントの種別 (カスタムオブジェクトやカスタム項目など) および追加するコンポーネントを選択
し、[変更セットに追加] をクリックします。
テスト用のカスタムオブジェクトおよびカスタム項目で試してみる場合は、まずいずれか 1 つを変更セッ
トに追加します。
6. [連動関係を参照/追加] をクリックして、変更セットに追加したコンポーネントが他のカスタマイズと連動
しているかどうかを確認します。
テスト用のカスタムオブジェクトとカスタム項目の場合、関連するコンポーネントおよびページレイアウ
トの両方が表示されます。
7. 追加する連動コンポーネントを選択し、[変更セットに追加] をクリックします。
8. [アップロード] をクリックし、リリース先組織を選択します。
送信変更セットの詳細ページにメッセージが表示され、アップロードの完了時にメール通知を受け取りま
す。
これで、リリース先組織にログインすると、受信変更セットを確認できます。
受信変更セットの検証
変更セットを確認することで、変更をコミットすることなく成功または失敗のメッセージを確認できます。
1. [設定] で、[リリース] > [受信変更セット] をクリックします。
2. 変更セットの名前をクリックします。
3. [検証] をクリックします。
メモ: テストリリースの実行中は、組織に変更を行うことはできません。
4. 確認が完了したら、[結果を表示] をクリックします。
エラーメッセージがある場合は、それらを解決してからリリースします。最も一般的なエラーの原因は、
連動コンポーネントが変更セットに含まれていないため Apex テストが失敗することです。
受信変更セットのリリース
変更セットのリリースでは、変更セットに含まれる変更をリリース先組織にコミットします。
1. [設定] で、[リリース] > [受信変更セット] をクリックします。
2. [変更セットリリース待ち] リストで、リリースする変更セットの名前をクリックします。
3. [リリース] をクリックします。
変更セットは、1 つのトランザクションでリリースされます。何らかの理由でリリースが完了できないとき
は、トランザクション全体がロールバックされます。リリースが正常に完了した後は、すべての変更が組
織にコミットされます。リリースはロールバックできません。
6
第2章
開発環境
Force.comプラットフォームでの開発では、他のユーザに影響を与えずに作業できる開発環境が必要です。従来
のソフトウェア開発では、開発環境は開発者が自由に使用できる単なる領域ですが、Force.comプラットフォー
ムでは、各開発環境が完全に機能する独自の Salesforce 組織です。
「クイックスタート: Sandbox および変更セットの使用」 (ページ 4)では、1 つの開発環境と 1 つの Developer
Sandbox を使用して、変更を本番組織から隔離しました。より複雑なシナリオでは、開発、統合、テスト、ト
レーニングなど、目的に応じて複数の環境が必要になる場合もあります。また、最適な開発環境の種別がユー
ザごとに異なる場合もあります。
開発とテストに 1 つの開発環境を使用する場合は、テスト用に開発を停止する必要があり、リリースが終わる
まで開発を再開できません。このため、これらのすべてのタスクを 1 人の開発者が行っていない限り、リソー
スの使用が非効率的になる可能性があります。より高度な開発モデルでは、テストやリリースの進行中に開発
を引き続き行うことができます。この場合は、開発用とテスト用に 2 つの隔離された環境が必要です。
開発とテストの分離
開発環境とテスト環境を分離すると、開発プロセスが複雑になり、既存のコンポーネントへの変更をどこで行
えばよいかわからなくなることがあります。たとえば、開発したアプリケーションがあり、その変更をテスト
環境に移行するとします。テスト中、本番組織にリリースするにはいくつか変更を行う必要があることに気づ
きます。その変更をテスト環境で行うのと、開発組織に戻って最初からプロセスをやり直すのとどちらがよい
でしょうか。Sandbox が 2 つのみの場合は、テスト組織での変更が便利です。その方がプロセスが速く容易で
あるうえに、開発 Sandbox がすでに変更されており、最初からやり直すのが容易でない状態になっている可能
性があるためです。ただしその場合でも、テスト環境に加えた変更を元の開発環境に複製して、次回開発から
テストに移行したときにその修正が保持されるようにする必要があります。アプリケーション開発プロセスの
配置と流れは次の図のようになります。
7
開発環境
統合、テスト、およびステージングを含む複数プロジェ
クトの開発
典型的な開発ライフサイクルは次のようになります。
1. 開発環境を作成します。
2. Salesforce Web ツールやローカルツールを使用して開発を実施します。
3. テスト環境を作成します。
4. 変更を開発環境からテスト環境に移行します。
5. テストを実施します。
6. 本番組織の変更を他の環境に複製します。
7. 開発したものを本番組織にリリースします。
典型的な開発プロジェクトとして、次のようなものがあります。
• 新規のカスタムオブジェクト、タブ、およびアプリケーション
• 他のシステムとの統合
• ワークフローまたは新しい入力規則を含むアプリケーション
統合、テスト、およびステージングを含む複数プロジェクトの開
発
複数の開発者がいて、同時にリリース予定の複数の開発プロジェクトが進行中の場合、別個のコード行が矛盾
なくマージされるようにするため、統合テストを行う必要があります。その後、ユーザ受け入れテスト (UAT)
を追加して、元の設計要件が満たされているかどうかの判定が必要になる場合もあります。より複雑な開発プ
ロセスには、ステージング環境が含まれる場合もあります。ここでは、本番組織へのリリースが厳密に計画ど
おり実行されることを確認します。
こうした開発シナリオの場合、どこでコード行を変更すればよいでしょうか。本番リリースへの途中で機能が
テストに失敗したら、失敗した環境でその機能を修正しますか、それともプロセス全体を最初からやり直しま
すか。このアプリケーション開発プロセスは複雑なため、その都度修正を行う方法は適切ではありません。代
わりに、すべての修正を開発組織で行い、その変更を本番組織に移行するという、繰り返し可能なプロセスに
従います。次の図は、このプロセスを表しています。
8
開発環境
統合、テスト、およびステージングを含む複数プロジェ
クトの開発
典型的な開発ライフサイクルは次のようになります。
1. 開発環境を作成します。
2. Salesforce Web ツールやローカルツールを使用して開発を実施します。
3. UAT および統合を含む、テスト環境を作成します。
4. 変更を開発環境から統合環境に移行します。
5. テストを実施します。
6. 変更を統合環境から UAT 環境に移行します。
7. ユーザ受け入れテストを実施します。
8. 変更を UAT 環境からステージング環境に移行します。
9. 本番組織の変更をステージング環境に複製します。
10. リリースをスケジュールします。
典型的な開発プロジェクトとして、次のようなものがあります。
• 複数環境での新規アプリケーションの並行開発
• チーム開発が必要なプロジェクト
9
開発環境
開発環境の種別について
開発環境の種別について
開発環境には、Sandbox 組織および Developer Edition 組織の 2 つの種別があります。
Sandbox は、本番組織からコピーされた新しい組織です。用途に応じた、異なる種別の Sandbox があります。
Sandbox の種別
説明
Developer
DeveloperSandboxでは、コーディングとテスト用にカスタマイズ (メタデータ) が別の
環境にコピーされますが、本番データはコピーされません。
Developer Pro
Developer Pro Sandbox では、コーディングとテスト用にカスタマイズ (メタデータ) が
別の環境にコピーされますが、本番データはコピーされません。Developer Pro Sandbox
には、Developer Sandbox より大きいストレージが割り当てられます。本番組織のエ
ディションに応じて、いくつかの Developer Sandbox が含まれます。
Partial Copy
Partial Data Sandbox は、Developer Sandbox に Sandbox テンプレートで定義したデータを
加えたものです。
Full
Full Sandbox には、本番組織全体と、本番組織の標準およびカスタムオブジェクトレ
コード、ドキュメント、添付ファイルなどのすべてのデータがコピーされます。こ
の Sandbox は、変更のコーディングやテスト、変更に関するチームのトレーニング
に使用します。Full Sandbox は、29 日ごとに更新できます。
使用目的に応じて、Sandbox に本番データの一部または全部を含めたり、まったく含めないようにしたりする
こともできます。開発では、正常に動作することを確認するための小さなデータセットのみが必要です。QA
テスト (特に回帰テスト) では、長期間にわたって変更されない大量のデータセットが必要です。リリース前の
ステージングでは、データを含め本番環境にできるだけ近い Sandbox が必要です。Full Sandbox の場合に限り、
データは作成時にコピーされますが、インポートウィザードまたはデータローダを使用してデータを Sandbox
に追加することもできます。
Force.com プラットフォームで使用できる他の開発環境として、Developer Edition 組織があります。Developer Edition
では、Enterprise Edition、Unlimited Edition、Performance Edition でのみ使用できる多くの機能に自由にアクセスでき
ます。Force.comプラットフォームおよびAPIにフルアクセスできるため、Salesforceの拡張、他のアプリケーショ
ンとの統合、新しいツールやアプリケーションの開発を行うことができます。Developer Edition 組織は、AppExchange
で配布するためにアプリケーションを作成する独立系ソフトウェアベンダ (ISV) で主に使用されます。詳細は、
『ISVforce ガイド』を参照してください。
Sandbox の使用方法
組織に複数の Sandbox がある場合、各 Sandbox を何の目的で使用するかを計画するときに次の要素を考慮して
ください。
使途
Sandbox の種別
メモ
開発
Developer または Developer Pro Sandbox
Full Sandbox は、作成時間と更新時間の点で
よりコストがかかり、開発者が不適切なデー
10
開発環境
使途
Sandbox の考慮事項と制限
Sandbox の種別
メモ
タにアクセスできてしまう可能性もありま
す。
テスト
• 単体テストおよび Apex テスト: Developer
または Developer Pro Sandbox
• 機能テストおよび回帰テスト: Partial Copy
Sandbox (標準データセットの読み込みを
含む)
外部インテグレー 外部システムで完全な本番データが必要な
ションのテスト
場合は Full Sandbox が最適
サンプルデータまたは実際のデータのサブ
セットを使用する特別な状況では、Partial
Copy Sandbox が適切な場合があります。外部
ID を使用している場合は適切に機能します。
ステージングおよ 本番組織の設定およびデータで新規アプリ 本番データのサブセットでのテスト (地域テ
びユーザ受け入れ ケーションを検証する場合は Full Sandbox が ストなど) が許容される場合は Partial Copy
テスト
最適
Sandbox が適しています。
本番組織のデバッ Full Sandbox
グ
Sandbox の考慮事項と制限
Sandbox の機能は本番組織とは異なります。コピープロセス自体だけでなく、その相違点も計画に入れる必要
があります。
Sandbox を作成または更新するときは、次の点を考慮してください。
• Sandbox コピーの作成または更新には時間がかかり、数分から数日、または 1 週間以上かかることもありま
す。この所要時間は、カスタマイズの数、データサイズと設定 (フルコピーの場合)、オブジェクトの数、
およびサーバの負荷などのいくつかの条件によって決まります。また、Sandbox の更新はキューに追加され
るため、コピーを要求しても即時にコピーが開始されないことがあります。したがって、事前に計画を立
て、Full Sandbox の省略可能なデータには、可能な場合は常にデフォルトの最小値を受け入れます。
• Sandbox の更新では、その Sandbox が削除され、本番組織の新しいコピーとして再作成されます。つまり、
この更新により、手動で行ったアクセス権の変更は元に戻ります。Sandbox でユーザを作成した場合はそれ
らのユーザは存在しなくなり、ユーザの権限を変更した場合は本番組織での値に戻されます。つまり、更
新後に、新しいコピーでアクセス権の変更を再度行う必要があります。このプロセスを避けるため、本番
組織でユーザテンプレートを作成し、それを Sandbox 組織で有効化できます。
• Sandbox の作成および更新作業中に本番組織の設定やデータを変更すると、Sandbox 内で矛盾が生じる場合
があります。したがって、Sandbox の作成中または更新中は、本番組織への変更は行わないか最低限にする
ことをお勧めします。
次の機能は無効になっており、Sandbox で有効にすることはできません。
• ケースのエスカレーション
11
開発環境
開発 Sandbox の作成
• 契約の有効期限警告
ケースのエスカレーションと契約の有効期限の警告は、Sandbox を使用できないようにする必要がある取引
先責任者、顧客、ユーザにメールが自動的に送信されるため、無効になっています。
• 登録明細
• データのエクスポート ([設定] の [データの管理] > [データのエクスポート] > [今すぐエクスポート] または
[データの管理] > [データのエクスポート] > [エクスポートをスケジュール])
• Salesforce Sandbox 作成機能
• Sandbox 内に作成したメールサービスアドレスは、本番組織にコピーできません。
• Site.com サイトの公開機能
関連トピック:
ユーザテンプレートの作成
開発 Sandbox の作成
特定のプロジェクトまたはタスクに必要な開発環境の種別を決定したら、本番組織の Sandbox コピーを作成し
ます。
1. [設定] で、[Sandbox] をクリックします。
2. [新規 Sandbox] をクリックします
3. Sandbox の名前と説明を入力します。
4. Sandbox の種別を選択します。
5. [コピー開始] をクリックします
組織の規模によっては、この処理にしばらく時間がかかることがあります。Sandbox のコピーが完了する
と、メール通知を受け取ります。
6. 通知メールのリンクをクリックして Sandbox にアクセスします。
.sandbox_name をユーザ名に追加することで、test.salesforce.com/login.jsp から Sandbox にログ
インできます。たとえば、本番組織のユーザ名が [email protected] の場合、「test」という名前の Sandbox
のユーザ名は [email protected] になります。パスワードは本番組織と同じです。
7. Sandbox と本番組織が誤ってやりとりしないようにするため、小さな変更が加えられます。この手順で作成
した Sandbox を使用する前に、『 開発ライフサイクルガイド (PDF) 』の「環境の連動関係の更新」セクショ
ンの説明に従って、これらの設定を調整してください。
ヒント: 使用可能な Sandbox の数と種別は、Salesforce 組織によって異なります。
関連トピック:
環境の連動関係の更新
本番組織での変更プロセスの確立
変更の同期
12
開発環境
環境の連動関係の更新
環境の連動関係の更新
Sandbox を作成したら、リリースを開始する前に、環境の連動関係を更新し、プロジェクトコンテンツをマー
ジするように Sandbox を設定します。複数の開発環境がある場合は、プロジェクトの進行に伴って、自分が行っ
た変更と他のチームメンバーによる変更を 1 つの開発環境にマージする必要があります。これらの変更を正常
にマージできるようにするため、このフェーズですべての環境の変更を追跡する必要があります。
環境の連動関係とは、開発環境と本番組織間の異なる設定です。開発環境で作業するときは、各ユーザがアク
セスできる機能を更新し、特定の機能のオン/オフを切り替え、本番組織ではなく開発環境を指し示すように
内部システムと外部システムのアドレスを更新する必要があります。逆の場合も同様です。本番組織にリリー
スする場合は、開発で使用した特定の設定を更新して、本番組織で動作するようにする必要があります。
環境の連動関
係
詳細
ログイン権限
開発者とテスト担当者が本番組織のログイン情報を持っていないか、必要な権限がない場
合、開発環境で必要なアクセス権を付与する必要があります。
メールアドレ
ス
Sandbox を作成すると、開発中にメールアラートや他の自動通知が Sandbox から送信されない
ように、メールアドレスが自動的に変更されます。開発者とテスト担当者は、Sandbox にロ
グインしたらメールアドレスを実際のアドレスに戻して、Sandbox からのメールメッセージ
を受信できるようにする必要があります。
メール受信者
エスカレーションやダッシュボードなどの機能の送信メールをテストする場合は、受信者リ
ストを更新する必要があります。受信者リストは不要なメールを受信しないように Sandbox
作成時に削除されるためです。
外部 URL
本番組織が外部システムと統合されている場合、本番データと非本番データの混在を避ける
ため、通常、Sandbox コピーと外部システムの本番バージョンとのやりとりは行いません。
たとえば、アウトバウンドメッセージまたは Web サービスコールアウトを使用する場合は、
それらのサービスからコールされる URL を更新して、そのアプリケーションの外部開発環境
を指し示すようにします。同様に、Sandbox は本番組織以外のインスタンスで実行されるた
め、Sandbox との統合をテストするには、API エンドポイントのホスト名を
login.salesforce.com から test.salesforce.com に変更する必要があります。
ハードコード
された URL
通常、1 つの Force.com ページから別のページにリンクする場合、リンクは、絶対リンクでは
なく相対リンク (ホスト名を省略) にし、静的リンクではなく動的リンク (ID、レコード、ペー
ジを名前で参照) にします。これにより、ホスト名やレコード ID が異なる組織間で URL を移
行することができます。1 つの Force.com ページから別のページにリンクするハードコードさ
れた URL がアプリケーションに含まれていると、Sandbox でクリックしたときにリンクが機能
しなくなり、開発環境にいると思っているユーザが本番組織に戻ってしまう場合がありま
す。
ハードコード
された ID
一部のコンポーネントには通常、RecordTypes などの ID を介してアクセスします。Sandbox コ
ピーを作成すると、本番 ID が Sandbox で保持されるため、これらの ID を使用してコンポーネ
ントを参照するコードは引き続き動作します。ただし、逆の場合は必ずしも動作するとは限
りません。メタデータを介した Sandbox から本番組織への移行では、コンポーネント名は保
持されますが、移行先組織にコンポーネントが存在しないと、新しい ID が生成されます。そ
のため、ハードコードされた ID を含むコードを移行することによって、コードが破損する可
13
開発環境
ユーザテンプレートの作成
環境の連動関
係
詳細
能性があります。可能な限り、コンポーネント名をクエリしてコンポーネント ID を取得する
ことをお勧めします。
既存のプロ
ジェクト
既存の開発プロジェクトがある場合は、作業を新しい開発環境にマージする必要がありま
す。
ユーザテンプレートの作成
Sandbox を更新すると、本番組織の新しいコピーが作成されます。つまり、Sandbox 内のすべてのユーザ権限が
本番組織からコピーされ、更新前に Sandbox でユーザアクセスまたはユーザ権限に加えた変更を再適用する必
要があります。複数の Sandbox が存在するか、Sandbox を定期的に更新する場合は、本番組織で開発ユーザテン
プレートを作成することを検討してください。開発ユーザテンプレートは、Sandbox での開発には必要だが本
番組織では無効な権限 (「すべてのデータの編集」権限など) を持つ抽象ユーザです。Sandbox を作成または更
新したら、Sandbox で開発ユーザを有効化し、そこで開発する個々のユーザに割り当てます。
開発テンプレートを作成する手順は、次のとおりです。
1. 本番組織で新規ユーザを作成します。
2. ユーザを編集して、必要な権限を付与します。
3. 本番組織でユーザを無効化します。
4. Sandbox を作成または更新します。
5. Sandbox でユーザを有効化します。
6. 必要に応じて、メールアドレス、パスワード、または他の環境設定を変更します。
警告: 本番環境からコピーされた機密情報 (社会保障番号など) が含まれる Sandbox 組織で権限を付与する
ときは、十分注意してください。
ロールごとに異なるテンプレートを作成すると便利な場合があります。たとえば、「すべてのデータの編集」
権限を持つ開発者ロールや、標準のユーザ権限を持つ QA テスト担当者ロールを作成できます。
Sandbox のライセンス数は本番組織と同じですが、すべてのユーザがログインすることはまずありません。
Sandbox を作成または更新すると、本番組織で有効なユーザが Sandbox でも有効になるため、すべてのライセン
スが使用された場合、無効な開発ユーザを有効化するには、有効なユーザを無効化する必要があります。ここ
で Sandbox で無効化するユーザは、その環境にログインすることのない、多くの本番組織のユーザの 1 人です。
同様に、有料の本番ライセンスが消費されないようにするため、本番開発ユーザテンプレートを本番組織で無
効化する必要があります。
ユーザの有効化、無効化、編集についての詳細は、Salesforceオンラインヘルプの「ユーザの編集」を参照して
ください。
Sandbox の管理
Sandbox を管理するには、[設定] から [Sandbox] をクリックします。既存の Sandbox のリストが表示されます。
14
開発環境
Sandbox の管理
• 新しい Sandbox を作成するには、[新規 Sandbox] をクリックします。組織の Sandbox が制限に達すると、
Salesforce は [新規 Sandbox] ボタンを無効にします。必要に応じて、組織で Sandbox をさらに注文する場合は、
Salesforce にご連絡ください。
• Sandbox の作成日時や作成者などの Sandbox の更新履歴のログを表示するには、[Sandbox 履歴] をクリックし
ます。
• 既存の Sandbox を新しいコピーで置き換えるには、[更新] をクリックします。Salesforce は、Sandbox の種別に
よって異なる、更新対象の Sandbox の[更新]リンクのみを表示します。更新の完了を待つ間は、この Sandbox
の既存のコピーを引き続き使用できます。更新されたコピーは、有効にするまで無効です。
• 更新された Sandbox を有効にするには、[有効化] をクリックします。更新された Sandbox にアクセスするに
は、まず有効にする必要があります。Salesforce は、有効になっていない Sandbox に対してのみこのオプショ
ンを表示します。
警告: 更新された Sandbox を有効にすると、既存の Sandbox が更新されたバージョンで置き換えられま
す。これによって、既存のバージョンと、そこに保存されているすべてのデータは完全に削除されま
す。本番組織とそのデータは影響を受けません。
• Sandbox を削除するには、[削除] をクリックします。削除オプションは、組織が Sandbox の制限を超えてい
ない場合にのみ選択できます。
警告: Sandbox を削除すると、その Sandbox と、そこに保存されているすべてのデータが完全に削除さ
れます。
• システム管理者は [ログイン] をクリックして、ユーザとして Sandbox にログインできます。Salesforce は、有
効な Sandbox に対してのみこのオプションを表示します。ユーザは自分の Salesforce ユーザ名に
.sandbox_name を付加することにより、https://test.salesforce.com から Sandbox にログインでき
ます。たとえば、本番組織のユーザ名が [email protected] で、Sandbox の名前が「test」の場合、Sandbox
にログインするための変更後のユーザ名は [email protected] になります。
• Sandbox の種別とその作成日を含む Sandbox の詳細を表示するには、Sandbox 名をクリックします。
15
第3章
開発ツール
開発プロセスでのロールに関わらず、Force.comのすべての開発ツールの動作と、相互に重なり合う開発タスク
の概要を理解することは重要です。リリース管理では、すべての組織での変更を追跡することが課題であり、
ツールを理解することにより変更の追跡作業が簡単になります。
Salesforce Web ユーザインターフェースを使用したアプリケーションの作成方法はご存じでしょう。プロジェク
トベースの開発では、デスクトップツールも操作する必要があります。Force.com IDE は、チーム開発、選択し
たコンポーネントの移行、Apexの作成に最適なツールです。他方、Force.com 移行ツールは、大規模な変更や反
復する変更を環境間で移行するのに役立ちます。これらのツールおよび他の Force.com ツールについては、次
のセクションで説明します。
Force.com アプリケーションビルダーツール
アプリケーションコンポーネントの作成および変更に使用できるツールは数多くありますが、Web インター
フェースを使用して開始するのが最も簡単です。
Salesforce ユーザインターフェースを使用すると、ポイント & クリックを使用したアプリケーションビルダー
ツールで簡単にアプリケーション開発を行うことができます。[設定] から、組織のメタデータを変更できま
す。
16
開発ツール
Force.com IDE
Web インターフェースは簡単に使用できるため、システム管理者が開発環境を使用せずに直接本番組織に変更
を加えることがよくあります。これは、機能をすぐに使用する必要があるユーザにとっては便利ですが、本番
組織での変更を追跡して、同じ機能を必要に応じてテストまたはステージング用の Sandbox に移行できるよう
にする必要があります。
Force.com IDE
Force.com IDE は、Apex、Visualforce、メタデータコンポーネントを使用して、Force.com プラットフォームでアプ
リケーションを開発する統合開発環境です。開発者および開発チーム向けに設計された IDE には、ウィザー
ド、ソースコードエディタ、テスト実行ツール、リリース支援や統合ヘルプなど、Force.comのアプリケーショ
ン開発を促進するツールが用意されています。
17
開発ツール
Force.com IDE
Force.com IDE は、オープンソースの Eclipse プラットフォームの上位に構築され、プラグインとして使用できま
す。Eclipse には豊富な機能が揃っています。Eclipse の機能についての詳細は、ヘルプコンテンツの『ワークベ
ンチユーザガイド』を参照してください。
Force.com のプロジェクトべースの開発には、開発環境 (Sandbox)、統合開発環境 (IDE)、ソース制御システムなど
ソフトウェア開発の従来のツールやプロセスを利用します。Force.comプラットフォームでは、Salesforce組織の
さまざまなコンポーネントを表すテキストベースのファイルを使用して、プロジェクトべースの開発を行うこ
とができます。これらのファイルは転送が容易で、ソース制御システムで保存およびバージョン管理すること
ができ、従来どおりの開発が行えます。これらのすべてを可能にしているのがメタデータ API です。
Force.com プロジェクトとは、メタデータファイルをまとめて 1 つの集合にしたもので、これにより、ローカル
でファイルの作業を行うことができます。各自のニーズに応じて、1 つのコンポーネントあるいは組織の全コ
ンポーネントを含む Force.com プロジェクトを作成できます。後者の場合は組織からすべてのポータブルコン
ポーネントを取得するため、リリースに時間がかかり、処理が難しくなる可能性があることから、必ずしも最
適な選択肢ではありません。
メモ: メタデータ API は、一度に最大 10,000 個のファイルまたは最大 400 MB をリリースおよび取得できま
す。取得またはリリースがこのいずれかの制限を超える場合は、バッチで実行する必要があります。
プロジェクトを構築する上で良い方法は、何を達成したいのかを考えて、そのコンポーネントのみのプロジェ
クトを作成することです。追加または削除したいコンポーネントがある場合、後からプロジェクトを編集でき
ます。
18
開発ツール
メタデータ API について
メタデータ API について
メタデータ API には豊富で強力なメタデータモデルとアプリケーションプログラミングインターフェース (API)
の 2 つがあり、この 2 つが連動して機能します。メタデータモデルは組織内のコンポーネントを記述します。
たとえば、Salesforce カスタムオブジェクトとその項目は、メタデータ API で提供される XML ファイルの操作で
制御できます。メタデータ API には、メタデータコンポーネントの設定とソースにプログラムでアクセスでき
る、Web サービスメソッドのセットも含まれています。つまり、API では、オブジェクトの作成やリリースな
ど、コンポーネントで可能な処理を記述します。この 2 つを区別するため、メタデータコンポーネントを名
詞、API コールを動詞とみなすことができます。
メタデータ API では、次のことができます。
• メタデータファイルで設定を行う。
• テキストエディタ、IDE、バッチスクリプト、ソース制御システムなどの使い慣れたツールを使用して、メ
タデータファイルのコピー、貼り付け、マージ、操作を行う。
• 2 つの開発組織間、または開発組織と本番組織間で設定の変更を移行する。
• 組織およびアプリケーションメタデータを管理する独自のツールを作成する。
サポート対象/対象外のコンポーネントのリストなどについては、『メタデータ API 開発者ガイド』を参照して
ください。
Force.com 移行ツール
Force.com 移行ツールは、ローカルディレクトリと Salesforce 組織間でメタデータを移動する Java/Ant ベースのコ
マンドラインユーティリティです。Force.com 移行ツールを使用すると、関連がない組織間でメタデータを移行
できるため、その点では変更セットより強力です。Force.com IDEとは異なり、Force.com 移行ツールにはグラフィ
カルユーザインターフェースはありません。コントロールファイルをテキストエディタで編集しコマンドライ
ン引数を使用して、リリースするコンポーネント、サーバアドレス、その他のリリース詳細を選択します。
ほとんどのユーザにとっては、テキストファイルを編集してコマンドラインで引数を指定するより、Force.com
IDE のグラフィカルユーザインターフェースのほうが簡単です。ただし、次のような場合、Force.com 移行ツー
ルは非常に便利です。
• 多数の設定変更を含むテスト環境を入力する必要がある開発プロジェクト。自動化されたスクリプトによ
る変更で、手動入力に比べてはるかに速く行うことができます。
• 組織間でファイルのコンテンツを変更する必要があるリリース。たとえば、ダッシュボードで実行ユーザ
を変更する場合、組織 A から実行ユーザを取得し、変更を加え、組織 B に実行ユーザをリリースすること
ができます。この操作を Force.com IDE で実行しようとすると、リリースウィザードを起動して組織 B にリ
リースする前に、(組織 A には組織 B のそのユーザは存在しないため) IDE により、組織 A に変更内容を保存
し直すように要求されます。Force.com 移行ツールでは、retrieve() および deploy() コマンドを完全に
制御でき、ローカルファイルシステムでファイルを編集および保存しても、それをリリースするまではど
の組織のメタデータも変更されません。
• 複数フェーズのリリースプロセス。一般的な開発プロセスでは、本番組織にリリースする前に、作成、テ
スト、ステージングを繰り返し行う必要があります。コンポーネントの取得とリリースをスクリプト化す
ると、この処理を効率的に行うことができます。
19
開発ツール
データローダ
• 同じパラメータを使用した反復リリース。組織からメタデータを取得し、変更を加え、変更を組織にリリー
スすることができます。この処理を繰り返す必要がある場合、同じリリース対象を再度コールするだけで
済みます。
• 高度な技術者によるステージングから本番組織への移行。スクリプト環境でのリリースを好むユーザにとっ
ては、Force.com 移行ツールのプロセスは使い慣れたものです。
詳細は、『Force.com 移行ツールガイド』を参照してください。
データローダ
データローダは、データを一括でインポートまたはエクスポートするためのクライアントアプリケーションで
す。Salesforce レコードの挿入、更新、削除、またはエクスポートに使用できます。
データのインポート時には、カンマ区切り値 (CSV) ファイルまたはデータベース接続からデータローダの参照、
抽出、および読み込みを実行できます。データのエクスポート時には、CSV ファイルへ出力します。
データローダは、データが含まれない Developer Pro Sandbox などのテスト環境にデータを読み込むのに役立ちま
す。回帰テストでは、リリース間で変更されない、安定したデータのセットを使用することが推奨されます。
このため、データをローカルに保存し、データローダを使用してテスト環境を入力する方法は有益です。デー
20
開発ツール
データローダ
タローダにはコマンドラインインターフェースがあるため、スクリプトによりデータを新しい組織に自動的に
読み込むことができます。
メモ: データローダは、メタデータではなく、データの読み込みに限定されたツールです。オブジェクト
の項目の追加または削除や、設定変更の読み込みはできません。
データのインポートには、インポートウィザードまたはデータローダのいずれかを使用できます。データロー
ダは、オンラインアプリケーションの [設定] メニューからアクセスできる Web ベースのインポートウィザード
を補完します。自分のビジネス上のニーズに最も適合するインポート方法を判断するには、次のガイドライン
を参照してください。
Web ベースのインポートを使用する場合
• 50,000 件未満のレコードを読み込む。
• インポートする必要のあるオブジェクトが、インポートウィザードによってサポートされている。利用で
きるインポートウィザードとそれがサポートするオブジェクトを表示するには、[設定] で [データの管理]
をクリックします。
• 取引先名と取引先部門、取引先責任者のメールアドレス、またはリードのメールアドレスに従ってレコー
ドをアップロードすることにより、重複を防止する。
データローダを使用する場合
• 50,000 ～ 5,000,000 件のレコードを読み込む必要がある。データローダは最大 500 万件のレコードの読み込み
に対応します。500 万件を超えるレコードを読み込む必要がある場合、Salesforceパートナーと連携するか、
App Exchange にアクセスして最適なパートナー製品を使用することをお勧めします。
• インポートウィザードによってまだサポートされていないオブジェクトに読み込む必要がある。
• 夜間インポートなど、定期的なデータ読み込みスケジュールを設定する。
• バックアップ目的でデータをエクスポートする。
データのインポートについての詳細は、Salesforce オンラインヘルプの「インポートの概要」および『データ
ローダガイド』を参照してください。
21
第4章
開発の変更の追跡および同期
リリース管理の課題の 1 つは変更を追跡することです。概念上は簡単そうに聞こえますが、実際には容易では
ないことがあります。本番組織と開発組織の両方で、さらにはメタデータ API で使用できるコンポーネントと
使用できないコンポーネントで同時に変更が行われることがあります。
変更を追跡する最も簡単な方法は、従来の開発ツールを使用して、コードの差分出力、マージ、バージョン管
理を行うことです。ただし、これらのツールは、メタデータ API で使用可能なコンポーネントでしか機能しな
いため、変更を手動で追跡する必要があります。大変な作業のように思われるかもしれませんが、あらゆる環
境の変更を追跡して複製することは、本番組織で変更を上書きすることなく、機能を確実にリリースする唯一
の方法です。Force.comプラットフォームで変更を追跡する最も重要な理由は、いくつかの変更を組織間で手動
で移行する必要のある場合があるためです。
本番組織での変更プロセスの確立
Salesforce Web ユーザインターフェースを使用して本番組織でアプリケーションをすばやく開発およびカスタマ
イズできることは、Force.com プラットフォームの多くの強みの 1 つです。ただし、このように簡単に開発を行
えることにより、エンタープライズアプリケーションの開発で、Sandbox でアプリケーションが開発されてい
るときに本番組織で変更が行われる可能性があります。本番組織へのリリースを確実に成功させるには、本番
組織で行われた変更を開発環境にも同様に反映する必要があります。本番組織から開発環境への変更の移動は
逆の処理のように見えますが、開発環境から本番組織への移行では本番組織で行った変更が上書きされるた
め、これが必要になります。
本番組織で変更が行われた場合、Sandbox の更新を実行して最新の変更を取得できます。ただし、Sandbox の更
新は常に実行可能ではなく (Full Sandbox では 29 日ごとに 1 回の更新に制限)、開発者に必要な権限を付与するた
めのユーザプロファイルや権限セットの変更など、設定の変更が必要な場合があります。
したがって、本番組織と開発環境間の変更を追跡し、本番組織と開発環境の差分をマージするプロセスが必要
になります。このタスクを容易にするため、本番組織で変更プロセスを確立することをお勧めします。変更プ
ロセスでは、本番組織で実行可能な変更の種類、変更可能な状況、および変更の責任者を決定します。導入す
る変更プロセスは、本番組織で必要な変更の種類によって異なります。変更プロセスのベストプラクティスを
最も単純な方法から最も複雑な方法の順に並べたリストを次に示します。
• 本番組織での変更を許可しない — 最も単純かつ厳格な方法です。この方法では、リリースが容易になる代
わりに、設定を簡単に変更できなくなります。このプロセスを選択する場合、すべての開発は Sandbox で行
われます。
• メタデータ API でのコンポーネント変更のみ — 手動による変更の追跡とリリースは、メタデータ API を使用
するよりもはるかに複雑です。本番組織への変更をメタデータ APIからアクセスできるコンポーネントのみ
に制限できる場合、これにより、追跡、マージ、およびリリースが変更されます。
• 設定の変更を 1 人の管理者のみに許可する — 一部の組織では、本番組織でのすべての設定の変更を 1 人の
管理者に割り当てると便利です。これにより、本番組織での変更の追跡、および Sandbox の更新間での開発
環境への変更の反映が容易になります。これはより柔軟な方法で、本番組織での変更とプロジェクトベー
スの開発環境での変更を同時に行うことができます。ただし、この方法は 1 人の管理者がすべての設定の
変更を実行できる規模の組織にのみ適用できます。
22
開発の変更の追跡および同期
手動による変更の追跡
• 本番組織への変更をスケジュール — 本番組織への変更を頻繁に行う必要がある組織では、その変更を開発
環境に移行する時間をスケジュールできます。所有する組織の数に応じて、簡単な移行を頻繁に (毎週など)
実行したり、複雑な移行をより低い頻度 (四半期ごとに 1 回) で実行したりできます。
手動による変更の追跡
メタデータ APIで使用可能なコンポーネントに実施した変更は、デスクトップツールを使用して追跡およびマー
ジできます。Force.com IDE または Force.com 移行ツールを使用する場合は、ファイルをバージョン管理システム
に配置し、バージョン管理システムの組み込み機能を使用して変更を追跡できます。ただし、たいていの IT 組
織ではメタデータ API で表されないコンポーネントに多数の変更を行うため、本番組織と開発組織の両方で変
更を手動で追跡する必要があります。
ここで重要な点は、すべての変更を追跡する方法を備えておくことで、これらの変更を手動で移行する必要が
ある場合は特に重要です。便利なツールの 1 つに変更要求フォームがあります。機能強化を要求するときや変
更を実施するときに毎回ユーザやシステム管理者がこのフォームに記入します。Salesforce内で、変更要求や実
際に行われた変更を記録するカスタムアプリケーションを作成できます。
ヒント: AppExchange には、無料の変更管理アプリケーションなど、こうした処理を管理するためのイン
ストール可能なカスタムアプリケーションが用意されています。
たいていの IT 組織では、変更の追跡にスプレッドシートも使用します。スプレッドシートでは、変更を移行ま
たは追跡するときに、ヘッダーによる並び替え、ピボットテーブルの作成、その他の便利な操作が行えます。
スプレッドシートには、次のような情報を含む、行われたすべての変更をリストします。
• 変更実施者
• 変更を実施した組織
• 日付と時刻
• 変更されたコンポーネント
いつ変更を手動で追跡する必要があるか
• メタデータ API にないコンポーネントに変更が実施された場合。メタデータ API で使用できないコンポーネ
ントへの変更はすべて手動で追跡する必要があります。
• Salesforce Web ユーザインターフェースを使用して変更が実施された場合。コンポーネントをメタデータ API
経由で使用できる場合でも、Web ツールを使用して実施された変更を追跡します。Web ツールとメタデー
タ APIで同時に変更が行われると、多くの場合は連動関係が生じ、リリースの問題の原因になることがよく
あります。念のために、Web インターフェース経由で実施されたすべての変更を手動で追跡することをお
勧めします。
Salesforce Web ユーザインターフェースで実施された変更は、設定変更履歴に記録されます。変更をもらさず追
跡する最適な方法は、設定変更履歴と手動の変更追跡ツールを併用することです。この処理をどのように管理
するかは独自に決めることができますが、設定変更履歴のすべての変更を定期的に (たとえば週に一度) 変更リ
ストに転送することや、設定変更履歴のみを使用して変更リストの変更を照合することをお勧めします。設定
変更履歴の使用についての詳細は、Salesforceオンラインヘルプの「設定の変更の監視」を参照してください。
23
開発の変更の追跡および同期
Force.com 移行ツールを使用した変更の追跡
Force.com 移行ツールを使用した変更の追跡
Force.com 移行ツールは、コンポーネントのバッチ移行などのスクリプトベースのリリースで特に役立ちます。
また、メタデータの変更の差分出力を行うバッチスクリプトを記述する場合も非常に便利です。こうしたスク
リプトにより、スケジュールされた時間で、またはさまざまなコンポーネントのセットで差分出力を実行でき
ます。
1. 比較対象のコンポーネントをリストした package.xml ファイルを作成します。
2. コンポーネントをダウンロードする取得先を作成します。次に例を示します。
<target name="retrieve-production">
<sf:retrieve
username="${sf.username}"
password="${sf.password}"
serverurl="${sf.serverurl}"
retrieveTarget="production"
unpackaged="package.xml" />
3. ファイルの差分出力を行う外部スクリプトを記述します。
4. スクリプトをコールし、結果をファイルに出力する対象を指定します。次に例を示します。
<target name="show-production-differences">
<!-- get metadata from organization -->
<antcall target="retrieve-production"/>
<!-- perl script to find changes -->
<exec executable="/bin/bash">
<arg value-"-c" />
<arg value-"cd production;
svn stat|../showdiffs.perl>../report.txt"/>
</exec>
</target>
メモ: この手順は、プログラムによる差分出力を実行する基本ステップの一例にすぎません。複数のフォ
ルダや package.xml ファイルを定義して、コンポーネントをまとめて取得することも可能です。
24
開発の変更の追跡および同期
Force.com IDE を使用した変更の追跡
Force.com IDE を使用した変更の追跡
Force.com IDEで行われた変更は、Eclipse 内の組み込み機能や他の変更追跡ユーティリティを使用して簡単に追跡
およびマージできます。詳細は、Force.com IDE の [ヘルプ] をクリックしてください。
変更の同期
メタデータ API は、異なる環境間で転送可能なテキストベースのファイルとして Force.com コンポーネントを記
述します。サードパーティのツールを使用して、これらのファイルを保存、バージョン設定し、開発者間およ
び開発環境全体で分割することができます。複数の開発環境、コードブランチ、バージョンなどの概念を導入
すると、アプリケーションの開発ライフサイクルが複雑になります。
これらのすべての変更を同期するのは困難な場合があります。たとえば、1 つの開発 Sandbox を本番組織の既
存のアプリケーションの機能強化専用に使用し、別の開発 Sandbox を新しいアプリケーションに使用するとし
ます。各組織には複数のプロジェクトが存在し、すべてのプロジェクトで同時に変更を加えます。このような
変更をマージするには、同一組織のプロジェクト間での変更の同期と、組織間での変更の統合という 2 つの個
別のプロセスが必要です。
複数の Sandbox の同期
従来のソフトウェア開発とクラウドコンピューティングの基本的な違いは、クラウドコンピューティングでは
コンポーネントの正しい定義が常にサーバにあるという点です。ローカルの Force.com プロジェクトで操作す
るファイルは、サーバ上のオブジェクトを表すものです。同期はプロジェクト間で直接行われるのではなく、
各プロジェクトとサーバ間で行われるため、この区別は重要です。
Force.com IDE を使用すると、[保存] ボタンをクリックするだけで簡単に、変更をホーム組織と同期することが
できます。両方の組織で同時に発生する変更については、同期ツールを使用することで、両方向に上書きした
り、変更をマージしたりできます。ファイルを保存、同期、更新する方法は、Force.com IDE ヘルプを参照して
ください。
25
開発の変更の追跡および同期
開発環境全体での変更の統合
開発環境全体での変更の統合
複数の開発環境がある場合、すべての変更を 1 つの組織にマージする必要があります。また、その組織からリ
リースが行える必要があります。Sandbox が 2 つのみの場合は、Sandbox 間で変更を双方向に比較的簡単に移行
できます。各 Sandbox は、他の組織や本番組織に変更をリリースするために使用できます。
開発環境を追加すると、同期の複雑さが大幅に増します。この場合は、Sandbox 間ではなく、別の統合 Sandbox
組織に変更をマージするほうがずっと簡単です。このようなシナリオでは、開発 Sandbox から統合 Sandbox へ
の移行は一方向のみになります。
26
開発の変更の追跡および同期
開発環境全体での変更の統合
変更セットを使用してコンポーネントを移行する場合、リリース接続を編集して、変更が、定義された統合パ
スに従うようにできます。
27
第5章
リリース管理
Force.com プラットフォームの最も生産的な機能の 1 つが、Web ユーザインターフェースで直接カスタマイズを
実行でき、エンドユーザがただちに利用可能になることです。こうした変更には複雑な開発ツールやプロセス
が必要ありません。リリース管理の点では、ほとんど手間がかかりません。
既存のアプリケーションにユーザインターフェースを新規作成する場合など、込み入ったアップグレードで
は、本番組織のユーザから隔離された状態で開発を行う環境が必要です。開発環境で実施した変更を本番組織
に再統合する場合、開発と同時期に本番組織でも変更が行われた可能性があるため、開発プロセスが一層複雑
になります。こうしたレベルのリリース管理では、さまざまな環境間の変更を追跡して、リリース時にクラッ
シュが生じないようにする必要があります。
すべてのユーザに影響する複雑なアプリケーションでは、複数の開発およびテスト環境が必要になることがあ
ります。こうした長期プロジェクトの場合、開発サイクルが異なる並行プロジェクトが存在するために複雑さ
が増す可能性があり、アプリケーションを本番組織にリリースする前にいくつかの統合が必要になることもあ
ります。多くの場合、これらの開発作業がすべて同時に行われます。このレベルのリリース管理は極めて複雑
で厄介です。
これらの開発プロジェクトが相互に、あるいは IT 部門のプロセスと競合しないようにするにはどのように管理
すればよいでしょうか。さまざまなタイムフレームや本番ライフサイクルはどのように調整すればよいでしょ
うか。そして、機能を本番組織にロールアウトするときに競合が起きないようにするには、環境間で変更をど
のようにマージすればよいでしょうか。これらの疑問の答えは、アプリケーションライフサイクル管理プロセ
スをどのように構築するかによって異なり、そうした未確定の要因をすべて理解しない限り決断を下すことが
できません。
エンタープライズアプリケーションの開発
大規模な組織では多くの場合、複数回にわたってリリースがスケジュールされる複雑な開発プロセスがありま
す。この場合、開発とテストの分離だけではなく、異なるスケジュールのプロジェクトの同期も重要です。こ
の開発シナリオでは、複数の開発環境があり、それらを互いに統合してからステージング領域にマージする必
要があります。トレーニング、本番サポートなどの目的で、他の環境が追加される可能性もあります。組織が
このようなエンタープライズ開発を管理する場合、さまざまな方法があります。次の図は、可能な方法の 1 つ
を表しています。
28
リリース管理
並行開発プロジェクトのスケジュール
異なるリリーススケジュール上の、さまざまな複雑さおよび期間の複数のプロジェクトを管理するには、リ
リース計画と厳格な変更追跡プロセスが必要です。開発チームに分散した開発者とテスターが含まれる場合
も、効果的にコラボレーションするためにそれぞれの変更を同期して統合する必要があります。
並行開発プロジェクトのスケジュール
1 回のリリースですべてのアップグレードが行われる従来のソフトウェア開発とは異なり、オンラインアプリ
ケーションはいつでもアップグレードできます。開発の容易な機能強化であればテストは少なくてすみ、優先
度が高い場合はすぐにエンドユーザにリリースできます。そのため、リリース管理では開発作業のスケジュー
リングが重要なステップになります。IT 組織の場合、これは開発プロジェクトを短期、中期、長期などのカテ
ゴリに分けることを意味します。これらのカテゴリは多くの場合、開発を行う環境、必要なテスト量、新機能
のリリース期限によって定義されます。
29
リリース管理
並行開発プロジェクトのスケジュール
カテゴリは必要な数だけ使用できますが、最初は 3 階層から始めるとよいでしょう。プロジェクト期間の他
に、次のような方法で開発作業をカテゴリ化できます。
開発を行う環境:
• 本番のみ — 機能の開発とテストをすべて本番 Web インターフェースで行える場合、開発サイクルを速め
て、ユーザに早く機能を提供できます。
• メタデータ API コンポーネント — 必要なコンポーネントがすべてメタデータ API で使用できる場合、各環境
の変更を追跡してマージする作業がはるかに容易になります。
• 1 つの Sandbox — 機能を 1 つの Sandbox で開発してすぐに本番組織にリリースできる場合、開発サイクルに
は統合環境やステージング環境は必要ありません。
• 複数の環境 — 開発プロジェクトが複数の Sandbox で行われることがあります。この場合、コード行の統合
がより複雑になります。複雑なプロジェクトによって、単純なプロジェクトのロールアウトが止まらない
ようにします。
開発者の数:
• 1 人 — 1 人の開発者が機能を作成、テスト、およびリリースできる場合、変更のマージの問題やその他の
時間のかかる問題が発生する可能性は非常に低くなります。
• 小規模なチーム — 小規模な開発チームの場合、大規模なプロジェクトを扱いやすい単位に分割すれば、迅
速な開発が可能です。このようなプロジェクトは、開発者 1 人のプロジェクトと簡単に統合でき、すぐに
ロールアウトできます。
30
リリース管理
リリーストレインでのアプリケーションの配信
• 大規模なチーム — 大規模な開発プロジェクトには、大規模な開発チームが必要です。このようなプロジェ
クトには、さまざまなコードブランチで行われた変更の追跡とマージ、受け入れテスト、その他の関連プ
ロセスが必要になり、開発プロセスのスピードが低下する可能性があります。
リリーストレインでのアプリケーションの配信
リリーストレインは、定期的にアプリケーションのアップグレードを配信するためのスケジューリング技法で
す。リリーストレインは予測可能な増分追加であるため、1 つの開発サイクルでリリース可能な量に上限を設
けることで開発プロセスが容易になります。アプリケーションの更新は、Salesforceアップグレードによる影響
を受けるため、Salesforce アップグレードが行われる前にスケジュールをリリースすることをお勧めします。
リリーストレインで複数のアプリケーションを配信する一般的なプロセスは次のようになります。
1. Salesforce アップグレードに近い時期にリリースを予定します。
2. 並行開発プロジェクトをスケジュールします。これにより、新しい機能のリリース時期 (今すぐ、最新のリ
リース、将来のいつか) を決定しやすくなります。
3. 本番組織を変更するためのプロセスを確立します。
4. すべての環境での変更を追跡します。これにより、本番組織に最近配信された機能が、開発環境からリリー
スしたときに上書きされないようにします。
5. 変更を統合して、ステージング環境またはテスト環境にリリースします。
6. 本番組織にリリースします。
Salesforce のアップグレードが配信スケジュールに与える影響
Salesforceを次のバージョンにアップグレードする場合、いくつかの点に留意する必要があります。まず、Sandbox
と本番インスタンスは異なるタイミングでアップグレードされます。つまり、しばらくの間は Sandbox と本番
組織で異なるバージョンの Salesforce が実行されます。インスタンスに応じて、Sandbox は本番組織の前または
後にアップグレードされます。スケジュールは Sandbox のコピー日付によって決定されます。
アップグレードはピーク時以外にスケジュールされ、ユーザに影響することはほとんどありません。ただし、
IT 部門は多くの場合同じ時間帯に独自のバッチプロセスをスケジュールするため、競合を避けることが重要で
す。アップグレードには次の内容が含まれます。
• 新しいロゴ — Salesforceのロゴで、使用中のバージョンをすばやく確認できます。Sandbox は本番組織の前ま
たは後にアップグレードされる可能性があるため、Salesforce リリースの前後で Sandbox ホームページ左上隅
にあるロゴで Sandbox がアップグレードされているかどうかを確認することをお勧めします。
• 新機能 — すべてのリリースには新機能が含まれています。新機能に含まれる新規コンポーネントは、メタ
データ API からアクセスできます。リリースノートを表示するには、[ヘルプ & トレーニング] ウィンドウで
[What's New] リンクをクリックします。
• API バージョンの増分 — API バージョンはリリースごとに増分されます。新機能にアクセスするには、新し
いバージョンの API に接続する必要があります。
• 分散アップグレード — 本番組織と Sandbox 組織はアップグレード期間中に異なるバージョンのプラット
フォームを実行している可能性があるため、新しいコンポーネントや追加メタデータを含むコンポーネン
トのリリースを遅らせる必要がある場合があります。新しいコンポーネントに対応するアップグレードが
31
リリース管理
Salesforce のアップグレードが配信スケジュールに与え
る影響
適用されていない組織に対して、そのコンポーネントが含まれる変更セットをアップロードしようとする
と、リリースは失敗します。
今後のメンテナンススケジュールを表示するには、trust.salesforce.com/trust/status にアクセスし、[メンテナンス
スケジュールを表示] リンクをクリックします。
32
第6章
環境間の変更のマージ
移行とは、あるSalesforce組織から別の組織に、設定の変更を移すことです。開発サイクルの間、開発組織の同
期を維持したり、変更を開発組織から本番組織に移したりするために、移行を何回も行う場合があります。
移行を行うには 2 つの方法 (手動またはメタデータ API 使用) があります。
• 手動移行 — メタデータ API で使用できないコンポーネントへの変更は、各環境で手動で行う必要がありま
す。つまり、本番組織または開発組織ごとにまったく同じ変更を繰り返す必要があります。手動移行は、
細かく変更を追跡することで容易になります。
• メタデータ移行 — メタデータ API で使用可能なコンポーネントは、デスクトップツールまたは変更セット
を使用して移行できます。
移行の典型的な手順は次のとおりです。
1. 最初に移行する必要があるコンポーネントを決めます。手動移行とメタデータ移行の両方を実行する場合、
これは特に重要です。たとえば、カスタムオブジェクトに対するキューを作成する場合、カスタムオブジェ
クトを先に移行する必要があります。
2. 必要な順序でコンポーネントを移行します。
• 変更リストを確認し、手動移行が必要なものがあるか判別します。手動移行が必要な場合、変更の移行
先となる組織にログインし、設定変更を手動で行います。
• サーバから最新のメタデータ変更を取得します。
3. 必要に応じて、コンポーネントのサブセットのみがリリースされるように、Force.com プロジェクトまたは
送信変更セットを変更します。
4. リリースを実施します。
関連トピック:
開発の変更の追跡および同期
変更の手動移行
手動で移行するには、Salesforce ユーザインターフェースから設定の変更を実行する必要があります。たとえ
ば、本番組織で新しい検索設定が必要で、その設定をユーザに公開する前に Sandbox で開発とテストを行うと
します。メタデータ API では検索設定にアクセスできないため、本番組織に検索設定を移行するには、検索設
定を手動で Sandbox に再作成する必要があります。
手動移行を避ける最も簡単な方法は、本番組織ですべての変更を行ってから Sandbox を更新することだと思う
かもしれません。これは可能ですが、Full Sandbox は 29 日ごとに 1 回しか更新できず、さらにその他の重要な考
慮事項もあります。さらに、本番組織で行ったすべての変更は、各開発組織に手動で移行する必要がありま
す。リリースにおいてコンポーネントの連動関係は大きな役割を担うため、本番組織で行った変更によって、
Sandbox で開発したアプリケーションがリリースできなくなる場合もあります。複数の開発組織がある場合、
33
環境間の変更のマージ
メタデータファイルの移行方法
本番組織から Sandbox に何度も手動で変更を移行する必要があります。これらの理由により、Sandbox から本番
組織への変更の手動移行よりも本番組織での開発の方が困難になる場合もあります。
メモ: 本番組織では多数のカスタマイズや機能を開発できますが、これらの変更ではテストは不要で、ト
レーニングはほとんど必要ありません。
手動移行の最適な管理方法は、本番組織での変更プロセスを確立し、手動移行が必要な変更を追跡することで
す。
関連トピック:
本番組織での変更プロセスの確立
メタデータファイルの移行方法
メタデータファイルを使用した組織間での変更の移行には、メタデータ API を使用して両方の環境を操作する
中間ツールが必要です。変更がどのように Sandbox から本番組織へ移行されるかを次の図に示します。
ファイルがクラウドに保存されている場合も、ファイルの移行にはローカルプロジェクトが必要です。これ
は、メタデータ APIが、ソースファイル上で動作する従来のソフトウェア開発ツール (テキストエディタ、差分
出力/マージユーティリティ、バージョン管理システムなど) をサポートするように設計されており、これらの
すべてのツールにローカルファイルシステムが必要なためです。一度 Force.com プロジェクトを作成したら、
本番組織に直接何度でもリリースできます。サーバと同期しない場合、ファイルの取得は必要ありません。
34
環境間の変更のマージ
リリース時間に影響する要因
リリース時間に影響する要因
ローカルディレクトリから Salesforce 組織へのメタデータの移行は、メタデータ API の deploy() メソッドを
コールすることで実行されます。Force.com IDE と Force.com 移行ツールは両方ともこのメソッドを使用するた
め、この 2 つのツールによるリリース時間の差はほとんどありません。deploy() メソッドは非同期型です。
つまり、結果はすぐに返されない可能性があり、結果が返されるまでの時間を決定する要素がいくつかありま
す。
• ファイルの数とサイズ — リリースするファイルが多いほど、リリースにかかる時間は長くなります。ただ
し、ネットワークペイロードが 10 MB を超えることはほとんどないため、通常は未加工ファイルのサイズ
による影響は大きくありません。
• コンポーネントの種類 — 一部のコンポーネントは他のコンポーネントよりも処理に時間がかかります。た
とえば、カスタム項目、カスタム連結オブジェクト、およびプロファイルは、他のコンポーネントよりも
リリースに時間がかかります。
• 処理時間 — データの再計算が必要な変更には、変更されるデータ量に比例して時間がかかります。たとえ
ば、項目のデータ型を変更する場合、その項目を使用するすべてのレコードの変更が必要な場合がありま
す。
• テスト実行 — 本番組織にリリースする場合、Apex テストの数と複雑さがリリース時間に大きく影響しま
す。
• ネットワークとサーバの可用性 — その他の要因ほどリリース時間には影響しません。ただし、勤務時間中
にリリースを待機したり、コンポーネントの使用がロックされたりすることを避けるため、所要時間が長
いリリースはピーク時以外にスケジュールすることをお勧めします。
• ロック — リリース中にユーザが組織で作業している場合、ユーザとリリースの両方に影響する可能性があ
ります。ユーザがコンポーネントからロックアウトされたり、リリースがユーザによるロックの解除を待
機したりする可能性があります。最も時間がかかる処理は、大量のレコードを所有するユーザ (またはユー
ザグループ) の再編成です。たとえば、共有ルールの変更は、3 人のユーザが所有する 100 件のレコードを
別の 6 人のユーザと共有するルールではあまり時間はかかりませんが、特定のロールまたはテリトリー階
層の 1 人のユーザの移動で、そのユーザが 1 ギガバイトのレコードを所有している場合には長い時間がか
かります。ユーザは、次の方法でも大量のレコードを強制的に処理できます。
– ポータルユーザまたは売上予測の影響を受けるユーザを作成
– 共有ルールを作成、変更または削除
– 大量の関連レコードがある場合、ユーザ、ロール、グループ、取引先所有者、またはチームメンバーを
移動または変更
開発状況の監視
メタデータコンポーネントのサイズと複雑さは、リリース時間に影響します。処理中または過去 30 日間で完
了したリリースの状況を追跡するには、[設定] で [リリース状況] または [リリース] > [リリース状況] をクリッ
クします。リリースは、その状況に応じて別個のセクションにリストされます。
[リリース状況] ページでは、現在処理中のリリースを監視したり、どのリリースが実行を待機しているかを確
認したり、完了したリリースの結果を参照したりできます。このページには、すべてのリリース (変更セット
35
環境間の変更のマージ
開発状況の監視
ベースのリリースとメタデータ API ベースのリリース) が表示されます。これには、Force.com IDE および Force.com
移行ツールから開始されたリリースも含まれます。
進行中のリリースとキューにあるリリース
リリースの実行中、[リリース状況] ページには、現在のリリースについてリアルタイムの進行状況が表示され
ます。このページでは、グラフで全体的なリリースの進行状況が視覚的に表現されます。最初のグラフでは、
コンポーネント総数のうちリリースが終了したコンポーネント数と、エラーがあったコンポーネント数が表示
されます。たとえば、次のグラフは、450 コンポーネント中 302 コンポーネントが正常に処理され、45 コンポー
ネントにエラーがあったことを示しています。
すべてのコンポーネントがエラーなしでリリースされると、必要または有効な場合は Apex テストが実行を開
始します。2 つ目のグラフは、Apex テストの総数のうち、実行された数と、返されたエラーの数が表示されま
す。さらに、このグラフには現在実行中のテスト名が表示されます。たとえば、次のグラフでは、合計 120 件
のテストのうち 77 件の実行が完了し、1 件が失敗したことを示しています。
次の情報が現在のリリースについて表示されます。
項目
説明
名前
メタデータ API リリースの追跡に使用される変更セット名または一意の識別子。メタデータ
API リリースの場合、この値は deploy() コールによって返されます。
タイプ
リリースタイプ: [変更セット] または API。
リリース者
リリースを実行しているユーザの名前。
開始時刻
要求がキューに入れられた時間ではなく、リリースが実際に開始された日時。この値は、リ
リース [状況] が [処理中] に設定された時間です。
36
環境間の変更のマージ
開発状況の監視
項目
説明
検証
リリース検証が完了した日時。
現在のリリースにエラーがある場合、[エラーを表示]をクリックするとリリースが終了する前にエラーを表示
できます。
待機中のリリース
複数のリリースを開始できます。一度に実行できるリリースは 1 つのみです。その他のリリースはキューに残
り、現在のリリースの終了後に実行されるまで待機します。キューに入れられたリリースは、実行される順序
で [待機中のリリース] の下に表示されます。
リリース検証
リリース検証は、リリースされるコンポーネントの結果をチェックするためだけに使用されるリリースで、
ロールバックされます。検証では、リリースされたコンポーネントは保存されず、組織にはいかなる変更も行
われません。リリースが検証のみ (「検証」) か、実際のリリース (「リリース」) かは、待機中のリリースの情
報か、[失敗] および [成功] セクションでリリースの [状況] 列を調べることで判定できます。
過去 4 日間に検証が正常に完了し、すべてのテストが十分なコードカバー率で合格した場合、テストを実行す
ることなくこの検証を本番組織にリリースするクイックリリースを実行できます。「クイックリリース」を参
照してください。
リリースのキャンセル
進行中またはキュー内のリリースは、リリースの横にある[キャンセル]をクリックしてキャンセルできます。
リリースが完全にキャンセルされるまで、リリースの状況は Cancel Requested になります。キャンセルさ
れたリリースは、[失敗] セクションにリストされます。
完了したリリース
完了したリリースは、状況に応じて [失敗] または [成功] セクションのいずれかに表示されます。
完了したが失敗したリリースおよびキャンセルされたリリースは、[失敗] セクションに表示されます。これら
のリリースでは、ファイルの欠落、コンポーネントのエラー、テストの失敗、またはリリースのキャンセルに
より、変更は組織にコミットされていません。
正常に完了したリリース、または部分的に成功したリリースは、[成功] セクションに表示されます。部分的に
成功する可能性があるのは、本番以外の組織へのリリースのみです。これらのリリースは、リリースオプショ
ンで rollbackOnError 項目が false に設定され、コンポーネントのサブセットにエラーがあります。部分
的に成功したリリースでは、失敗したコンポーネントはコミットされず、残りのコンポーネントは組織にコ
ミットされています。
リリースの詳細を表示するには、リリースの横にある [詳細を表示] をクリックします。[リリースの詳細] ペー
ジの情報を使用して、エラーを確認し、失敗または部分的に成功したリリースの問題をトラブルシューティン
グします。[リリースの詳細] ページには、リリース中に発生したエラーメッセージ、Apex テストのエラーとス
タック追跡情報、コードカバー率の警告、および時間がかかるテストについての情報が表示されます。リリー
37
環境間の変更のマージ
開発状況の監視
スを成功させるために、[リリースの詳細] ページには、リリースされたコンポーネントの数、および実行され
た Apex テストの数などの情報が表示されます。
リリース状況
[失敗] または [成功] セクションの完了したリリースの [状況] 列には、リリースの種別と状況が表示され、次
の 2 つの部分で構成されます。
• プレフィックスは、リリースが検証のみ (「検証:」) か、実際のリリース (「リリース:」) かを示します。
• 状況値の 2 つ目の部分は、リリースの状況を示します。失敗したリリースでは [失敗] または [キャンセル]、
成功したリリースでは [成功]、部分的に成功したリリースでは [一部成功] が表示されます。
クイックリリース
本番環境へのリリースでは、すべてのApexテストが実行されます。本番組織に多数のApexテストがある場合、
すべてのテストの実行に時間がかかり、リリースが遅延することがあります。本番環境へのリリース時間を短
縮するため、すべてのテストを実行せずにリリースするクイックリリースを行うことができるようになりまし
た。クイックリリースは、変更セットおよびメタデータ API コンポーネントが次の要件を満たす場合に使用で
きます。
• コンポーネントが対象の環境で過去 4 日 (96 時間) 以内に正常に検証されている。
• 検証の一部として、対象組織でのすべての Apex テストに合格している。
• 組織の全体的なコードカバー率が 75% 以上で、Apex トリガのカバー率も同じである。
検証は、リリースされるコンポーネントの結果をチェックするためだけに使用されるリリースで、コンポーネ
ントを組織に保存することはありません。検証により、実際のリリースで受信する可能性のある成功または失
敗のメッセージを確認できます。変更セットまたはメタデータコンポーネントは、API またはForce.com 移行ツー
ルを使用して検証できます。
変更セットを検証する方法についての詳細は、Salesforceヘルプの「変更セットの確認」を参照してください。
Force.com 移行ツールでコンポーネントを検証するには、リリース先の checkOnly オプションを true に設定
します。『Force.com 移行ツールガイド』の「Salesforce 組織への変更のリリース」を参照してください。
ユーザインターフェースまたは API を使用したクイックリリースの実行
クイックリリースを実行するには、まず検証のみのリリースで、リリースする必要があるコンポーネントセッ
トに Apex テストを実行します。検証に成功し、クイックリリースの必要条件を満たした場合は、クイックリ
リースを開始できます。
検証された変更セットおよびメタデータ API コンポーネントは、ユーザインターフェースでクイックリリース
できます。[リリース状況] ページで、検証の横または検証の詳細ページにある [クイックリリース] をクリック
して、最近の検証をリリースします。このボタンは、必要条件を満たしている検証に対してのみ表示されま
す。
38
環境間の変更のマージ
開発状況の監視
または、メタデータ API を使用するか、または Metadata API コンポーネント (変更セットを除く) の Force.com 移行
ツールを使用して、クイックリリースを開始することもできます。メタデータ API の場合、
deployRecentValidation() をコールして検証 ID を渡します。Force.com 移行ツールの場合、
<sf:deployRecentValidation> タスクを使用します。
メモ: クイックリリースは、すべての Apex テストの実行に成功し、コードカバー率要件を満たした最近
の検証に対して有効になります。次の点に注意してください。
• Apex テストは本番環境で実行する必要があるため、条件を満たした検証に対して、クイックリリース
が本番環境でサポートされます。変更セットおよびメタデータ API コンポーネント (Force.com 移行ツー
ルを使用して検証したコンポーネントを含む) の最近の検証をリリースできます。
• 本番以外の環境 (Sandbox) にリリースするときは、Apex テストが不要で、自動的に実行されません。メ
タデータ API (Force.com 移行ツールを含む) を使用する場合は、テストの実行を明示的に有効にする検証
(移行ツールで runAllTests パラメータを使用する場合など) に対してのみ、クイックリリースが
Sandbox でサポートされます。変更セットについては、Sandbox に変更セットのテスト実行を有効にす
るオプションがないため、Sandbox ではクイックリリースがサポートされません。
• クイックリリースまたは通常のリリースのどちらを使用するかに関係なく、検証後にリリースを実行
した場合は、すべての検証がクイックリリースの対象外になります。クイックリリースを行う必要が
ある場合は、対象のコンポーネントセットを再度検証します。
長時間実行されているテストのパフォーマンス調整のリソース
必要または有効な場合、すべてのコンポーネントがリリースされた後に、Apexテストがリリースの一部として
実行されます。Apex テストの実行に長く時間がかかると、リリース全体が遅延します。実行時間が長い上位 5
つのテスト、つまり実行時間が 2 分を超えた上位 5 つのテストに、[リリースの詳細] ページで完了済みリリー
スのフラグが設定されます。効率化して将来のリリース時間を短縮できるように、これらのテストのパフォー
マンスを改善することができます。 パフォーマンス低下の原因は多数存在します。たとえば、テストデータ
を使用せずに組織データにアクセスする場合や、パフォーマンスの低い SOQL クエリや Apex コードを実行する
39
環境間の変更のマージ
リリースの連動関係
場合などが挙げられます。 Apex および SOQL のパフォーマンスのベストプラクティスを学ぶために使用できる
リソースをいくつか紹介します。
• 単体テストの組織データとテストデータの分離
• Working with Very Large SOQL Queries (非常に大きい SOQL クエリの処理)
• Web セミナー: Inside the Force.com Query Optimizer (Web セミナー: Force.com クエリオプティマイザのしくみ) (英語)
• Query and Search Optimization Cheat Sheet (クエリおよび検索最適化のための早見表)
• Performance Tuning for Visualforce and Apex Webinar (Visualforce および Apex のパフォーマンス調整の Web セミナー)
• Architect Core Resources (アーキテクト向けコアリソース)
リリースの連動関係
開発環境間で変更を移行するか、変更を本番組織にリリースするかに関わらず、リリースの成否に影響する要
素が多数あります。最も重要な要素は連動関係です。
次のような、いくつかの種類の連動関係があります。
• 親子 — メタデータコンポーネントが他のコンポーネントと連動する場合があります。たとえば、カスタム
項目はそのカスタムオブジェクトと連動するため、カスタムオブジェクトなしでカスタム項目をリリース
することはできません。このようなオブジェクトの連動関係は常に同じオブジェクト内にあるとは限らず、
異なるオブジェクト間にわたる場合もあります。たとえば、特定のオブジェクトのリレーション項目をリ
リースするには、その対象オブジェクトがリリースに含まれているか、対象組織にすでに存在する必要が
あります。
• 参照ファイル — 別のファイルによって参照されるすべてのファイルは、リリース計画に含まれているか、
対象組織にすでに存在する必要があります。たとえば、静的リソースとして画像を参照する Visualforce ペー
ジがあり、その画像が対象組織に存在しない場合、リリースにその画像を含める必要があります。参照ファ
イルは、メタデータ API からアクセスできる必要があります。たとえば、上記の例の Visualforce ページが個
人用ドキュメントフォルダ内の画像を参照し、リリース計画にすべてのフォルダを含めた場合、個人用ド
キュメントはメタデータ API からはアクセスできないため、リリースは失敗します。
• 順序 — 連動関係がある場合、コンポーネントは 1 回のリリース操作で、かつ特定の順序でリリースする必
要があります。この順序は、メタデータ APIによって自動的に処理されます。ただし、コンポーネントのサ
ブセットをリリースする場合やリリースを複数のバッチに分割する場合は、自分自身で連動関係の順序を
決定する必要があります。
• 必須項目 — Force.com IDEまたはSalesforceユーザインターフェースを使用してオブジェクトを作成する場合、
ツールによって必須項目が作成されます。ただし、ローカルディレクトリでファイルを操作する場合、必
須項目のないメタデータファイルを作成または変更できるため、リリースできない状態になる可能性があ
ります。コンポーネント間でコピーして貼り付けることでも、同様のエラーが発生する可能性があります。
バッチでのファイルの移行
変更を移行する最も簡単な方法は、1 回の操作ですべての変更をリリースすることです。ただし、次のような
場合はリリースを小さいサイズに分割した方が便利です。
40
環境間の変更のマージ
まとめてリリースするファイルの決定
• リリースが大きすぎる — メタデータ API は、一度に最大 10,000 個のファイルまたは最大 400 MB をリリース
および取得できます。
• リリースにかかる時間が長い — リリースにかかる時間が異常に長い場合、リリースを小さいサイズに分割
できます。これにより、長時間処理のロックによるユーザへの影響を軽減できます。
• Apex テスト — テストが必要なコンポーネントとテストが不要なコンポーネントの 2 つのグループにコン
ポーネントを分割すると便利です。これにより、テストが不要なコンポーネントのリリースが高速化され、
ロックされるコンポーネント数が減ります。
まとめてリリースするファイルの決定
リリースを小さいサイズに分割する必要がある場合、同時にリリースすべきコンポーネントを把握することが
重要です。
• テストをトリガしないコンポーネントをリリースする — コンポーネントの中には、不具合を発生させるよ
うなテストを行えないものがあります。このため、こららのコンポーネントは本番組織でテストをトリガ
しません。リリースが次のコンポーネントのみで構成されている場合、テストを実行せずに本番組織にリ
リースできます。
– Visualforce コンポーネント (ApexComponent)
– Visualforce ページ (ApexPage)
– ダッシュボード
– メールテンプレート
– レポート
– Scontrol
– 静的リソース
• 連動コンポーネントは分割しない — メタデータの移行においてファイルの連動関係は大きな役割を担うた
め、連動コンポーネントは別々にしないことが非常に重要です。
• 最も数が多いコンポーネントを個別にリリースする — 次のコンポーネントは数が多くなる可能性があるた
め、その他のコンポーネントとは個別にリリースすることが適切な場合があります。
– メールテンプレート: 個別にリリースできますが、そのテンプレートを使用するコンポーネントより前
にリリースする必要があります。
– ダッシュボード: 個別にリリースできますが、カスタムボタンがレポートにリンクされている場合はレ
ポートより前にリリースする必要があります。
– レポート: 最も多い数のコンポーネントが含まれる可能性があり、その他すべてのコンポーネントの後
に複数のバッチでリリースできます。
Force.com IDE を使用したファイルのバッチリリース
Force.com IDE を使用してコンポーネントをバッチリリースする方法は 2 つあります。プロジェクトコンテンツ
を変更する方法と、Force.comリリースウィザードの使用時にリリースしないコンポーネントを選択解除する方
法です。
41
環境間の変更のマージ
Force.com IDE を使用したファイルのバッチリリース
ファイルをバッチリリースする最も簡単な方法は、新しい Force.com プロジェクトを作成し、[メタデータコン
ポーネントを選択] ダイアログを使用してリリースするコンポーネントのみを選択することです。[メタデータ
コンポーネントを選択] ダイアログは、個々のコンポーネントまたは特定の種類のすべてのコンポーネントを
選択できるグラフィカルなツールです。プロジェクトを作成するときに、このダイアログを使用してプロジェ
クトに含めるコンポーネントを決定しますが、プロジェクトコンテンツは同様の方法でいつでも編集できま
す。
この方法でプロジェクトコンテンツを作成または編集すると、package.xml ファイルがバックグラウンドで
変更されます。このファイルはプロジェクトマニフェストとも呼ばれ、コンポーネントの取得時とリリース時
の両方でプロジェクトの内容を決定します。package.xml ファイルを [エディタ] ペインにドラッグして手動
で編集することもできます。
警告: package.xml ファイルの手動編集は、ダイアログよりも詳細に制御する必要がある場合にのみお
勧めします。package.xml ファイルの編集後に [メタデータコンポーネントを選択] ダイアログを開く
と、行った変更の一部を元に戻すことができます。
リリース計画を制御するもう 1 つの方法は、Force.com リリースウィザードを使用することです。このウィザー
ドでは、プロジェクト内のリリースするコンポーネントと、実行する特定のアクション (追加、削除、上書き、
またはアクションなし) を選択できます。このウィザードを使用するには、Force.com プロジェクトを右クリッ
クし、[Force.com] > [サーバにリリース] を選択します。
42
環境間の変更のマージ
Force.com 移行ツールを使用したファイルのバッチ移行
方法
Force.com 移行ツールを使用したファイルのバッチ移行方法
Force.com 移行ツールを使用する場合、package.xml ファイルの編集にグラフィカルユーザインターフェース
は使用できないため、XML ファイルの形式に精通し、このファイルを手動で編集する必要があります。作成す
る各 package.xml ファイルに含める必要があるコンポーネントを判断するうえで役に立つ、2 つのリリース
対象をコールできます。
• describeMetadata — 組織で有効になっているメタデータ型のリストを返します。この対象は、
package.xml 内のメタデータ型に必要な構文を識別する場合に役立ちます。
• listMetadata — 組織内の個別のメタデータコンポーネントの名前とその他のプロパティ、およびそれぞ
れの追加情報を返します。この対象は、package.xml に特定のコンポーネントを含める場合、または組織
の特定のメタデータ型の概要が必要な場合に役立ちます。たとえば、この対象を使用して組織のすべての
レポート名のリストが返されるようにできます。さらに、この情報を使用して package.xml ファイルを
作成し、移行する特定のレポートが返されるようにすることができます。
これらのリリース対象の使用方法についての詳細は、『Force.com 移行ツールガイド』を参照してください。
43
環境間の変更のマージ
コンポーネントの削除と名前変更
コンポーネントの削除と名前変更
組織間でコンポーネントを移行する操作は更新/挿入と似ています。つまり、既存のコンポーネントに変更を
リリースすることができ、コンポーネントが存在しない場合は作成されます。たとえば、組織 A に foo とい
うコンポーネントがあり、データ型を変更した場合、その変更を組織 B にリリースすると、foo が組織 B に存
在すれば、そのデータ型が変更されます。ただし、foo が組織 B に存在しない場合、コンポーネント全体が作
成されます。
組織 A で、あるコンポーネントの名前を変更し、そのコンポーネントを組織 B にリリースする場合、組織 B で
もそのコンポーネントの名前が変更されるのではなく、組織 B には新しいコンポーネントが作成されます。こ
れは、リリース操作では一致する名前が検索されるためです。その名前のコンポーネントは組織 B に存在しな
いため、新しいコンポーネントが作成されます。たとえば、組織 A で foo の名前を foos に変更し、その変
更を組織 B にリリースする場合、組織 B には foo と foos の 2 つのコンポーネントが存在することになりま
す。
コンポーネントの名前を変更するには、そのコンポーネントを削除してから、新しい名前で再作成する必要が
あります。コンポーネントの削除プロセスは、環境によって異なります。
• 開発環境とテスト環境の場合 — コンポーネントを削除し、新しい名前で再作成してから、テストデータを
再読み込みします。
• 本番環境またはステージング環境の場合 — Salesforce ユーザインターフェースを使用してコンポーネントの
名前を変更します。既存のレコードのデータは保持されます。
プロジェクトマニフェスト (package.xml) はプロジェクトでリリースされる内容を決定しますが、このファ
イルを削除プロセスに使用することはできません。Force.com プロジェクトのファイルを削除するには、プロ
ジェクトマニフェストを作成し、DestructiveChanges.xml という名前にします。このファイルをリリース
に含めると、削除を指定したコンポーネントが対象組織で削除されます。
AppExchange の使用した変更の移行
AppExchange は組織間のメタデータの移動に使用できますが、変更を移行するための効率的な方法ではありま
せん。未管理パッケージでは同じ名前のコンポーネントをインストールできないため、未管理パッケージのコ
ンポーネントは、初期インストールしたら (未管理パッケージを使用して) それ以上変更することはできませ
ん。
もう 1 つのパッケージの種類として、管理パッケージがあります。管理パッケージでは、IT 開発ツールとして
使用するには適切でない制約が追加されます。さらに、未管理パッケージはどの組織でも作成できますが、管
理パッケージを作成するには Developer Edition 組織を使用する必要があります。
メモ: 未管理パッケージは、初期コンポーネントを複数の組織に配布するのに便利です。たとえば、使用
する Apex コアクラスのセットをすべての開発環境で同じにする場合は、そのコアクラスをパッケージ化
して AppExchange で配布できます。ファイルを複数の開発環境に配布する場合、未管理パッケージをこの
ように使用すると便利ですが、配布したファイルをそれ以上変更することはできません。
44
環境間の変更のマージ
本番組織へのリリース
本番組織へのリリース
本番組織にリリースするためのツールおよび処理は、1 つの開発環境から別の開発環境に変更を移行する場合
に似ています。ただし、本番組織へのリリースでは、いくつかの重要な相違点と追加手順があります。本番組
織へのリリース時に行う手順は、その会社の IT 部門のポリシーやリリース内容によって異なるため、本番組織
へのリリースに規定された処理はありません。ただし、リリースのためのベストプラクティスはいくつかあり
ます。
ユーザが組織に変更を加えない時間帯にリリースすることが重要です。また、テストリリースを実行して、本
番組織へのリリースが成功することを確認する必要もあります。これらの操作は通常、メンテナンス中に行い
ます。リリース中はユーザがシステムからロックアウトされるため、ピーク時間外に行うよう事前に計画して
ください。リリースはオールオアナッシングのイベントです。たとえば、本番組織の新しい 1 つの項目がリ
リース組織に存在しないと、リリース全体が失敗します。リリースフェーズで本番組織に変更を加えると、最
終的なリリースが無効になる可能性があるため、リリースが完了するまで変更を加えないことが重要です。
本番組織にリリースする前に、テストリリースを実行できるステージング環境を作成することをお勧めしま
す。通常、ステージング環境はフルコピーの Sandbox であるため、本番組織に可能な限り近い環境です。この
ため、メンテナンス実施期間前ではなく、メンテナンス実施期間中にステージング環境を作成または更新する
必要があります。フルコピーの Sandbox の作成または更新には時間がかかることがあるため、この点を考慮し
てメンテナンス実施期間を決めることが重要です。
ステージング環境へのリリース手順は、1 つの開発組織から別の開発組織に移行するときの手順と同じです。
この手順には、メタデータ API に含まれないコンポーネントや、Salesforce ユーザインターフェースを使用して
開発された機能の手動による移行が含まれます。また、すべてのテストをステージング環境で手動で実行し、
本番組織にリリースする前に、起こりうる問題が発生しないようにしておくこともお勧めします。開発環境で
は Apex テストカバー率は適用されませんが、本番組織では適用されます。
メモ: Force.com プラットフォームでは、本番組織にリリースする前に、コードのうち少なくとも 75% が単
体テストを受ける必要があります。100% のコードをテストすることが理想的です。コードの対象範囲の
制限は、Sandbox または Developer Edition 組織には適用されません。
ステージング環境に正常にリリースしたら、本番組織にリリースする前に、追加の変更をいくつか加える必要
があります。環境の連動関係を開発環境で変更した (本番組織にはない権限を開発者に付与するなど) 場合は、
それらの値を本番組織の値に戻す必要があります。外部サービスとの統合をテストするためにサービスエンド
ポイントを設定した場合は、それも本番組織の値に戻す必要があります。
これで、本番組織へのリリース準備が整いました。まず、ユーザをシステムからロックアウトしてから、本番
組織で メタデータ API テストリリースを実行します。これは「確認のみ」の検証リリースです。つまり、リ
リースが完全にシミュレーションされ、リリースの成功または失敗が返されますが、コンポーネントが実際に
リリースされることはありません。リリースがステージングされた時間 (通常の営業時間内など) と、実際のリ
リースが行われる時間 (週末にユーザがロックアウトされるときなど) との間で時間が経過している場合は、こ
の手順が特に重要です。このテストリリースに成功したら、コンポーネントに応じて メタデータ API または
Web インターフェースを使用して変更をリリースできます。
すべての IT 組織はそれぞれ異なることを念頭に置いてください。次に、エンタープライズアプリケーションを
本番組織にリリースする場合に実行する可能性がある手順の概要を示します。
1. メンテナンス時間を通知します。
2. 本番組織での設定の変更をすべて停止します。
45
環境間の変更のマージ
リリースのスケジュール設定
3. ステージング環境を作成します。
4. 変更をステージング環境に移行します。
5. 環境の連動関係およびサービスをテスト設定から本番組織の値に変更します。
6. ユーザをアプリケーションからロックアウトします。
7. メタデータ API を使用してリリースをテストします。
8. 本番組織にリリースします。
9. 本番組織をロック解除します。
リリースのスケジュール設定
本番環境への変更のリリースはユーザに直接影響するため、新機能のロールアウトに関するガイドラインを設
定しておくことをお勧めします。Salesforce はこの分野で 10 年以上の経験があります。Salesforce モデルのロール
アウト手順を基準にすることができます。
1. 何も破損しないでください。
a. 本番機能をまずテスト環境にリリースします。フルコピーの Sandbox へのリリースおよびテストに成功
したら、本番組織への最終的なリリースが成功すると確信できます。
b. すべてのバックアップを作成します。
c. 万一に備えて代替案を用意します。
2. リリースをスケジュール設定します。
a. ほとんどのユーザが組織を使用できなくなるメンテナンス実施期間を作成し、通知します。
b. プロファイルを使用して、メンテナンス更新を制御します。
3. すべての変更をユーザに通知します。
a. 新機能および既存の動作に加えた変更に関する詳細なリリースノートを作成します。
b. 主要な機能を通知する、リリースノートへのリンクを含めたメールを送信します。
c. ユーザを指導するための Web セミナーおよびトレーニングセッションを作成します。
プロファイルを使用したメンテナンス更新の制御
リリース中は、ユーザプロファイルを使用して、本番組織へのユーザアクセスを制限できます。
1. ほとんどのユーザが組織を使用できなくなるメンテナンス実施期間を作成し、通知します。
• [設定] から [ユーザの管理] > [ユーザの一括メール送信] をクリックし、有効なすべてのユーザにメンテ
ナンス実施期間に関するアラートを送信できる、一括メール送信ウィザードにアクセスします。
2. プロファイルを使用して、メンテナンス実施期間を作成および管理します。
• プロファイルの [ログイン時間帯の制限] を編集して、メンテナンス実施期間の間、ほとんどのユーザを
ロックアウトします。システム管理者または統合ユーザは必要に応じてアクセスできるようにします。
46
環境間の変更のマージ
バグ修正
• ユーザ受け入れテストへのアクセスを一部のユーザに許可する場合は、異なるユーザプロファイルに対
してオブジェクト、タブ、アプリケーションを選択的にロールアウトします。
組織に多くのプロファイルが含まれている場合は、次の方法でメンテナンス実施期間を設定します。
1. ロックアウトするすべてのログイン時間を設定した「Maintenance」という新しいプロファイルを作成しま
す。
2. データローダを使用して、ユーザとそのユーザプロファイルの対応付けを抽出し、保存します。
3. メンテナンス実施期間の開始時に、データローダを使用して、システム管理者を除くすべてのユーザプロ
ファイルを Maintenance プロファイルに変更します。システム管理者のログインアクセスを残しておくこと
は非常に重要です。このようにしないと、すべてのユーザがシステムから無期限にロックアウトされるこ
とになります。メンテナンス実施期間に統合を実行する場合は、統合ユーザもロックアウトされないよう
にする必要があります。
4. メンテナンス実施期間の終了時に、データローダを使用して、ユーザの元のプロファイルを再読み込みし
ます。
バグ修正
バグ修正を行う場所は、バグの重要度と IT 部門の方針によって異なります。一般的には、本番組織で修正する
か、開発環境で修正するかのどちらかです。すべての変更を 1 か所で行い、反復可能なプロセスを使用して変
更を本番組織に移動することをお勧めします。このプロセスの一例を次の図に示します。
このプロセスは、直ちに本番組織に適用する必要がある優先度の高いバグ修正には適さない場合があります。
その場合は、本番組織でバグを修正してから、そのバグ修正を開発環境に移行する必要があります。開発環境
から変更を移行するときに本番組織で行った変更が上書きされてしまうため、これは重要です。このプロセス
の一例を次の図に示します。
47
環境間の変更のマージ
バグ修正
48
第7章
高度な開発ライフサイクルシナリオ
この章では、高度な開発およびリリース管理で推奨される開発ライフサイクルについて説明します。
高度な開発ライフサイクルは、アプリケーションの並行開発が行われる企業や、プログラムによるカスタマイ
ズが行われる企業に適用されます。並行開発が行われるのは、複数の部署の開発者が並行して複数のプロジェ
クトに取り組んでいる場合や、同じチームの複数の開発者が 1 つのアプリケーションの開発タスクを共有して
いる場合です。開発ライフサイクルとは、Salesforce で並行開発が行われ、さまざまな開発者が実施した変更を
統合してテストし、数種の中間環境を経てこれらの変更を本番組織にリリースするプロセスです。
高度な開発ライフサイクルについて説明した後、架空の企業での開発ライフサイクルの使用例を示します。
例: 架空の企業: AW Computing
この章のシナリオでは、AW Computing という架空の企業を使用します。AW Computing は、企業や個人消費
者にオフィスコンピューティング機器を提供する中堅企業です。AW Computing には社内の開発チームがあ
り、開発者 4 名、品質管理技術者 2 名、リリースマネージャとプロダクトマネージャ各 1 名、その他で構
成されています。AW Computing では、外部システム、SAP、エンタープライズリソースプランニングおよ
び業務システムのデータを Salesforce に統合しています。AW Computing の開発チームは、すべての生産物を
ユーザ受け入れテストにかける必要があります。また、AW Computing では、本番組織にリリースする前
に、従業員に正式なトレーニングを実施します。さらに同社では修正パッチを本番組織にすばやくリリー
スする能力も求められます。
AW Computing の担当職務は次のとおりです。
• リースマネージャ — リリーススケジュールの管理およびリリースと業務の調整を担当します。 また、
ソース制御システムの管理も担当します。
• プロダクトマネージャ — アプリケーションや機能のビジネス要件を定め、開発チームと協力してこれ
らの要件を満たします。また、ユーザ受け入れテストを実施して、要件を満たしていることを確認し
ます。
• ソフトウェア開発者 — 本番以外の環境でアプリケーションを記述します。
• 品質管理技術者 — 開発中のアプリケーションのテストを実行します。
• 管理者 — レポートの作成など本番組織の管理タスクを行います。
• トレーニング講師 — 新しいアプリケーションおよび機能について企業の従業員にトレーニングを行い
ます。
ソース制御システムとリリースツール
ソース制御システム
カスタマイズは、Sandbox から中央ソース制御リポジトリに移行されてから、他の環境に移行されます。Git や
Apache Subversion (SVN) などのリポジトリを使用すると、並行開発で実装された変更を統合しやすくなり、異な
るバージョンのアプリケーションを分離できます。
49
高度な開発ライフサイクルシナリオ
ソース制御システムとリリースツール
ソース制御リポジトリには、メタデータ API で公開された、組織全体のメタデータのコピーが含まれます。チー
ムメンバーは、カスタムオブジェクト、項目、レポート、Apex または Visualforce コードなどのカスタマイズを
ソース制御リポジトリに追加できます。これらの変更は、他のチームメンバーや他のチームの開発者が行った
変更とマージされます。ソース制御システムには、開発プロセスの品質確保など、多くのメリットがありま
す。たとえば、特定バージョンのカスタマイズのみをリリースしたり、他のプロジェクトでカスタマイズを上
書きすることなく、プロジェクトごとに別個のブランチを管理したりできます。
Git など、使用するソース制御システムでは、複数のブランチを持つリポジトリを作成できます。各ブランチ
には、別々のチームによって開発された一連の変更が含まれます。たとえば、ある開発者チームは、2 月に本
番リリースされる機能を開発しています。 別のチームは、3 月に本番リリースされる機能を開発しています。
これらのチームには、それぞれ別個の Developer Edition 組織と統合テスト Sandbox が必要です。 また、パッチリ
リースにはバグ修正、つまり、新機能とは異なるカスタマイズメタデータと Apex コードが含まれるため、パッ
チリリース用に別個のブランチを使用します。
Force.com 移行ツールを使用すると、組織のメタデータのコピーを取得し、ソース制御にコミットできます。反
対に、Force.com 移行ツールを使用して、ソース制御に保存したメタデータを組織にリリースできます。
Force.com 移行ツール
Force.com 移行ツールは、Java ベースおよび Ant ベースのコマンドラインユーティリティで、組織からメタデー
タをダウンロードして、ファイルシステムのローカルディレクトリに保存することができます。メタデータを
ローカルディレクトリから別の Salesforce 組織にリリースすることもできます。Force.com 移行ツールを使用する
と、移行を簡単に自動化し、柔軟性を高めることができます。スクリプトを使用してリリースを自動化し、制
御ファイルでリリースオプションを指定できます。さらに、このツールでは、リリースする前にファイル内の
メタデータの内容を変更できます。このガイドで前述した「Force.com 移行ツール」セクションを参照してくだ
さい。
50
高度な開発ライフサイクルシナリオ
開発者ライフサイクルと Sandbox 環境
Force.com IDE
Force.com IDE は、Force.com プラットフォーム上で Apex、Visualforce、およびメタデータコンポーネントを使用し
てアプリケーションを開発するための統合開発環境です。Force.com IDE は、オープンソースの Eclipse プラット
フォームの上位に構築され、プラグインとして使用できます。Apex、Visualforce、およびメタデータコンポーネ
ントは IDE によってローカルファイルシステムに保存されます。開発者はツールを使用してこれらの変更を
ファイルシステムからソース制御リポジトリにコミットできます。IDE からソース制御システムを直接操作で
きる Eclipse プラグインを使用できるため、開発者は迅速かつ容易に変更をコミットできます。このガイドで前
述した「Force.com IDE」を参照してください。
企業例の AW Computing で使用されているツールの概要は次のとおりです。
• ソース制御システム: 企業例では Git を使用していますが、どのソース制御システムでも使用できます。
• Force.com 移行ツール: エンジニアのローカル環境上には通常 Force.com 移行ツールが設定されています。
• 開発用 Force.com IDE
変更セット
変更セットを使用してメタデータコンポーネントを移行できます。変更セットは使いやすさを目的として設計
されていますが、制限があります。たとえば、変更セットに入れることができるのは Salesforce ユーザインター
フェースで行った変更のみで、Force.com IDE による変更は追加できません。また、コンポーネントの名前変更
や削除に変更セットを使用することはできません。移行を自動化してより広範囲のメタデータ移行をサポート
するには、Force.com 移行ツールの使用をお勧めします。
開発者ライフサイクルと Sandbox 環境
開発ライフサイクルの間は、複数のタスクが別々のチームによって実行されます。アプリケーションの開発か
らテスト、リリースに至るまで、タスクは特定のリリースプロセスに従う必要があります。開発およびテスト
タスクには、並行して行われるものもあれば、先に他のリリースが完了してから行われるものもあります。こ
れらのタスク (開発、テスト、統合、ステージング) 用の環境を分けると、チーム開発が可能になり、高品質の
リリースを行うことができます。
開発ライフサイクルで開発環境とテスト環境を別個に用意するには、Sandbox 組織を作成します。Sandbox に
は、組織のメタデータのコピーと、必要に応じてデータのコピーが含まれます。
Sandbox の種別
次の Sandbox 環境を使用できます。各 Sandbox 種別についての詳細は、「開発環境の種別について」を参照し
てください。
• Developer
• Developer Pro
• Partial Copy
• Full
開発とテストには、Developer Sandbox および Developer Pro Sandbox の使用をお勧めします。これらの Sandbox に
データ (標準およびカスタムデータオブジェクト) は含まれていません。Partial Copy Sandbox は通常、統合テスト
51
高度な開発ライフサイクルシナリオ
開発者ライフサイクルと Sandbox 環境
またはユーザ受け入れテスト (UAT) 環境として使用され、メタデータに加えて、組織のデータのサブセットが
含まれています。Full Sandbox は、組織のすべてのデータとメタデータのフルコピーです。Full Sandbox が本番組
織の完全なレプリカであるのに対し、他の Sandbox は部分的なコピーです。
Sandbox データテンプレート
Partial Copy Sandbox および Full Sandbox で Sandbox テンプレートを使用すると、特定のオブジェクトとデータを選
択して Sandbox にコピーできます。Sandbox テンプレートによって、各 Sandbox のサイズとコンテンツを制御で
きます。
プロジェクトチームが複数ある大規模な組織では、Partial Copy Sandbox とデータテンプレートを利用してテスト
作業を分けることができます。たとえば、回帰テストを分割して (Full Sandbox ではなく) 更新サイクルの短い複
数の Sandbox で実行することができます。
機能リリースのための推奨 Sandbox 環境
機能リリースでの、タスク別の推奨 Sandbox 環境を次に示します。
• 開発とテストには、次の Sandbox をお勧めします。
– 開発: 専用 Developer または Developer Pro Sandbox (エンジニア 1 人につき 1 個)
– 共有テスト: 共有 Developer または Developer Pro Sandbox
• 統合テストとユーザ受け入れテスト: 共有 Partial Copy Sandbox
• ステージング変更: Full Sandbox
共有 Sandbox にログインするユーザごとに Sandbox ユーザを作成します。各ユーザが個別のユーザアカウント
を使用して Sandbox にログインします。
専用または共有の Sandbox を使用した開発
各開発者が専用の Sandbox を作成して作業することをお勧めします。開発者ごとに 1 つの Sandbox を用意するこ
とで、各開発者が作業を管理しやすくなります。つまり、いつ Sandbox をリポジトリにある最新の変更で更新
するか、いつ変更をコミットするかを各開発者が決定できます。
チームメンバーが緊密に連携して作業し、主に Salesforce ユーザインターフェースのポイント & クリックツール
を使用している場合は、チームメンバーで 1 つの Sandbox を共有できます。Sandbox は、ユーザごとにユーザア
カウントを作成することで共有できます。Sandbox を共有すると、Sandbox を管理してソース制御と同期するプ
ロセスは容易になりますが、開発プロセスは複雑になります。
次の図は、開発者用とテスト用の Sandbox 環境の位置付けを示しています。この概要図では、任意の人数 (n) の
開発者と QA エンジニアのそれぞれに Sandbox があることを前提としています。
52
高度な開発ライフサイクルシナリオ
開発者ライフサイクルと Sandbox 環境
ユーザ受け入れテスト Sandbox
会社の従業員は、ユーザ受け入れテスト (UAT) Sandbox を使用して新機能を試したり、アドホックテストを実行
したりできます。たとえば、製品マネージャは、アドホックテストを実行して機能が実装されていることを確
認し、デモを準備することができます。また、トレーニング講師は、アプリケーションが本番組織にロールア
ウトされる前に、新しいアプリケーションを使用して正式なトレーニング教材を作成できます。
Partial Copy Sandbox または Full Sandbox は、本番組織のデータを使用したカスタマイズのテストにお勧めします。
Partial Copy Sandbox には、組織のすべてのメタデータと、本番データの一部が含まれており、他方 Full Sandbox に
は本番のメタデータとデータがすべて含まれています。次の図は、前の図への追加として、使用される Partial
Copy Sandbox を示します。
53
高度な開発ライフサイクルシナリオ
開発者ライフサイクルと Sandbox 環境
ステージング Sandbox
ステージング環境は、本番組織の前の、開発ライフサイクルの最後の環境です。ステージング Sandbox は、本
番組織のデータとメタデータがすべて含まれるFull Sandbox です。本番の完全なレプリカであるため、実際の環
境でテストを実行して、アプリケーションの動作に影響を与える、データに依存する問題を見つけることがで
きます。ステージング環境を使用して、テストリリースと最後の回帰テストを実行します。つまり、すべての
テストを実行して、リリースが成功することを確認します。このタスクは、本番環境への検証のみのリリース
に相当します。
メモ: runAllTests パラメータを true に設定して、ステージング Sandbox で Force.com 移行ツールを使
用してテストを実行すると、ローカルテストやインストール済みの管理パッケージからのテストをはじ
めとするすべてのテストが実行されます。それに対し、本番組織で自動的に実行されるテストは、イン
ストール済みの管理パッケージからのものを除く (名前空間のない) ローカルテストのみです。「Force.com
移行ツールを設定してテストを実行する場合のヒント」を参照してください。
また、ステージング環境は、ストレステストとパフォーマンステストにも使用します。Force.com プラットフォー
ムの Sandbox 用ハードウェアは本番組織のハードウェアとは異なるため、Sandbox でのパフォーマンステストが
本番環境と同じにならない可能性があります。それでも、ステージング Sandbox でパフォーマンステストを実
行すると、パフォーマンス上の問題や、Apex ガバナ制限に起因するエラーを見つけるのに役立ちます。
アプリケーションの品質を高めるには、開発プロセスの早期に単体テストを継続して実行することをお勧めし
ます。詳細は、「継続的インテグレーションプロセス」を参照してください。
54
高度な開発ライフサイクルシナリオ
開発者ライフサイクルと Sandbox 環境
メモ: 変更は通常、一方向 (ソース制御システムから本番組織) にのみ移行されます。ただし、本番組織を
手動で変更した場合、それらの変更が次回のリリースで失われないように、変更を複製してソース制御
リポジトリに戻す必要があります。これを行うには、Developer Sandbox でそれらの変更を手動で行い、ソー
ス制御に変更をコミットします。
機能リリースのアプリケーションライフサイクル全体図
次の図には、機能リリースを行う場合のアプリケーション開発ライフサイクルのすべてのフェーズが含まれて
います。
55
高度な開発ライフサイクルシナリオ
パッチリリース
パッチリリース
アプリケーションのリリース後、新しいバージョンをパッチとして転送する必要が生じることがあります。こ
うした変更は、重要なバグ修正ですぐに適用が必要な場合や、より複雑な機能強化の場合などに行われます。
緊急バグ修正 (ホットフィックス) の場合、変更をすぐに本番環境に適用するには、短いリリースサイクルを使
用します。より大規模な変更の場合は、詳細なテストが必要になるため、短いサイクルは適しません。代わり
に、大規模な変更を行うメジャーリリースと同じプロセスを使用することをお勧めします。
56
高度な開発ライフサイクルシナリオ
パッチリリース
メジャーリリースの後、開発チームは通常、新しいバージョンのカスタマイズに着手します。新機能との干渉
や、リリースできない機能とのバグ修正や機能強化の混在を防ぐため、カスタマイズのリリース済みバージョ
ンは、開発チームが作業している新バージョンから隔離する必要があります。そのため、新機能の作業には別
個のソース制御ブランチを使用します。
パッチリリースのライフサイクル
すぐにリリースする必要がある小規模な変更 (ホットフィックス) の場合、本番環境へのクイックパスがある開
発ライフサイクルをお勧めします。 次の Sandbox を使用します。
• 本番環境にある最新の成果物で設定された Developer Sandbox。この Sandbox は、本番サポートに携わる開発
者が使用します。
• Developer Sandbox または Partial Copy Sandbox で構成されるテスト環境
パッチリリースと次回の機能リリースには別個のソース制御ブランチを使用します。
• パッチリリース用の 1 つのブランチ。本番環境に現在リリースされているバージョン (本番バージョン) に
対応します。
• 今後、本番環境にリリース予定の新しいカスタマイズ用の 1 つのブランチ。 このブランチには、パッチリ
リースブランチからの変更も含まれます。
パッチリリースを適用するには、パッチブランチから本番組織へのリリースを実行します。さらに、パッチ変
更をパッチブランチから次回の機能リリースのブランチに統合して、次回のメジャーリリースでこの変更が失
われないようにします。
次の図は、Sandbox とソース制御システムを含む、典型的なパッチ環境を示します。パッチを本番環境にリリー
スする前に、ステージング Sandbox へのテストリリースを実行します。
57
高度な開発ライフサイクルシナリオ
開発ライフサイクルのシナリオ: AW Computing
開発ライフサイクルのシナリオ: AW Computing
AW Computing という架空の企業の一般的な開発およびリリースプロセスを見てみましょう。このプロセスで
は、AW Computing がカスタム Force.com アプリケーションを開発してリリースします。
AW Computing では開発に次のツールを使用します。
• アプリケーションの開発: Force.com IDE
• ソース制御システム: Git および Git リポジトリ (GitHub や Bitbucket など)
• ソース制御からの Sandbox の更新: Force.com 移行ツール
AW Computing の開発チームの技術者には各自の Sandbox があります。
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 リポジトリは各ユーザのローカルにあるため、開発者が行った作業でローカルリポジトリに
コミットされるものは最終的にリモートリポジトリに転送する必要があります。
メモ: このシナリオで説明する Git のワークフローは、ブランチモデルの 1 つのアプローチです。Git では
非常に柔軟にブランチの作業を行うことができます。組織に最も適したブランチモデルを選択してくだ
さい。詳細は、「Git」 の Web サイトを参照してください。
58
高度な開発ライフサイクルシナリオ
開発ライフサイクルのシナリオ: AW Computing
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 リポジトリに転送します。
59
高度な開発ライフサイクルシナリオ
開発ライフサイクルのシナリオ: AW Computing
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 テンプレートを使用して値を入力します。
60
高度な開発ライフサイクルシナリオ
開発ライフサイクルのシナリオ: AW Computing
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
61
高度な開発ライフサイクルシナリオ
継続的インテグレーションプロセス
でパフォーマンステストを実行すると、パフォーマンス上の問題 (本番組織と全く同じでないとして
も) や、Apex ガバナ制限に起因するエラーを見つけるのに役立ちます。
メモ: runAllTests パラメータを true に設定して、ステージング Sandbox で Force.com 移行ツールを使
用してテストを実行すると、ローカルテストやインストール済みの管理パッケージからのテストをはじ
めとするすべてのテストが実行されます。それに対し、本番組織で自動的に実行されるテストは、イン
ストール済みの管理パッケージからのものを除く (名前空間のない) ローカルテストのみです。「Force.com
移行ツールを設定してテストを実行する場合のヒント」を参照してください。
リリースマネージャがリリースを完了し、ステージング Sandbox で正常な結果が得られたら、本番組織へのリ
リースをスケジュールし、スケジュールされた時間に本番組織への最終リリースを実行します。
AW Computing: パッチ環境でバグを修正する
1. アプリケーションが本番組織にリリースされた後、Andrew はDeveloper Sandbox を更新して、本番組織から最
新の変更を取得します。
2. 自身の Developer Sandbox で修正を行い、その変更を Git のパッチブランチにアップロードします。
3. リリースマネージャの Nishi が、Force.com 移行ツールを使用して、Git からステージング Sandbox への検証リ
リースを実行します。
4. Nishi が Git から本番組織へのホットフィックスリリースを実行します。
メモ: パッチブランチに実施されたすべての変更を、定期的に master ブランチにマージして、変更が次
回の機能リリースに取り込まれるようにします。
継続的インテグレーションプロセス
堅牢な品質保証プロセスでは、Jenkins などの継続的インテグレーションプロセスを使用して、ソース制御リポ
ジトリにカスタマイズを追加するたびにテストリリースを実行します。これらのリリースは、継続的インテグ
レーションの専用 Sandbox で実行できます。Apex テストは、各リリースの一環として実行されます。 テストが
有効になるように Force.com 移行ツールを設定します。「Force.com 移行ツールを設定してテストを実行する場
合のヒント」を参照してください。
継続的インテグレーションシステムを使用すると、リリースを自動化できます。たとえば、Jenkins を使用し
て、ユーザ受け入れテスト (UAT) Sandbox へのリリースを自動化することができます。
次の図は、継続的インテグレーションサーバ、Sandbox、ソース制御間の関係を示しています。
62
高度な開発ライフサイクルシナリオ
API でサポートされていないメタデータの処理
API でサポートされていないメタデータの処理
一部のメタデータコンポーネントはメタデータ API でサポートされないため、Force.com 移行ツールなどのツー
ルで移行されません。たとえば、差し込み印刷テンプレートや会計年度はサポートされません。サポートされ
ていないメタデータの完全なリストは、『Force.com メタデータ API 開発者ガイド』の「サポートされていない
メタデータ型」を参照してください。このメタデータは、Sandbox がソース制御の新しいメタデータで更新さ
れるたびに作成する必要があります。また、このメタデータは、Salesforce ユーザインターフェースから手動
で、または自動的に作成できます。メタデータコンポーネントを手動で作成する場合、これらのメタデータの
変更を文書化し、変更のチェックリストを管理して移行を検証することをお勧めします。このメタデータの作
成を自動化するには、Selenium など、ブラウザユーザインターフェースの自動化ツールを使用できます。Selenium
の詳細は、「Selenium Browser Automation」を参照してください。
Force.com 移行ツールの設定
Force.com 移行ツールの一般的な設定タスクのヒントを次に示します。
Git 用に Force.com 移行ツールを設定する場合のヒント
Force.com 移行ツールを Git などのソース制御システムに統合するには、コマンドラインで実行する場合やロー
カルファイルシステムを使用して保存する場合とは異なるように移行ツールを設定する必要があります。
63
高度な開発ライフサイクルシナリオ
Force.com 移行ツールの設定
Force.com 移行ツールを Git に統合すると、このツールで Git の出力を保存したり、リポジトリから Git の入力を
取得したりすることができます。Git 用にこのツールを設定する場合のベストプラクティスを次に示します。
• Git で、package.xml を格納するプロジェクトフォルダ内にソースフォルダ (src) を作成します。
• ツールのサンプルディレクトリから build.properties と build.xml を Git プロジェクトソース (src)
フォルダにコピーします。
• メタデータの取得またはリリースにパッケージ名を使用しないでください。代わりに、パッケージ化され
ていない取得やリリースを使用します。
リモート Git リポジトリを使用する場合のヒント
リモート Git リポジトリの場合は、Force.com 移行ツールを Git リポジトリに統合すれば、Git ブランチのファイ
ルにアクセスできます。 次のスニペットを build.xml に追加します。
<macrodef name="git">
<attribute name="dir" default="" />
<attribute name="branch" default="master" />
<sequential>
<exec executable="git" dir="@{dir}">
<arg value="pull" />
<arg value="origin" />
<arg value="@{branch}" />
</exec>
</sequential>
</macrodef>
<target name="checkoutFromGit">
<echo>Issuing git pull from directory: ${git.dir}</echo>
<echo>Pulling from branch: ${git.branch}</echo>
<git dir="${git.dir}" branch="${git.branch}" />
</target>
64
高度な開発ライフサイクルシナリオ
Force.com 移行ツールの設定
Force.com 移行ツールを設定してテストを実行する場合のヒント
ステージング Sandbox にリリースする場合は、Apex テストを実行することをお勧めします。 デフォルトではテ
ストは必須ではなく、Sandbox で実行されませんが、Force.com 移行ツールのオプションを設定すればテスト実
行を有効にできます。有効にするには、runAllTests="true" 属性を build.xml ファイルのリリース対象
(<sf:deploy> タグ) に追加します。次の例は、runAllTests="true" 属性 (太字) を使用してリリース対象で
テスト実行を有効にする方法を示しています。
<sf:deploy username="${sf.username}" password="${sf.password}" runAllTests="true" … />
上記の対象の例では、ローカルテストだけでなく、インストール済みの管理パッケージのテストも実行されま
す。 これらの管理パッケージ内のテストに合格しない場合は、runAllTests を false に設定してから、Apex
テスト実行コンソールを使用して本番組織にリリースした後テストを実行します。このコンソールにアクセス
するには、[設定] から [開発] > [Apex テスト実行] をクリックします。
すべてのメタデータの package.xml を生成する場合のヒント
Force.com 移行ツールを使用してすべてのメタデータコンポーネントを移行するには、組織のすべてのメタデー
タを参照する package.xml マニフェストファイルを使用する必要があります。このファイルを手動で作成す
る手順を次に示します。
1. Force.com 移行ツールを使用して、コマンド ant describeMetadata を実行します。
このコマンドの出力に、すべてのメタデータコンポーネントと子オブジェクトがリストされます。Force.com
移行ツールでメタデータを取得またはリリースする場合、親オブジェクトに子オブジェクトが含まれるた
め、リストに必要なのは親オブジェクト (XMLName 項目) のみです。
2. 返されたリストから InFolder: true 属性のあるデータ型 (Dashboard、Document、EmailTemplate、Report) を
除外して絞り込みます。
3. 絞り込まれたリストから、各 XMLName 項目の値を package.xml の <types> にネストされた <name> タ
グにコピーして、<members> タグを * 値に関連付けます。たとえば CustomLabels の場合、タグのペアは次
のようになります。
<types>
<members>*</members>
<name>CustomLabels</name>
</types>
次の例は、package.xml の一部分を示しています。package.xml の内容は、組織で使用可能なメタデー
タによって異なります。
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>SampleManifest</fullName>
<types>
65
高度な開発ライフサイクルシナリオ
本番リリースの考慮事項
<members>*</members>
<name>AnalyticSnapshot</name>
</types>
<types>
<members>*</members>
<name>AuthProvider</name>
</types>
<types>
<members>*</members>
<name>CustomLabels</name>
</types>
<types>
<members>*</members>
<name>CustomObject</name>
</types>
. . .
<version>31.0</version>
</Package>
本番リリースの考慮事項
カスタマイズを本番組織にリリースするとき、次の点を考慮します。
• 予定されている Salesforce リリースが自分のリリースに影響を与えないようにする。Salesforce アップグレー
ドに近い時期にリリースをスケジュールします。
• リリースの一環としてテストを実行する。
• Salesforce Sandbox プレビューを予定に入れる。いくつかの Sandbox を Salesforce リリースプレビューの参加対
象として指定することをお勧めします。各メジャーリリースの 1 か月前に、Salesforce は Sandbox インスタン
スのセットをアップグレードします。これらのインスタンス上に存在するすべての Sandbox 組織は、次回の
Salesforce リリースにアクセスできるようになります。これらの Sandbox を使用して回帰テストや新機能の試
行を行います。
66
高度な開発ライフサイクルシナリオ
Sandbox 環境の更新
Sandbox 環境の更新
Sandbox を定期的に更新して、設定情報とデータを最新の状態にすることをお勧めします。ステージング Sandbox
とユーザ受け入れテスト (UAT) Sandbox は、中央ソース制御リポジトリからいつでも更新できます。最新の変更
はすべてソース制御リポジトリに保存され、取得もできるため、本番組織へのリリースが完了して成功するま
で待つ必要はありません。ソース制御からの Sandbox 更新は、継続的な統合プロセスを使用して自動化できま
す。「継続的インテグレーションプロセス」を参照してください。
Sandbox 更新の推奨事項
Sandbox を更新する場合、次の推奨事項に従います。
• ステージング Sandbox 環境は、機能リリース期間が終わるたび、または毎月のどちらか長い方の間隔で更新
します。
• UAT Sandbox 環境は、部分的なデータコピーのデータが最新になるように定期的に更新します。
• Developer Sandbox は必要に応じて更新します。 たとえば、開発者は組織の設定とメタデータのクリーンな
コピーが含まれるように自分の Sandbox を更新し、それをベースにしてカスタマイズを加えることができま
す。
67
用語集
A |B |C |D |E |F |G |H |I |J |K |L |M |N |O |P |Q |R |S |T |U |V |W |X |Y |Z
A
管理者 (システム管理者)
アプリケーションの設定およびカスタマイズができる組織内の 1 人以上のユーザ。システム管理者プロファ
イルに割り当てられているユーザは、管理者権限があります。
Apex
Apex は、開発者が Force.com プラットフォームサーバでフローとトランザクションの制御ステートメントを
Force.comAPIへのコールと組み合わせて実行できるようにした、強く型付けされたオブジェクト指向のプロ
グラミング言語です。Java に似た、データベースのストアドプロシージャのように動作する構文を使用す
るApexにより、開発者は、ボタンクリック、関連レコードの更新、およびVisualforceページなどのほとんど
のシステムイベントにビジネスロジックを追加できます。Apex コードは、Web サービス要求、およびオブ
ジェクトのトリガから開始できます。
App
「アプリケーション」の短縮形です。特定のビジネス要件を扱うタブ、レポート、ダッシュボードおよび
Visualforce ページなどのコンポーネントの集合です。Salesforce では、セールスおよびコールセンターなどの
標準アプリケーションを提供しています。お客様のニーズに合わせてこれらの標準アプリケーションをカ
スタマイズできます。また、アプリケーションをパッケージ化して、カスタム項目、カスタムタブ、カス
タムオブジェクトなどの関連コンポーネントと共にAppExchangeにアップロードできます。そのアプリケー
ションを AppExchange から他の Salesforce ユーザが利用できるようにすることもできます。
アプリケーションメニュー
「Force.com アプリケーションメニュー」を参照してください。
AppExchange
AppExchange は Salesforce の共有インターフェースであり、Force.com プラットフォームのアプリケーションや
サービスを参照および共有できます。
AppExchange のアップグレード
アプリケーションのアップグレードは、新しいバージョンをインストールするプロセスです。
アプリケーションプログラムインターフェース (API)
コンピュータシステム、ライブラリ、またはアプリケーションが、その他のコンピュータプログラムがサー
ビスを要求したりデータを交換したりできる機能を提供するインターフェースです。
承認プロセス
承認プロセスは、Salesforce でレコードを承認する場合に、組織で使用できる自動化されたプロセスです。
承認プロセスでは、承認するレコードの条件と各承認ステップの承認者を指定します。各承認ステップは、
その承認プロセスの対象レコードすべてに適用することも、システム管理者が定義した特定の条件を満た
すレコードのみに適用することもできます。承認プロセスでは、レコードの承認、却下、取り消しまたは
最初の承認申請時に実施するアクションも指定します。
68
用語集
B
該当用語はありません。
C
子リレーション
別の sObject を一対多リレーションの片方として参照する sObject に定義されたリレーション。たとえば、取
引先責任者、商談および行動は取引先との子リレーションがあります。
「sObject」も参照してください。
クラス、Apex
Apexオブジェクトの作成でベースとして使用する一種のテンプレート。他のクラス、ユーザ定義メソッド、
変数、例外型、および static 初期設定化コードで構成されます。多くの場合、Apex クラスは、Java 内のその
対応物に基づいています。
クライアントアプリケーション
Salesforce ユーザインターフェースの外部で実行し、Force.com API または Bulk API のみを使用するアプリケー
ションです。通常、デスクトップまたはモバイルデバイス上で稼動します。これらのアプリケーションは、
プラットフォームをデータソースとして扱い、設計されたツールおよびプラットフォームの開発モデルを
使用します。
クラウドコンピューティング
インターネットをベースにソフトウェアを開発および配布するモデル。サービス (データなど) のテクノロ
ジインフラストラクチャは、インターネット上にホストされます。このため、コンシューマがサービスを
ブラウザやその他のシンクライアントで開発および使用でき、ハードウェアやソフトウェア、メンテナン
スに投資する必要がありません。
コンポーネント、Visualforce
<apex:detail> などの一連のタグを使用して Visualforce ページに追加できます。Visualforce には、多くの標
準コンポーネントが含まれていますが、独自のカスタムコンポーネントを作成することもできます。
コンポーネントの参照、Visualforce
組織で使用できるVisualforceの標準コンポーネントおよびカスタムコンポーネントの説明。Visualforceページ
の開発フッターまたは『Visualforce 開発者ガイド』からコンポーネントライブラリにアクセスできます。
複合アプリケーション
Yahoo! 地図など 1 つ以上の外部 Web サービスとネイティブのプラットフォーム機能を組み合わせるアプリ
ケーション。複合アプリケーションを使用すれば、柔軟性が高まり、他のサービスとのインテグレーショ
ンが可能になります、外部コードの実行と管理が必要になる場合があります。「クライアントアプリケー
ション」 と 「ネイティブアプリケーション」 も参照してください。
コントローラ、Visualforce
Visualforce ページに実行する必要のあるデータおよびビジネスロジックを提供する Apex クラス。Visualforce
ページは、デフォルトですべての標準オブジェクトまたはカスタムオブジェクトに付属する標準コントロー
ラを使用、またはカスタムコントローラを使用できます。
カスタムアプリケーション
「アプリケーション」を参照してください。
69
用語集
カスタムリンク
カスタムリンクとは管理者によって定義された URL。これを使用して、Salesforceデータを外部 Web サイトと
バックエンドのオフィスシステムと統合します。以前は Web リンクと呼ばれていました。
カスタムオブジェクト
組織固有の情報を保存することが可能なカスタムレコード。
カスタムレポートタイプ
「レポートタイプ」を参照してください。
カスタムSコントロール
メモ: Sコントロールは、Visualforce ページに置き換えられました。2010 年 3 月以降、Sコントロールを
作成したことのない組織および新規組織が、Sコントロールを作成できなくなりました。既存の Sコン
トロールには影響がなく、引き続き編集できます。
カスタムリンクで使用するカスタム Web コンテンツ。カスタム Sコントロールには、Java アプレット、Active-X
コントロール、Excel ファイル、カスタム HTML Web フォームなど、ブラウザに表示できるあらゆる種類のコ
ンテンツを入れることができます。
D
ダッシュボード
ダッシュボードでは、ソースレポートから得たデータを、グラフ、ゲージ、テーブル、総計値、または
Visualforce ページなど、視覚化されたコンポーネントとして表示します。コンポーネントは、組織の主要な
総計値のスナップショットおよびパフォーマンスの指標を提供します。各ダッシュボードには、最大 20 個
のコンポーネントを持たせることができます。
データベース
情報の編成されたコレクション。Force.com プラットフォームの基底となるアーキテクチャには、データが
格納されているデータベースが含まれています。
データベーステーブル
追跡する必要のある人物、物事、またはコンセプトに関する情報のリストで、行および列で表示されます。
「オブジェクト」も参照してください。
データローダ
Salesforce 組織からデータをインポートおよびエクスポートするために使用する Force.com プラットフォーム
のツールです。
データ操作言語 (DML)
レコードを挿入、更新、削除する Apex のメソッドまたは操作。
連動項目
対応する制御項目で選択された値に基づいて、使用可能な値が表示される、カスタム選択リストまたは複
数選択リストの項目です。
Salesforce 開発者
Salesforce 開発者 Web サイト (developer.salesforce.com) では、サンプルコード、ツールキット、オンライン開発
者コミュニティなど、プラットフォーム開発者向けの幅広いリソースを提供しています。開発向けのForce.com
プラットフォーム環境も、ここから入手できます。
70
用語集
E
メールアラート
メールアラートは、メールテンプレートを使用してワークフロールールまたは承認プロセスによって生成
され、Salesforce ユーザなど、指定された受信者に送信されるワークフローおよび承認アクションです。
Enterprise WSDL
Salesforce 組織のみでインテグレーションを構築する顧客や、Tibco、webMethods などのツールを使って強い
型キャストが必要なインテグレーションを構築するパートナー向けの強い型付けの WSDL です。Enterprise
WSDL の欠点は、組織のデータモデルに存在するすべての一意のオブジェクトおよび項目にバインドされて
いるため、1 つの Salesforce 組織のスキーマだけを扱うという点です。
F
項目
テキストまたは通貨の値など、情報の特定の部分を保持するオブジェクトの一部。
項目の連動関係
別の項目の値に基づいて、選択リストの内容を変更できるフィルタ。
項目レベルセキュリティ
項目が、ユーザに非表示、表示、参照のみ、または編集可能であるかどうかを決定する設定。Enterprise
Edition、Unlimited Edition、Performance Edition、Developer Edition でのみ使用できます。
フォルダ
フォルダは、レポート、ダッシュボード、ドキュメント、またはメールテンプレートの保管場所です。フォ
ルダは、公開、非表示、または共有にすることができ、「参照のみ」か「参照・更新」に設定できます。
フォルダの内容へのアクセス権を持つユーザの制御は、ロール、権限、公開グループ、またはライセンス
の種類に基づいて行います。フォルダを組織全体で使用できるようにしたり、非公開にして所有者のみに
アクセス権を与えたりすることもできます。
Force.com
クラウドでアプリケーションを構築するための Salesforce プラットフォーム。Force.com は、強力なユーザイ
ンターフェース、オペレーティングシステムおよびデータベースを結合して、企業全体でアプリケーショ
ンをカスタマイズおよび展開できます。
Force.com アプリケーションメニュー
カスタマイズ可能なアプリケーション (別称「アプリケーション」) をワンクリックで切り替えることがで
きるメニュー。Force.com アプリケーションメニューは、ユーザインターフェースの各ページの上部に表示
されます。
Force.com IDE
開発者が Eclipse 開発環境で Force.com アプリケーションを管理、作成、デバッグおよびリリースできる Eclipse
プラグイン。
Force.com 移行ツール
ローカルファイルシステムと Salesforce 組織との間で Force.com コンポーネントを移行する Apache Ant 開発ス
クリプトを作成するためのツールキットです。
71
用語集
Web サービス API
Salesforce組織の情報へのアクセスを提供する Web サービスアプリケーションプログラミングインターフェー
ス。「SOAP API」および「Bulk API」も参照してください。
外部キー
値が別のテーブルの主キーと同じ項目です。外部キーは、別のテーブルの主キーのコピーとしてみなすこ
とができます。2 つのテーブルのリレーションは、あるテーブルの外部キーの値と、別のテーブルの主キー
の値が一致することによって成り立ちます。
G
ガバナ制限
効率性の低いコードを作成する開発者が他の Salesforce ユーザのリソースを独占しないようにする Apex 実行
の制限です。
グループ
一連のユーザのグループ。グループには、各ユーザ、その他のグループ、ロールのユーザが含まれます。
Connect for Outlook または Connect for Lotus Notes を使用する場合、グループを使用してデータへの共有アクセ
スを定義したり、同期するデータを指定したりできます。
ユーザは自分の個人グループを定義できます。管理者は、組織内の全員が使用する公開グループを作成で
きます。
Group Edition
ユーザ数が制限された小規模ビジネスやワークグループに設計された製品。
H
該当用語はありません。
I
インポートウィザード
Salesforce 組織にデータをインポートするツール。[設定] からアクセスできます。
インスタンス
組織のデータをホストし、アプリケーションを実行する単一の論理サーバとして示されるソフトウェアお
よびハードウェアのクラスタです。Force.comプラットフォームは複数のインスタンスで稼動しますが、1 つ
の組織のデータは常に 1 つのインスタンスに保存されています。
インテグレーションユーザ
クライアントアプリケーションまたはインテグレーションのみを対象に定義された Salesforce ユーザです。
また、SOAP API コンテキストではログインユーザとも呼ばれます。
72
用語集
J
連結オブジェクト
2 つの主従関係を持つカスタムオブジェクトです。カスタム連結オブジェクトを使用して、2 つのオブジェ
クト間の「多対多」リレーションをモデル化できます。たとえば、「バグ」という名前のカスタムオブジェ
クトを作成し、1 つのバグを複数のケースに、また 1 つのケースを複数のバグに関連付けることができま
す。
K
該当用語はありません。
L
レイアウト
「ページレイアウト」を参照してください。
レターヘッド
HTML メールテンプレートの基本属性を決定します。ユーザは、背景色、ロゴ、フォントサイズ、フォント
の色などの属性を含むレターヘッドを作成できます。
M
管理パッケージ
ユニットとしてAppExchangeに投稿され、名前空間と、場合によりライセンス管理組織に関連付けられるア
プリケーションコンポーネントの集合です。アップグレードをサポートするには、管理パッケージである
ことが必要です。組織は、他の多くの組織でダウンロードおよびインストールできる単一の管理パッケー
ジを作成できます。管理パッケージは、未管理パッケージとは異なり、コンポーネントの一部がロックさ
れていて、後でアップグレードできます。未管理パッケージには、ロックされたコンポーネントは含まれ
ておらず、アップグレードはできません。また、管理パッケージでは、開発者の知的財産保護のため、登
録している組織では特定のコンポーネント (Apex など) は隠されます。
多対多リレーション
リレーションの両端に多くの子があるリレーション。多対多リレーションは、連結オブジェクトを使用し
て実装されます。
メタデータ
組織および組織のいずれかの部分の構造、外観、機能に関する情報。Force.com では、メタデータを記述す
るのに XML を使用します。
メタデータベースの開発
アプリケーションを宣言的な「設計図」として定義できるアプリケーション開発モデル。コードは必要あ
りません。データモデル、オブジェクト、フォーム、ワークフローなど、プラットフォームに構築された
アプリケーションはメタデータで定義されます。
73
用語集
メタデータ WSDL
Force.com Metadata API コールを使用するユーザの WSDL。
マルチテナンシー
すべてのユーザおよびアプリケーションが単一で共通のインフラストラクチャおよびコードベースを共有
するアプリケーションモデル。
MVC (Model-View-Controller)
アプリケーションをデータを示すコンポーネントに分割する設計パラダイム (モデル)、ユーザインター
フェースでデータを表示する手段 (ビュー)、およびビジネスロジックデータを使用してデータを処理する
手段 (コントローラ)。
N
ネイティブアプリケーション
Force.comの設定 (メタデータ) 定義で排他的に開発されたアプリケーションです。ネイティブアプリケーショ
ンには、外部サービスまたは外部インフラストラクチャは必要ありません。
O
オブジェクト
Salesforce 組織に情報を保存するために使用するオブジェクト。オブジェクトは、保存する情報の種類の全
体的な定義です。たとえば、Case オブジェクトを使用して、顧客からの問い合わせに関する情報を保存で
きます。各オブジェクトについて、組織は、そのデータ型の具体的なインスタンスに関する情報を保存す
る複数のレコードを保有します。たとえば、佐藤次郎さんから寄せられたトレーニングに関する問い合わ
せに関する情報を保存するケースレコードと、山田花子さんから寄せられたコンフィグレーションの問題
に関する情報を保存するケースレコードなどです。
一対多リレーション
1 つのオブジェクトが多数のオブジェクトに関連するリレーション。たとえば、取引先に 1 つまたは複数の
関連取引先責任者がある場合があります。
組織
ライセンスユーザセットが定義された Salesforce のリリース。組織は、Salesforce の各お客様に提供される仮
想スペースです。組織には、すべてのデータおよびアプリケーションが含まれており、他のすべての組織
から独立しています。
組織の共有設定
ユーザが組織で持つデータアクセスのベースラインレベルを指定できる設定。たとえば、オブジェクト権
限によって有効化されている特定のオブジェクトの任意のレコードを参照できますが、編集するには別の
権限が必要となるよう、組織の共有設定を設定できます。
アウトバウンドメッセージ
アウトバウンドメッセージは、外部サービスなどの指定したエンドポイントに指定の情報を送信するワー
クフロー、承認、およびマイルストンアクションです。アウトバウンドメッセージは、Salesforce の設定メ
ニューで設定します。その後で、外部エンドポイントを設定する必要があります。SOAP API を使用して、
メッセージのリスナーを作成できます。
74
用語集
所有者
レコード (取引先責任者またはケースなど) が割り当てられる個別ユーザです。
P
パッケージ
AppExchangeを介して他の組織で使用可能なForce.comのコンポーネントおよびアプリケーションのグループ
です。AppExchangeにまとめてアップロードできるように、パッケージを使用してアプリケーションおよび
関連するコンポーネントをバンドルします。
選択リスト
Salesforce オブジェクトの特定の項目で選択できる選択肢。たとえば、取引先の [業種] 項目など。ユーザ
は、項目に直接入力せずに、選択リストから 1 つの値を選択できます。「マスタ選択リスト」も参照して
ください。
選択リスト (複数選択)
Salesforce オブジェクトの特定の項目で選択できる選択肢のリストです。複数選択リストを使用して 1 つま
たは複数の値を選択できます。ユーザは値をダブルクリックして選択するか、Ctrl キーを押したまま値をク
リックしてスクロールリストから複数の値を選択し、矢印アイコンを使用して選択されたボックスに値を
移動できます。
Platform Edition
セールスやサービス & サポートなどの標準 Salesforce アプリケーションを含まない Enterprise Edition、Unlimited
Edition、または Performance Edition に基づいた Salesforce エディションです。
主キー
リレーショナルデータベースのコンセプトです。リレーショナルデータベースの各テーブルには、データ
値が一意にレコードを識別する項目があります。この項目を、主キーと呼びます。2 つのテーブルのリレー
ションは、あるテーブルの外部キーの値と、別のテーブルの主キーの値が一致することによって成り立ち
ます。
本番組織
実際の本番データとそれらにアクセスするライブユーザを持っている Salesforce 組織です。
プロファイル
Salesforce 内でユーザがさまざまな機能を実行するための権限を定義します。たとえば、ソリューション管
理者プロファイルでは、ソリューションを作成、編集、および削除するためのアクセス権がユーザに付与
されます。
Q
該当用語はありません。
75
用語集
R
参照のみ
ユーザに割り当て可能な標準プロファイルの 1 つ。アクセス権が参照のみのユーザは、組織内での役割に
基づいて、情報を表示し、レポートできます。(つまり、CEO のアクセス権が参照のみの場合は、システム
内の全データを表示できます。アクセス権が参照のみのユーザに西日本営業担当の役割が割り当てられて
いる場合は、自分の役割のデータ、および階層内で自分より下の役割のデータをすべて表示できます)。
レコード
Salesforce オブジェクトの単一インスタンス。たとえば、「John Jones」は取引先責任者レコードの名前とな
ります。
レコードタイプ
レコードタイプとは、そのレコードの標準およびカスタムの選択リスト項目の一部またはすべてを含める
ことができる特定のレコードに使用可能な項目。レコードタイプをプロファイルに関連付けて、含まれて
いる選択リストの値のみがそのプロファイルのユーザに使用できるようにできます。
レコードレベルセキュリティ
データを制御するメソッドで、特定のユーザがオブジェクトを参照および編集でき、ユーザが編集できる
レコードを制限できます。
リレーション
ページレイアウト内の関連リストおよびレポート内の詳細レベルを作成するために使われる、2 つのオブ
ジェクトの間の接続。両方のオブジェクトの特定の項目において一致する値を使用して、関連するデータ
にリンクします。たとえば、あるオブジェクトには会社に関連するデータが保存されていて、別のオブジェ
クトには人に関連するデータが保存されている場合、リレーションを使用すると、その会社で働いている
人を検索できます。
レポート
レポートは、一定の条件を満たすレコードセットを返し、行と列に整理して表示します。レポートデータ
は、条件で絞り込んだり、グループ化したり、グラフなどの図にして表示したりすることができます。レ
ポートはフォルダに保存され、フォルダごとに誰にアクセス権を与えるかを制御します。表形式レポート、
サマリーレポート、マトリックスレポートを参照してください。
レポートタイプ
レポートタイプは、主オブジェクトとその関連オブジェクトとの関係に基づいて、レポートで使用するレ
コードと項目のセットを定義するものです。レポートには、レポートタイプで定義された条件を満たすレ
コードのみが表示されます。Salesforceには、定義済みの標準レポートタイプのセットが用意されています。
管理者がカスタムレポートタイプを作成することもできます。
実行ユーザ
各ダッシュボードには実行ユーザが指定され、そのユーザのセキュリティ設定によってダッシュボードに
表示されるデータが決まります。実行ユーザが特定の 1 ユーザである場合、すべてのダッシュボード閲覧
者には、閲覧者個々人のセキュリティ設定に関係なく、実行ユーザのセキュリティ設定に基づいてデータ
が表示されます。動的ダッシュボードの場合、実行ユーザをログインユーザに設定することができるため、
各ユーザには独自のアクセスレベルに従ってダッシュボードが表示されます。
76
用語集
S
SaaS
「サービスとしてのソフトウェア (SaaS)」を参照してください。
Sコントロール
メモ: Sコントロールは、Visualforce ページに置き換えられました。2010 年 3 月以降、新しい組織同様、
Sコントロールを作成したことのない組織は、Sコントロールを作成できなくなります。既存の Sコント
ロールには影響がなく、引き続き編集できます。
カスタムリンクで使用するカスタム Web コンテンツ。カスタムSコントロールには、Java アプレット、Active-X
コントロール、Excel ファイル、カスタム HTML Web フォームなど、ブラウザに表示できるあらゆる種類のコ
ンテンツを入れることができます。
IdeaExchange
Salesforce ユーザが新しい商品のコンセプトを提案したり、お気に入りの拡張機能を勧めたり、製品マネー
ジャや他のユーザと対話したり、今後のリリースが予定される Salesforce 製品のプレビューを行ったりする
ことができるフォーラム。IdeaExchange ideas.salesforce.com を参照してください。
Salesforce SOA (サービス指向アーキテクチャ)
Apex 内から外部 Web サービスへのコールを実行できる Force.com の強力な機能です。
Sandbox
開発、テストおよびトレーニング用の、Salesforce 本番組織とほぼ同一のコピー。Sandbox のコンテンツとサ
イズは、Sandbox の種別および Sandbox に関連付けられた本番組織のエディションによって異なります。
セッション ID
ユーザが Salesforce に正常にログインした場合に返される認証トークンです。セッション ID を使用すると、
ユーザが Salesforce で別のアクションを実行するときに毎回ログインする必要がなくなります。レコード ID
または Salesforce ID と異なり、Salesforce レコードの一意の ID を示す用語です。
セッションタイムアウト
ログインしてからユーザが自動的にログアウトするまでの時間です。セッションは、前もって決定された
非活動状態の期間の後、自動的に終了します。非活動状態の期間の長さは、[設定] の [セキュリティのコン
トロール] をクリックすることによって Salesforce で設定できます。デフォルト値は 120 分 (2 時間) です。ユー
ザが Web インターフェースでアクションを実行または API コールを実行すると、非活動状態タイマーが 0 に
リセットされます。
設定
システム管理者が組織の設定および Force.com アプリケーションをカスタマイズおよび定義できるメニュー
です。組織のユーザインターフェース設定に応じて、[設定] はユーザインターフェースのヘッダーでリン
クになっている場合もあれば、ユーザ名の下でドロップダウンリストになっている場合もあります。
サイト
Force.com サイトでは、公開 Web サイトとアプリケーションを作成できます。それらは Salesforce 組織と直接
統合されるため、ユーザがログインする場合にユーザ名やパスワードは必要ありません。
SOAP (Simple Object Access Protocol)
XML 符号化データを渡す一定の方法を定義するプロトコルです。
77
用語集
サービスとしてのソフトウェア (SaaS)
ソフトウェアアプリケーションがサービスとしてホストされ、顧客にインターネットを経由して提供され
る配信モデルです。SaaS ベンダは、アプリケーションおよび各顧客データの日常メンテナンス、操作およ
びサポートを行う責任があります。このサービスで、顧客が独自のハードウェア、ソフトウェア、そして
関連 IT リソースを使用してアプリケーションをインストール、構成、保守する必要性を緩和します。SaaS
モデルを使用して、あらゆる市場区分にサービスを配信することができます。
SOQL (Salesforce オブジェクトクエリ言語)
Force.com データベースからデータを選択する条件を指定するために使う、単純で強力なクエリ文字列を構
築できるクエリ言語です。
SOSL (Salesforce オブジェクト検索言語)
Force.com API を使用して、テキストベースの検索を実行できるクエリ言語。
標準オブジェクト
Force.com プラットフォームに含まれる組み込みオブジェクト。アプリケーション独自の情報を格納するカ
スタムオブジェクトを作成することもできます。
システムログ
開発者コンソールの一部。コードスニペットのデバッグに使用できる独立したウィンドウ。ウィンドウの
下部にテストするコードを入力して、[実行] をクリックします。システムログの本文には、実行する行の
長さや、作成されたデータベースコール数などのシステムリソース情報が表示されます。コードが完了し
なかった場合は、コンソールにデバッグ情報が表示されます。
T
Test メソッド
特定のコードが適切に動作しているかを確認する Apex クラスメソッド。Test メソッドは引数を採用せず、
データをデータベースにコミットしません。また、コマンドラインまたは Force.com IDE のような Apex IDE で
runTests() システムメソッドによって実行できます。
トランスレーションワークベンチ
トランスレーションワークベンチを使用して、翻訳する言語を指定し、翻訳者を言語に割り当て、Salesforce
組織に作成したカスタマイズの翻訳を作成し、管理対象パッケージから表示ラベルと翻訳を上書きするこ
とができます。カスタム選択リスト値からカスタム項目にいたるすべてを翻訳し、海外のユーザがSalesforce
のすべてを彼らの言語で使用できるようになりました。
トリガ
データベースの特定の種別のレコードが挿入、更新、または削除される前後で実行する Apex スクリプトで
す。各トリガは、トリガが実行されるレコードへのアクセス権限を提供する一連のコンテキスト変数で実
行し、すべてのトリガは一括モードで実行します。つまり、一度に 1 つずつレコードを処理するのではな
く、複数のレコードを一度に処理します。
78
用語集
U
V
入力規則
指定される基準に一致しない場合、レコードを保存しない規則。
Visualforce
開発者が、プラットフォームに作成されたアプリケーションのカスタムページおよびコンポーネントを容
易に定義できる、単純で、タグベースのマークアップ言語。各タグが、ページのセクション、関連リスト、
または項目など、大まかなコンポーネントときめの細かいコンポーネントのどちらにも対応しています。
コンポーネントの動作は、標準の Salesforce ページと同じロジックを使用して制御することも、開発者が独
自のロジックを Apex で記述されたコントローラと関連付けることもできます。
W
Web サービス
2 つのアプリケーションが、異なるプラットフォームで稼動していたり、異なる言語で作成されていたり、
地理的に離れた場所に存在していたりする場合でも、インターネットを経由してデータを容易に交換でき
るメカニズム。
WebService メソッド
サードパーティのアプリケーションのマッシュアップなど、外部システムによって使用できる Apex クラス
メソッドまたは変数。Web サービスメソッドは、グローバルクラスで定義する必要があります。
ウィザード
1 つの複雑なタスクを行うユーザを複数のステップで誘導するユーザインターフェース。
WSDL (Web Services Description Language) ファイル
Web サービスと送受信するメッセージの形式を説明する XML ファイル。開発環境の SOAP クライアントは、
Salesforce Enterprise WSDL または Partner WSDL を使用して、SOAP API で Salesforce と通信します。
X
XML (拡張可能マークアップ言語)
構造化データの共有と移動を可能にするマークアップ言語。メタデータ APIを使用して取得またはリリース
されるすべての Force.com コンポーネントは、XML 定義に従って表されます。
Y
該当用語はありません。
79
用語集
Z
Zip ファイル
データ圧縮およびアーカイブの形式です。
メタデータ APIによって取得またはリリースされるファイルの集合です。「ローカルプロジェクト」も参照
してください。
80

東北地方太平洋沖地震におけるハートグループの取組み

国際小児保健研究会 ホームページ運用規定

PRE-19-31

DBセキュリティの基礎とガイドライン

レンタルスタジオ Force on Force 高円寺 利用規約 当スタジオは、使用

YKDホールディングス 発足に向け 役員就任

株式会社イトーキ様

概要・資格取得の流れ - SkyVisualEditor

Document

Sandbox からの機能強化のリリース