Deployment Salesforce—如何在环境（沙盒、Live等）之间部署

我们正在研究建立一个适当的部署过程

据我所知，似乎有4种方法可以做到这一点

复制粘贴--我们不想这样做

使用Salesforce Web界面内置的“包”机制

Eclipse强制IDE“部署到服务器”选项

Ant脚本（尚未尝试此脚本）

是否有人对各种方法的局限性提出建议

你能在一个Web界面包中包含所有内容吗

我们希望部署以下项目：

• 顶点类

• 顶点触发器

• 工作流程

• 电子邮件模板

• 邮件合并模板——在Eclipse中似乎找不到这些模板

• 自定义字段

• 页面布局

• 记录类型（在网站或Eclipse中似乎找不到）

• 挑选清单项目

• 控制

我建议您使用

供参考：

---

迁移工具允许您使用ant目标在salesforce.com组织之间移动元数据。

我可以从最近的痛苦经历中得出这样的结论

打包：这是一个非常古老的方法，早于Ant和Eclipse所依赖的元数据API。根据我们的经验，打包的唯一好处是定义您的项目。如果您使用的是Eclipse（我建议您这样做），您可以将您的项目定义为基于特定的包。只要您记得向包中添加新组件，您的项目就可以挂接在一起

顺便说一句，有一件事让我们困惑了一段时间，那就是包装的许多用途。我们注意到以下几点：

已安装的软件包：这些软件包有托管和非托管两种风格，用SFDC板上最近的一篇文章的话来说，它们确实是ISV将自己的东西部署到各种未知的组织中的工具。托管包和非托管包都有一些限制，这些限制使得它们不适合也不需要在组织内从开发部署到生产，或者在任何情况下，如果您正在进行自定义开发，并且不打算将代码分发到大型匿名库中，则不需要它们

未安装的软件包：这是您在web UI中单击“软件包”时看到的内容。这些，我们有时称之为“开发包”，似乎只是将项目定义保持在一起的一种方便方式

无论如何，我的结论是我们的团队（定制开发，而不是ISV）不需要任何形式的包

其他形式的部署（Eclipse和Ant）都依赖于元数据API。从理论上讲，他们能够做完全相同的事情。实际上，它们似乎是互补的。Force.com迁移工具内置于Force.com IDE for Eclipse中，使部署尽可能简单（这不是很简单），并让您可以很好地了解它打算部署什么。另一方面，我们看到Ant做了一些IDE做不到的事情。因此，两者都值得学习

我们倾向于将所有项目保持在SVN中，并使用SVN结构作为项目定义（Eclipse将处理并尊重它）。我们使用Eclipse，有时使用Ant进行迁移。任何地方都不需要包装

顺便说一下，还有一件事需要注意——并非所有组件都是可迁移的。有些东西必须在目标环境中手动重新配置。一个例子是基于时间的工作流。我认为，队列和组也需要表现和创建。同样，元数据API无法直接处理字段删除，因此如果您在源中删除了字段，则需要在目标中手动删除。还有其他情况

希望有用--

---

--Steve Lane

从2009年春季开始，元数据中不支持邮件合并模板，但支持记录类型。您将在文件中找到记录类型作为它们所属对象的XML元素。您列表中的所有其他内容都受支持，只有一个小的例外。无法在2009年春季编辑标准字段的选取列表值。请继续关注09年夏季专题报道的新闻

更新：标准对象上的标准选取列表现在已公开元数据（从API v16开始）：

否则，史蒂夫·莱恩的回答相当准确。使用非托管软件包（Steve称之为未安装的软件包）的优点是，当您向软件包添加元数据时，它所依赖的元数据将自动添加。因此，更容易获取包含其所有依赖项的完整元数据集。如果您反复将元数据从一个组织（沙箱）移动到另一个组织（生产），Steve的方法可能是最好的方法，当然也是当今最常见的方法。我经常使用非托管的“开发人员”包将我在一个组织中开发的东西移动到另一个不相关的组织。出于我的目的，我希望在org中定义包，而不是在Eclipse项目/SVN中定义包。但是，如果您正在跨许多开发人员/沙箱组织进行团队开发，并且已经在使用SVN，那么这可能没有意义

Jesper

来自文档：

必须管理软件包，才能在AppExchange上公开发布，并支持升级。一个组织可以创建一个可由多个不同组织下载和安装的托管包。它们与非托管包的不同之处在于某些组件被锁定，从而允许稍后升级托管包。非托管包不包括锁定的组件，因此无法升级。此外，托管包会混淆订阅组织上的某些组件（如Apex），以保护开发人员的知识产权。

托管软件包的优点在于，它允许您轻松地在多个SFDC组织之间对内容进行版本设置和分发。

另一种选择是，如果您需要