現在、いくつかの社内CRMツールを置き換えるためにSalesforceプラットフォームを試しており、既にいくつかのコードを導入しています。私たちのコードベースが成長するにつれて、コード体系については他の人が書いているような痛みを感じ始めています（名前空間/パッケージングなどがない）。私たちはエンタープライズレベルの顧客であり、現行の実験では現在1つの部門のみを対象としていますが、最終的には企業全体に成長することを期待しています。Salesforce導入のベストプラクティス？
ビジネスプロセスが異なる3つの全く異なる営業チームを持ち、異なるコード（SF用語：レコードタイプ、レイアウト、トリガーなど）を持つ組織では、展開を管理するための良い方法は何ですか？ 「パッケージ」はこれに適しているのですか？会社全体が同じSF組織/名前空間内でうまくいくべきでしょうか？
一般的に、皆さんが特定のサンドボックス内でコードと設定を実行していることを確認したいので、すべての異なるパーツが適切に一緒に動作し、望ましくない影響がないことを確認できます。レコードタイプは、特定のレコードに対してトリガーなどの内部で実行するロジックを決定するのに便利なメカニズムです。名前付けスキームと組み合わせることで、すでに存在するものがある場合にコードを配置する場所を知ることができます更新前のアカウントのトリガーは2つ以上のアカウントを維持する方が簡単です。トリガー「Account_BeforeUpdate」を呼び出すと、誰でもそのことを知ることができます。そのため、必要な場合にのみ特定のレコードタイプで動作する既存のトリガーにコードを挿入することができます。
デプロイメントの前に必ず行うべきことのひとつは、サンドボックスの側面に沿ってEclipseの内部でプロダクションプロジェクトをセットアップし、必要なもの（レイアウトなど）をすべて確保することです。差分ツールを使用して、サンドボックスとプロダクションの間にどのような変更が存在しているかを正確に調べることができます。これは非常に貴重な知識です。ただし、ここで気をつけなければならないことは、サンドボックスが削除された後にレイアウトなどが更新されることが多いためです。つまり、配置に関する注意が必要な場合があります。
通常はオブジェクトが最初に移動しますが、APIは非破壊であるため、本番から重要なフィールドを削除しないようにすることができます。
個人的に私は実際にSalesforceの適切なバージョンコントロールを楽しみにしています。複数の開発者が同じエリアで作業している場合は、他の変更を上書きしないようにしていても常に注意する必要がありますいくつかの機会に私たちに起こった。このうちのいくつかは使いたいと思っています！
一般的に、システムを確立しようとする3つのチームがあるため、開発経験を楽しむことはありません。発生する多くの問題に対してそれぞれ異なる回避策が見つかるため、それぞれの開発方法が若干異なります。
トリガーとクラスを名前空間にする方法を見つける必要があります。コードを区切るために各チームのプレフィックスを選択します。
より少ないクラスを使用：従来のOOP（Javaなど）でプログラミングする場合、私は意味のある小さなクラスが好きです。しかしSalesforceでは、クラスを管理するために大きなオーバーヘッドがあります。さらに、すべてのクラス（yuck）に対して1つの大きなフォルダがあります。だから、私は今より大きなクラスファイルを構築します。各ファイルにはテストコードが含まれています。トリガテストコードは、同じオブジェクトで動作するクラス（コントローラなど）に配置します。 Force IDEをCVS、SVN、Mercurial、Gitなどのバージョン管理システムと組み合わせて使用してください。 変更を追跡してコードレビューを実行するには、この方法を使用します。
すべてを含めるようにメインプロダクションプロジェクトを設定します（プロジェクトを右クリック... Force.com ...プロジェクトのプロパティ。環境設定ダイアログでForce.comを展開してプロジェクトの内容を選択します。Add/Removeを押してすべてを追加してください）。私はIDEからのプロダクション変更をこのようにして展開していません。そうすることは良い考えではないかもしれません。しかし、私は頂点クラス、トリガー、およびページを後退させます。各保存の往復は遅いです！ ソース管理システムを使用して変更を文書化し、バージョンを比較します。
サンドボックスからプロダクションへの配備：私はUI配備ツールの使用を断念しました。彼らは単純なもののために働くが、私はそれがより複雑な変更（新しいオブジェクト、タブ、アプリケーション、トリガー、クラス、ページ、レイアウト）を処理することができないことがわかった。私は変更をサンドボックスから作品に移行します。 3チームの場合、最終的な変更を展開する中央チームが必要な場合があります。
システムを分類するには、レコードタイプを含む多くの方法があります。これらは、ハードコードされたSF Idを含むか、文字列を使用してルックアップを実行するコードを必要とします。どちらの場合も、コード全体にこれらの文字列またはIDを配布する必要はありません。あなたがリファクタリングする必要があるときの悪夢を考えてください。代わりに、Globalsクラスを作成し、すべてのハードコーディングされた名前とIDをここに入れます。少なくとも、より合理的な検索と置換を行うことができます。
私はSFが大好きです。いくつかのことは非常に簡単です。しかし、いくつかの開発作業には非常に時間がかかるようです。幸運
興味深いバージョンコントロールを利用すると、いつか試してみてください。 RecordTypesに関しては、変更するべきではない開発者名フィールド、すなわち 'RecordType.DeveloperName'を持っていますが、時にはこれを回避するためにカスタム設定を利用して必要なRecordType名を格納します。 force.comコードでハードコードされたIDを使用しないでください。IDがサンドボックスや本番環境で同じになる可能性は最小限に抑えられます。 –
私は、大きなクラスが行く方法であると感じ始めました。そのことを確認していただきありがとうございます。私はJava + JUnitにも慣れていたので、特に同じファイルにテストを置くのは不便です。 –
私たちが始めている方向を検証するために提案するもの。私はオブジェクトごとに1つのトリガーのアイデアが好きです。非常に特殊なトリガーを作成していましたが、オブジェクト/ドメインごとに1つのトリガーに移動しました（つまり、{OurDepartment} Account_beforeUpdate）。私はあなたの提案がより好きです。 –
複数のトリガーを持つオブジェクトがありますが、DML操作タイプごとに1つずつあります。つまり、例としてContact_BeforeInsert.triggerとContact_AfterUpsertUpdateがあります。 'trigger.isUpdate'のようなものを使って、トリガ内の操作を区別することができます。 –