🔍Salesforce 模块化软件包变更模型研究

tags
CRM
dev
type
Post
summary
status
Published
slug
salesforce-modular-software-package-change
date
Feb 5, 2020
  1. 基于程序生命周期的开发模型
    1. 传统的软件开发基于应用生命周期,随着组织的发展,企业应用的复杂性会成倍递增。基于应用生命周期的开依赖于所谓变更集的概念。变更集是一个用于发布的概念工具,记录的是软件在不同组织之间转移部署的差异。 Salesforce有别于其他企业级应用的一个关键,就是它使用的是基于组织的软件设计观念。循照着生命周期变更进行软件发布时,第一步就是获取现存生产组织的最新快照。在基于组织的模型中,生产组织是所有代码、配置和自定义项的真实来源。
      不管是对核心CRM程序的自定义,还是既有业务流程的代码抽象,最终进行的版本发布都是针对生产组织的部署。从下面的图中可以看出,在变更集的概念中,即使有多个团队从事不同的开发项目,他们也都会使用相同的部署来开发/发布更新。如Maven的package.xml或Node.js的package.json,都记录了所有团队、项目在新版本的发布变更。
      最终的部署范围,不限于特定的应用程序或者CRM扩展,它包括了对组织的所有更改。这样的发布流程可能会随着业务扩展变得越来越麻烦,而且部署的难度与未知风险也会随之加大。
  1. 通过软件包开发管理变更
    1. 很明显,集中了所有变更的统筹发布不利于开发团队的管理,更不利于自动化测试、持续集成和敏捷开发。软件包是另一软件发布的概念工具,它是一组相关的代码和自定义项。在Salesforce中,组织中的所有数据、所有对象都被认为是软件包。
      不同的项目、团队可以借助VCS管理项目的开发和变更。业务团队可以拥有一个特定的软件包,如销售团队可以拥有一个支持销售业务的定制,包括了Lightning组件、特定对象、工作流等等。而组织也可以被视作是一个软件包,其中包括的是不同项目的源代码和元数据,借助这样的设计可以方便地了解组织中各个组件于元数据组件之间的关系。
      在Salesforce中的软件包概念很像微服务的架构,不过这个模型是基于组织,而不是应用→容器→服务器→CICD的传统技术概念,但有一点是一致的,软件包发布流程的高效运转依赖于组织的科学划分,就像微服务架构需要将业务进行高内聚低耦合的拆解一样。
      Salesforce提供的解锁包概念支持同一组织中不同软件版本的高效更迭。业务团队可以根据自身发展更高效地修改业务逻辑,同时软件包的异步发布也不用像传统一致发布造成无谓的等待消耗。

lucky_bricks © 2018 - 2024