適切な導入プロセスの設定を検討しています。
私が読んだことから、これを行うには4つの方法があるようです。
誰かがさまざまな方法の制限についてアドバイスを持っていますか？
Webインターフェイスパッケージにすべてを含めることはできますか？
次のアイテムの展開を検討しています。
アペックスクラス
Apexトリガー
ワークフロー
メールテンプレート
MailMergeテンプレート-Eclipseでこれらを見つけることができないようです
カスタムフィールド
ページレイアウト
RecordTypes（WebサイトまたはEclipseでこれらを見つけることができないようです）
PickListアイテム？
SControls
これは、最近のつらい経験から言えます。
パッケージ化: これは、Ant と Eclipse の両方が依存しているメタデータ API よりも前の非常に古い方法です。私たちの経験では、パッケージ化の唯一の利点は、プロジェクトを定義することです。Eclipse を使用している場合 (私たちも使用しており、推奨しています)、プロジェクトを特定のパッケージに基づくものとして定義できます。パッケージに新しいコンポーネントを追加することを覚えている限り、プロジェクトはハングアップします
ところで、しばらくの間私たちを当惑させたのは、package の多くの用途です。次の点に注意してください。
インストール済みパッケージ: これらは管理対象および管理対象外のフレーバーで提供され、実際には、SFDC ボードの最近の投稿によると、ISV がさまざまな未知の組織に「そこにある」ものをデプロイするためのものです。管理パッケージと未管理パッケージの両方に制限があるため、組織内での開発から本番への展開には不適切であり、必要がありません。また、カスタム開発を行っていて、大規模な匿名ベースにコードを配布するつもりがない場合にも使用できません。
インストールされていないパッケージ: これは、Web UI で [パッケージ] をクリックしたときに表示されるものです。私たちが「開発パッケージ」と呼ぶこともあるこれらは、プロジェクト定義をまとめる便利な方法のようです。
とにかく、私が目指している結論は、私たちのチーム (ISV ではなくカスタム開発) は、いかなる形式のパッケージも必要としないということです。
Eclipse と Ant の両方の他の形式のデプロイメントは、Metadata API に依存しています。理論的には、それらはまったく同じことができます。実際には、それらは補完的であるように見えます。Eclipse 用の 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 Lane の応答はかなり正確です。非管理パッケージ (Steve が非インストール パッケージと呼んでいるもの) を使用する利点は、パッケージにメタデータを追加すると、パッケージが依存するメタデータが自動的に追加されることです。そのため、すべての依存関係を含むメタデータの完全なセットを簡単に取得できます。メタデータを 1 つの組織 (サンドボックス) から別の組織 (本番) に繰り返し移動する場合、Steve のアプローチはおそらく最良の方法であり、今日最も一般的であることは間違いありません。管理されていない「開発者」パッケージを頻繁に使用して、ある組織で開発したものを別の無関係な組織に移動します。私の目的のために、Eclipse プロジェクト/SVN とは対照的に、パッケージを組織で定義するのが好きです。しかし、それはおそらくそうではありません'
ジェスパー
もう 1 つのオプションは、サンドボックスから本番環境にメタデータを移動する場合に、変更セットを使用することです。
現在、変更セットの使用方法にはいくつかの制限があります。
2 つの組織間で変更セットを送信するには、展開接続が必要です。現在、変更セットは、本番組織と提携している組織間でのみ送信できます (本番組織と Sandbox、または同じ組織から作成された 2 つの Sandbox など)。
ドキュメントから：
パッケージを AppExchange で公開して公開し、アップグレードをサポートするには、パッケージを管理する必要があります。組織は、多くの異なる組織がダウンロードしてインストールできる単一の管理パッケージを作成できます。一部のコンポーネントがロックされているため、後で管理パッケージをアップグレードできるという点で、未管理パッケージとは異なります。未管理パッケージにはロックされたコンポーネントが含まれず、アップグレードできません。さらに、管理パッケージは、開発者の知的財産を保護するために、登録組織の特定のコンポーネント (Apex など) を難読化します。
管理パッケージの利点は、複数の SFDC 組織間で簡単にバージョン管理および配布できることです。
私はまだこれに苦労しています。移行ツールの IDE も、私が直面している主な問題を解決していません。
インストールされたパッケージは、開発者組織にデプロイできません。Dev Org に 1 つずつ手動でインストールする必要があります。
パッケージを組織にインストールできず (たとえば、 Marketo Sales Insightのようにパスワードが必要なため、またはSalesforce for Google Adwordsのように廃止されたため )、アプリケーションに依存関係がある (オブジェクト内のフィールドへの参照など)。パッケージに属している) 場合、アプリをデプロイできません。
回避策: パッケージを DEv 組織に手動でインストールできない場合、各開発者には独自の開発者サンドボックスが必要になります。追加の Developer Sandbox は、Salesforce から注文できます。（ただし、クライアントは喜んでそれらを支払う必要があります...）
サンドボックスが本番環境から更新され、サーバーからローカル プロジェクト(SVN に接続されている) を更新すると、古いサンドボックスにあったが本番環境にないすべての追加ファイル/コードが新しいサンドボックスに移動されます。
回避策: 本番環境で行われたすべての変更は、サンドボックスと開発者組織に複製する必要があります。(ちょっと痛いけど大丈夫…)
すべての Salesforce 本番デプロイメントでは、メタデータ API はそれを実行するための優れたオプションの 1 つです。作業を簡素化するツールがあります。この投稿をチェックしてください: https://www.deploypkg.com/deploy-to-production/