本篇参考：
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提供了一套应用的生命周期的管理流程以及针对这种管理模型对应的三种开发模式。我们可以通过下图查看到一个应用的生命周期流程涉及到的阶段，各阶段含义的相关介绍如下。
1. 计划发布阶段：一个项目启动以后，不是开发直接干就完事了，而是应该先由一个计划来开始我们的自定制或者开发的项目。收集需求并进行分析，让产品经理（或同等级别的人员）创建设计规范，并与开发团队共享这些规范以供实施。随着项目在ALM周期中的进展，确定团队需要的各种开发和测试环境。
2. 开发阶段：在开发的sandbox上按照设计文档进行程序的开发工作。使用声明性工具（Process Builder、Custom Object Wizard和有UI界面的其他的功能）和编程工具（develop console、sublime 或 visual code studio等）的适当组合在Lightning平台上开发。
3. 测试阶段：在我们和其他人的工作集成以前，需要先检查一下我们的更改内容是否按照预期来工作。在开发步骤中使用的相同类型的环境中进行测试，但要将开发环境和集成测试环境分开。通过下图可以看到，当我们在测试阶段出现一些问题情况下，我们应该针对开发阶段以及测试阶段有一个可以自动测试的持续的集成过程（CI）。
4. 构建发布阶段：将当前release在开发阶段创建或修改的所有资产聚合到一个用来部署到生产环境中的定制包中。从这一点开始，关注你将要发布的team所有人的内容，而不是个人的贡献。
5. 测试发布阶段：测试实际要部署的内容，但要在尽可能模拟生产的环境中安全地进行测试，使用实际数量的代表性生产数据。将测试环境与所有外部系统连接起来，以模拟生产系统的集成点。在此步骤中运行完整的回归和最终性能测试。与一小群经验丰富的测试人员一起测试发行版（一种称为用户验收测试的技术UAT）。
6. 发布阶段：完成测试并达到质量基准后，可以将定制部署到生产环境中。培训员工和合作伙伴，让他们了解变化。如果某个版本对用户有重大影响，请为培训用户创建一个具有真实数据的单独环境。
当然，上述说的内容是一个比较common的，不同的场景可能大步骤还是这样，执行起来好多就可以忽略。比如一个项目特别小，就是一个CR，做一做 report ，修复修复bug这种打补丁相关的项目，我们就可以省略了发布阶段的用户培训这个步骤。我们的一个发布版本可以根据改动大小分成三种不同的种类：
- Patch：这种打补丁的发布的种类通常用于Bug修复和简单更改。简单的更改包括报告、仪表板、列表视图和电子邮件模板。
- Minor（较小变更）：影响有限的更改，例如影响单个业务流程的新workflow或者trigger。这些版本通常需要测试，但只需要有限的培训和更改管理。通常，一个团队会在几周内为一个小版本交付更改。
- Major（较大的变更）：具有重大影响的更改，包括具有一个或多个依赖项的更改。因为这些版本会极大地影响用户体验和数据质量，所以它们需要彻底的测试、培训和仔细的更改管理。主要版本通常每季度发布一次（Salesforce每年发布三次）。
二. 开发模式浅谈
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使用的优缺点：
优点：
1. 声明式操作，不管是source sandbox的 outbound change set还是target sandbox的 inbound changeset，只需要在UI上面操作，动一动你的手指头便可以搞定。
2. 对于有关联关系的组件，部署简单。类之间相互引用等这种有级联关系的，使用 change set部署很容易。
缺点：
1. 如果公司有多个BU，然后有多个生产环境，并且生产环境需要部署同样的东西， change set方式便会爱莫能助因为 changeset 基于 sandbox的 deployment setting去设置 source and target关系，也只能绑定到一个production环境，涉及到多个生产环境无法实现。
2. 声明式的方式就注定涉及到大量的组件的部署，会相对不方便。
3. 无法实现自动部署，因为只有人工的点击部署按钮，才可以进行资源的部署。
4. profile / permission set等部署会很棘手，这两样部署以前需要查看文档中针对这两个内容的特殊的注意事项，所以老人好多时候就说，如果资源不多，profile就不部署了吧，直接手动生产配置。
5. 追踪组件资源的变更也会很麻烦。
所以我们使用 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的相对挺多的。印象中之前做过的一个对日项目，项目有几个特性。
1. 项目周期很长，一期项目从0到1的上线持续了1年到1年半的时间；
2. 开发人员很多，相对复杂。每个sprint中针对机能可能会有一些修改或者回滚操作。针对机能的每个版本变更很在意，后续有回滚或者基于哪版继续开发几率高；
3. 每个人一个 sandbox进行开发，使用 git作为代码仓库，开发部署完以后，需要重新部署到各自开发人员以及SIT等环境的sandbox容易并且耗时少，最好可以实现自动化部署。
当然，其他的特点还有很多，上述只是罗列了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.