Salesforce 应用生命周期管理

应用程序生命周期管理

一个Salesforce系统可以有多个版本，最常见的有：

• production版本：终端用户实际使用的版本
• sandbox版本：沙盒环境，用于开发、测试等

在对Salesforce系统的功能持续开发的过程中，有些功能可以直接在production版本中直接更新，比如增减报表、建立视图等，不用担心对整个系统造成潜在的风险。而有些功能或应用程序则必须通过复杂的步骤来实现，比如增减自定义对象、字段、添加Apex类等。这些功能在开发之后必须经过详细的测试，并且如果没有对用户进行合适的培训，新的功能可能造成用户的误解，从而对系统造成潜在的风险。

对于Salesforce应用程序生命周期合理的管理，有助于将风险减小至最低，这一点在商业逻辑复杂的大企业系统的开发中尤其重要。

应用程序生命周期

一个应用程序的生命周期大体可以分为以下几部分：

1. 计划：在开发之前对于需求进行详细的规划设计
2. 开发：开发相应的应用程序或功能，最好使用sandbox版本进行
3. 测试：测试开发出的功能，将问题反馈给开发者进行修复，最好使用sandbox版本进行
4. 部署：当开发的应用程序或功能经过完整的测试之后，可以部署上线，比如从sandbox版本部署到production版本中，供终端用户使用

大型开发环境的构建

对于大型开发环境，需要多个开发者共同开发，每一个开发者都有自己的sandbox开发环境。

当开发者完成功能后，可以通过版本控制软件将功能整合到质量管理的sandbox环境中。

开发者的功能整合后，可以上传到用户测试的环境中。

当测试通过后，可以上传到真正的production环境中。

沙盒的类型

沙盒（sandbox）可以看作是production环境的一个拷贝，供开发和测试使用。沙盒可以刷新，即从production中重新拷贝一次，得到最新的系统和数据，而此前在沙盒中的任何更改都将丢失。

沙盒分为多种类型：

• Developer：只包含系统的设置，不包含数据库。开发者可以在其中添加或载入不多于200MB的数据用于开发和测试。每天可以刷新一次。
• Developer Pro：和Developer类似，不过可存储的数据量达到了1GB。每天可以刷新一次。
• Partial Copy：是一种特殊的Developer类型的沙盒，可以在其中预定义一些存在于production环境中的数据作为样例数据。在预定义样例数据时，只能选择哪些类型的对象会存在样例数据中，无法选择具体的记录。可存储的数据量是5GB，每个对象可容纳的样例数据最多10000条记录。每5天可以刷新一次。
• Full：从production环境的完全拷贝，系统功能、设置、数据都完全一样。每29天可以刷新一次。

在production环境中的设置界面，可以设置此系统的沙盒。

当沙盒被创建成功之后，其中的用户的登录名会在后面加上“.沙盒名”。比如一个用户在production环境中的用户名是“user1@test.com”，那么在一个名为“dev”的沙盒中，其用户名变为“user1@test.com.dev”。其密码不变。

同样的对象记录可以从production环境被拷贝到沙盒中，但是要注意：它们的ID已经改变了。所以在代码或其他地方要读取某记录时，要尽量避免使用写死的ID值，而要使用其他方法来查询、读取。

更改集（Change Sets）

如果要将设置的改变从一个系统拷贝到另一个系统，可以使用更改集。

关于更改集：

• 更改集只包括能从“设置”界面中做出的更改，而非所有的更改。
• 在两个系统间发送和接收更改集需要它们拥有“部署链接”（Deployment Connection）。
• 在两个系统间发送和接收更改集需要它们使用更改集的权限。
• 使用更改集的两个系统必须从属于同一个production环境，比如同一个production环境下的不同沙盒系统，或者某沙盒和production环境。

改变部署的最佳实践

当开发者在开发用的沙盒中完成了功能的开发和其他设置之后，就需要将这些改变部署在生产环境中。

在这个过程中，有以下几点最佳实践：

• 不允许在生产环境中进行任何改变。生产环境中的改变必须始终从开发沙盒中部署。
• 使用Metadata API来部署各组件的改变。
• 只允许一个管理员在生产环境中进行“设置”界面的更改。
• 对于需要经常向生产环境中部署的情况，制定定期的计划任务。