言いたくないのですが、私が知っている最善のアプローチに落ち着いたようですね。Salesforce のパッケージング環境は、作業するのがまったくの悪夢になる可能性があります。管理パッケージにプレフィックスを付けると、スクリプトを作成しない限り、プレフィックスのないプレーン パッケージに戻ることはできません。そのため、システムが追加するコード全体にパッケージ名が散りばめられていることがわかります。
これを使用する最善の方法は、Ant 内から開発組織にクリーンにインストールされるアプリの「純粋な」バージョンを維持することです。Ant でコードを取得したら、「通常の」ソース管理に追加できます。私が知る限り、ソース コード管理を含むワークフローはあまりサポートされていないため、Salesforce で複数のチーム メンバーを使用して構築された大規模なアプリケーションはそれほど多くないようです。彼らは、開発組織の構成にある種のリリース管理を追加しようとしましたが、これは現在ベータ版ですが、まったくうまくいきませんでした。
私は、Salesforce Force.com 移行ツールを使用する Ant が、ほとんどの場合、進むべき道だと思います。ただし、管理パッケージを作成したい場合は、そのコード ベースが凍結され、その接頭辞が付けられた状態で立ち往生し、パッケージ システム内から (ベータ版などから) パッケージ リリースを行う必要があります。自体。最善の方法は、サンドボックスを更新することです (1 か月に 1 回のハード リミット!!)。その後、開発者にそのサンドボックスから引き出して、個々の開発組織にデプロイしてもらいます。その後、それを定期的に「グループ開発組織」にマージすることができます。サンドボックスに (Force.com IDE または Ant を使用して) デプロイしてから、本番環境にデプロイします。
全体のプロセスは基本的に完全な災害です。Salesforce は非常に強力なプラットフォームを手に入れようとしていますが、多くの場合、ハンドルのない素晴らしいスポーツカーのように感じます.
静的リソースに関しては、Eclipse を使用して比較的簡単な方法で自動化できるはずなので、それらを 1 つのステップで個別にデプロイできます。APIもそれをサポートする必要があります。
私はいくつかのかなり大規模な Apex コードベースに取り組んできました (私はそう思いますし、そう願っています)。場合によっては Ant を使用してデプロイしたり、Eclipse を使用したりするなど、奇妙な組み合わせで立ち往生するでしょう。
他の開発環境から来ると、しばしば混乱し、奇妙になります。たとえば、オブジェクト間の関係を追跡しながらデータベースを 1 ステップで簡単にダンプできず、それを別の組織に 1 ステップで「インポート」できないのは困惑しています。組織でテストする簡単な方法が必要だったため、実際には、オブジェクトの関係をたどりながらすべてのデータを簡単に抽出したり、すべてのデータをロードしたり、xls ファイルからデータを再帰的に削除したりできるツールを作成する必要がありました。
ところで、開発組織は基本的に使い捨て組織です。さまざまなテスト目的で、さまざまなバージョンと構成を維持するために、何十ものそれらを作成します。
良いニュースをお伝えできず申し訳ありません。ここには、パッケージを管理するエレガントな方法を指摘できるグルがもっといるかもしれません。答えと同じくらいあなたに興味があります! 同情したい場合は、suprasphere --- at --- gmail で私にメールを送信できます。:)