本篇参考:
https://help.salesforce.com/s/articleView?id=sf.deploy_sandboxes_intro.htm&type=5
https://guides.github.com/introduction/flow/
https://developer.salesforce.com/docs/atlas.en-us.224.0.sfdx_dev.meta/sfdx_dev
一. Application Lifecycle Management(ALM)
我们都知道,聊起来salesforce的实施,想到的前三个词中大概率就会包括敏捷这个词,当然每个人站在不同的位置对这个词就有不同的含义。对于开发人员来说,敏捷可能意味着2、3周一次上线。对于项目管理来说,可能需要根据客户的需求去分析去根据优先级以及resource情况排sprint计划等等。敏捷不代表没有流程性,相反敏捷对于团队成员的整体能力以及流程要求更高。Salesforce提供了一套应用的生命周期的管理流程以及针对这种管理模型对应的三种开发模式。我们可以通过下图查看到一个应用的生命周期流程涉及到的阶段,各阶段含义的相关介绍如下。
当然,上述说的内容是一个比较common的,不同的场景可能大步骤还是这样,执行起来好多就可以忽略。比如一个项目特别小,就是一个CR,做一做 report ,修复修复bug这种打补丁相关的项目,我们就可以省略了发布阶段的用户培训这个步骤。我们的一个发布版本可以根据改动大小分成三种不同的种类:
二. 开发模式浅谈
Salesforce 提供了三种开发模式或者开发模型。Change Set 开发模型 、 Org 开发模型 以及Package 开发模型。当然,我想大部分人对第一种开发模型很熟悉,事实上,好多的国内项目现在还在用 change set进行部署管理。那么这三种模型有啥使用场景以及优缺点呢?这里进行一个简单的描述,后续看一下是否有必要每个进行单独的讲解。
1. Change Set Development Model
这种应该是大部分人都比较熟悉的一种模式。我们在项目启动到项目上线(上线后维护),通常的阶段会是:
Dev: 项目的开发阶段,进行代码的开发等。
SIT: 项目的系统集成测试,进行多端系统的集成的测试。
UAT: 用户接受测试,实际的客户进行功能测试。
PROD: UAT客户验收以后,实际生产环境。
HOTFIX:生产环境出现紧急问题的补丁的sandbox。
我们实际做项目时,UAT以前如果有代码质量review等操作,基本上要在上UAT以前进行此操作。因为不同的sandbox需要履行的事情不同,所以对sandbox的类型的使用也各不相同。PROD没有说的必要,肯定用生产环境,不涉及到 sandbox的选用。 FULL环境理论上需要和生产环境的配置以及数据等等相同,进行实际生产环境的mock以及进行大数据量的性能测试等,所以UAT环境需要使用 FULL SANDBOX。SIT 需要和各个外部环境进行集成测试,在保证数据量,功能等情况,以及可能需要带入一些实际生产数据等考虑,通常SIT会使用 Partial Copy Sandbox,使用时需要考虑他的刷新的周期以及存储量等是否可以满足使用。HOTFIX通常都是项目 Release以后部署完生产环境以后要尽快的弄成和生产环境配置相同,所以可以使用 Developer Pro Sandbox,好处是刷新的周期是1天,即使上线以后出现了一些问题,也可以通过 hotfix去紧急对应,然后以 hotfix进行部署上线。
Change Set Develop Model使用的优缺点:
优点:
缺点:
所以我们使用 change set develop model通常用于minor的这种变更,比如针对 trigger / apex class等一些变动,或者增加 修改一个 record type相对应的变更等,可以使用 change set。
2. org development model
相对于 change set模式的缺点, org developmet model就特别适合一个大型项目的运作了。 org development model优点很多,但是针对 change set模式最好的两个特性: 自动部署 & 自动追踪变更。org development model有一个很重要的点就是 VCS(version control system)。国内项目因为体量等原因实际用起来的项目不是特别多,目前对日以及对欧美项目基于 org development model的相对挺多的。印象中之前做过的一个对日项目,项目有几个特性。
当然,其他的特点还有很多,上述只是罗列了3点,即: 周期长,版本管理重要,部署要方便。这种场景使用 org development model便会极为的方便,针对后续部署时,哪些内容上,哪些内容不上,复杂的迭代场景也会更加的友好。
当然,org development model也不是万能的,目前salesforce不是所有的metadata都支持使用metadata api或者CLI来部署,针对 org development model不支持的场景,仍然需要走 manual 的操作。这里引申一道题:
Universal Containers has an active production org; and they are planning to release some new features to it next month. The team is working to prepare .1 deployment plan and reached out to the technical architect for inputs on rollback strategy. What should a technical architect recommend?
A. Backup the existing metadata using the ANT Migration Tool. To roll back deployment, deploy again to production using backed up metadata.
B. Create a sandbox from production to take the backup of existing metadata. To roll back deployment, manually delete new components and then deploy again to production using metadata from this sandbox.
C. Create a sandbox from production to take the backup of existing metadata. To roll back deployment, use destructivechanges.xml to delete new components and then deploy again to production using metadata from this sandbox.
D. Backup the existing metadata using ANT Migration Tool. To roll back deployment, manually delete new components and deploy again to production using backed up metadata.
我认为这道题应该选择C的。之所以ANT MIGRATION TOOL去备份 metadata不选择,就是有一些是不支持部署的,全量备份还是需要刷新 sandbox去备份,更稳妥。如果有不同理解并且认为我的答案是错的,欢迎相互交流。
3. package development model
我们在实际项目中使用sandbox的缺点是什么呢?我们新起了一个项目,特别小。可能就是写一个 trigger更新一个字段等等。那开发环境的 sandbox因为很久没有刷新,这个表的字段不全,怎么办,现在的做法最稳妥的就是刷新一下 sandbox。 这种场景引申一下,所以我们会发现。如果涉及到 sandbox资源和生产不完整的场景,好多时候我们开发以前的第一步都是要先刷新sandbox保证两边相同,随着生产环境的资源以及存储等区别以及sandbox template type的区别,刷新时间并不完全确定,以 developer Pro sandbox为例,刷新周期是1天。当然,如果生产环境资源少,可能很快就刷新完成,但是如果多的话,可能需要1天。如果我们的工作可能半天就搞定,但是需要等1天的刷新时间,是不是很得不偿失。 salesforce提供了一个新的开发模式,基于包的开发模式,也不需要创建sandbox,可以直接创建 scratch org来进行资源获取以及资源部署。
针对 package development model,推荐一些中文的链接:
https://www.jianshu.com/p/651925a1dd03
Salesforce LWC学习(一)Salesforce DX配置
https://www.jianshu.com/p/aab15e748e48
这里有对 scratch org / package development model以及 salesforce DX配置的一些简单介绍。
总结:篇中只是针对这三种模式很浅的介绍, change set相对容易一些,针对 org development model 以及 package development model实际使用中,特别是大型的项目使用场景下,配置项以及细节考虑特别多。对这些部署模式感兴趣的可以查看头部的相关的官方文档去进行深入的学习。篇中有错误地方欢迎指出,有不懂欢迎留言。