Salesforce-環境間での展開方法（サンドボックス、ライブなど）
適切な導入プロセスの設定を検討しています。
私が読んだことから、これを行うには4つの方法があるようです。
- コピーと貼り付け-これはしたくない
- Salesforce Webインターフェースに組み込まれた「パッケージ」メカニズムの使用
- Eclipse Force IDE "Deploy to Server"オプション
- Antスクリプト（これはまだ試していません）
さまざまな方法の制限についてのアドバイスはありますか？.
Webインターフェイスパッケージにすべてを含めることはできますか？
次のアイテムを展開しようとしています。
Apexクラス
Apexトリガー
ワークフロー
メールテンプレート
MailMergeテンプレート-Eclipseでこれらを見つけることができないようです
カスタムフィールド
ページレイアウト
RecordTypes（WebサイトまたはEclipseでこれらを見つけることができないようです）
PickListアイテム？
SControls
私は最近の辛い経験からこれについて話すことができます。
パッケージング：これは非常に古い方法であり、AntとEclipseの両方が依存するメタデータAPIよりも古いものです。私たちの経験では、パッケージングの唯一の利点はプロジェクトを定義することです。 Eclipseを使用している場合（推奨されます）、プロジェクトを特定のパッケージに基づくものとして定義できます。新しいコンポーネントをパッケージに追加することを忘れない限り、プロジェクトは一緒にハングします
しばらくの間私たちを困惑させたのは、パッケージの多くの使用法です。次のことに注意してください。
インストールされたパッケージ：これらは管理されたフレーバーと管理されていないフレーバーで提供され、SFDCボードの最近の投稿によると、ISVは自分のコンテンツをさまざまな未知の組織に「そこから」展開することができます。マネージパッケージとアンマネージパッケージの両方に制限があり、組織内での開発から本番環境への展開、またはカスタム開発を行っており、大規模な匿名ベースにコードを配布するつもりがない場合には、それらを展開する必要がありません。
インストールされていないパッケージ：これは、Web UIで[パッケージ]をクリックすると表示されます。 「開発パッケージ」と呼ばれることもあるこれらは、プロジェクト定義をまとめて維持するための便利な方法のようです。
とにかく、私が向かっている結論は、私たちのチーム（ISVではなくカスタム開発）はどのような形式のパッケージも必要としないということです。
EclipseとAntの両方の他のデプロイメント形式は、メタデータAPIに依存しています。理論的には、それらはまったく同じことを実行できます。実際には、それらは補完的であるように見えます。 Force.com IDEに組み込まれているForce.com移行ツールを使用すると、デプロイメントを可能な限り簡単に（非常に簡単ではありません）でき、意図したとおりの見栄えになります。一方、AntがIDEでできないことを実行していることを確認しました。そのため、両方を学ぶ価値はあるでしょう。
私たちが頼りにしているプロセスは、すべてのプロジェクトをSVNに保持し、SVN構造をプロジェクト定義として使用することです（Eclipseはこれで動作し、それを尊重します）。また、移行にはEclipseを使用し、時にはAntも使用します。どこにでもパッケージは必要ありません。
ちなみに、もう1つ注意すべき点があります。すべてのコンポーネントが移行可能というわけではありません。ターゲット環境では、いくつかのことを手動で再構成する必要があります。 1つの例は、時間ベースのワークフローです。キューとグループも手作業で作成する必要があると思います。同様に、メタデータAPIはフィールドの削除を直接処理できないため、ソースでフィールドを削除した場合は、ターゲットで手動で削除する必要があります。他のケースもあります。
お役に立てれば幸いです-
-スティーブレーン
Spring '09以降、差し込み印刷テンプレートはメタデータではサポートされていませんが、レコードタイプはサポートされています。レコードタイプは、それらが属するオブジェクトのファイル内のXML要素として見つかります。リストの他のすべては、小さな例外を除いてサポートされています。標準フィールドの選択リスト値は、Spring '09では編集できません。 Summer '09の機能発表に関するニュースをお楽しみに。
更新：標準オブジェクトの標準ピックリストがメタデータとして公開されるようになりました（API v16以降）： http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
それ以外の場合、スティーブレーンの応答はかなり正確です。非管理パッケージ（Steveがインストールされていないパッケージと呼ぶ）を使用する利点は、パッケージにメタデータを追加すると、依存するメタデータが自動的に追加されることです。したがって、すべての依存関係を含むメタデータの完全なセットを取得する方が簡単です。メタデータを1つの組織（サンドボックス）から別の組織（サンドボックス）に繰り返し移動する場合、スティーブのアプローチがおそらく最善の方法であり、今日最も一般的です。私は頻繁に管理されていない「開発者」パッケージを使用して、ある組織で開発したものを別の無関係な組織に移動します。私の目的のために、私はEclipseプロジェクト/ SVNではなく、組織でパッケージを定義するのが好きです。しかし、多くの開発/サンドボックス組織にわたってチーム開発を行っており、すでにSVNを使用している場合は、おそらくそれは意味をなさないでしょう。
ジェスパー
もう1つのオプションは、メタデータをサンドボックスから本番環境に移動する場合、 変更セット を使用することです。
現在、変更セットの使用方法にはいくつかの制限があります。
2つの組織間で変更セットを送信するには、デプロイメント接続が必要です。現在、変更セットは、本番組織とサンドボックス、または同じ組織から作成された2つのサンドボックスなど、本番組織に関連する組織間でのみ送信できます。
私はまだこれを自分で苦労しています。移行ツールのIDE=でも、私が直面する主な問題は次のように解決されていません。
インストールされたパッケージは、開発者組織にデプロイできません。 Dev Orgに1つずつ手動でインストールする必要があります。
パッケージが組織にインストールできない場合（たとえば、 Marketo Sales Insight のようにパスワードが必要なため、または Salesforce for Google Adwords のように廃止されたため）およびアプリケーションがそれに依存している（パッケージに属するオブジェクトのフィールドへの参照など）場合、アプリケーションをデプロイできません。
回避策：パッケージをDEv組織に手動でインストールできない場合、各開発者は独自の開発者サンドボックスを必要とします。追加の開発者サンドボックスは、Salesforceから注文できます。 （ただし、クライアントは喜んでそれらを支払う必要があります...）
サンドボックスが本番環境から更新され、サーバーからローカルプロジェクト（SVNに接続されている）を更新すると、古いサンドボックスですが、本番環境ではありませんが、新しいサンドボックスに移動されます。
回避策：本番環境で行われたすべての変更は、サンドボックスと開発者組織に複製する必要があります。 （痛みのような、でも大丈夫...）
ドキュメントから：
パッケージがAppExchangeで公開され、アップグレードをサポートするためには、パッケージを管理する必要があります。組織は、多くの異なる組織がダウンロードしてインストールできる単一の管理パッケージを作成できます。一部のコンポーネントがロックされ、管理パッケージを後でアップグレードできるという点で、非管理パッケージとは異なります。管理されていないパッケージには、ロックされたコンポーネントが含まれていないため、アップグレードできません。さらに、管理パッケージは、開発者の知的財産を保護するために、購読組織の特定のコンポーネント（Apexなど）を難読化します。
管理パッケージの利点は、複数のSFDC組織に簡単にバージョンを付けて配布できることです。