【转】【Salesfoece】Salesforce 应用生命周期管理

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来部署各组件的改变。
  • 只允许一个管理员在生产环境中进行“设置”界面的更改。
  • 对于需要经常向生产环境中部署的情况,制定定期的计划任务。
posted @ 2020-11-28 21:14  猪猪宝丫  阅读(180)  评论(0编辑  收藏  举报