学习目标
完成本单元后，您将能够：
- 说明使用版本控制如何使变更集版本受益。
- 描述变更集和组织开发模型之间的相似之处。
本单元描述了为什么Calvin和他的同事着手进行代码和版本控制系统的开发。在阅读本单元时，请考虑为团队做出哪些选择。通过完成本模块末尾列出的模块来进行动手操作，以学习该过程并就最适合您的情况做出最明智的决定。
为了应付日益增加的复杂性，转向组织发展模式
Zephyrus有一个伟大的四分之一。现在，Salesforce正在业务的其他部分中使用，而不仅仅是在Sales中。在咨询了Calvin和客户服务部门的负责人之后，COO同意迁移到企业版并购买Service Cloud Lightning。借助Service Cloud Lightning，公司可以为客户提供即时和个性化的支持。更好的是，客户服务部门拥有一些具有编码技能的团队成员，可以根据他们的团队需求开发Salesforce应用程序。
对于Calvin来说，很明显，组织的复杂性正在超出团队可以通过变更集开发流程管理的范围。公司现在需要更严格的变更管理流程和审核流程（例如版本控制系统）来帮助他们管理如此多的工作流。
团队还面临着使用变更集所能做的限制。例如，他们可以添加但不能删除字段（破坏性更改）。
在向Zephyrus的董事兼首席执行官的演讲中，卡尔文建议他们转向组织发展模式。
与变更集过程一样，他们正在创建的发布工件是相对于其生产组织的一组元数据变更。但是，在组织开发模型中，团队可以通过外部化所做的更改来获得重大的更改管理改进。他们可以使用Salesforce CLI从开发环境中提取元数据，以与版本控制系统（VCS）集成。
他们还可以使用Salesforce CLI编写日常任务的脚本，并提高贡献该版本的每个人的工作效率。卡尔文建议他们首先创建脚本以运行测试部署并运行Apex测试，这对他的董事和首席执行官很有意义。
得益于Calvin的业务驱动论点，他的董事和首席执行官批准了向组织开发的转变。为了表彰他对公司成功的贡献，Calvin被提升为业务分析师。此次晋升还使Calvin获得了跨部门管理发布所需的范围。
新优势和一些熟悉的主题
卡尔文（Calvin）和两个客户服务团队成员各自在具有单独开发环境的不同项目上工作。这三个项目都计划在同一发行版中进行。在组织开发过程中，他们会注意到一些熟悉的方面以及与变更集过程不同的地方。
就像他们在变更集开发中所做的一样，所有三个团队成员都将跟踪他们所做的变更。为什么？团队需要知道哪些组件发生了更改，他们是将这些组件添加到更改集中还是使用Salesforce CLI检索它们。此外，它们的某些自定义项无法部署到另一个组织，因为它们包含未在Metadata API中表示的已更改组件。此类更改必须在目标组织上手动重新创建，因此保持对它们的跟踪仍然很重要。
当团队成员完成各自的开发任务后，下一步就是将所做的更改移至构建环境进行集成。但是现在，他们使用Salesforce CLI从各自的开发环境中检索更改，而不是使用声明性工具创建更改集。他们将工作与VCS集成在一起，因此可以在VCS中提交和跟踪团队成员检索到的更改。
在VCS中提交和跟踪检索到的更改为团队提供了一个重要的好处。在使用变更集过程时，团队成员可以（有时确实）通过在先前的变更集上部署变更集来意外覆盖其他人的变更。通过使用向VCS提交更改的新过程，可以在更改被覆盖之前识别自定义冲突。
进入构建步骤，团队的自定义项已集成到源代码管理的项目中。这些更改将从VCS一起部署到构建环境中，以进行集成和测试。就像更改集过程一样，更改将在构建环境中一起进行测试。就像以前一样，结果是一个单一的发行工件，实际上是一组较大的合并变更。但是Calvin现在使用Salesforce CLI从构建环境中检索工件。并且随着组织开发过程的进行，发行工件不断从VCS转移到下一个环境。
尽管他们在组织开发过程中使用了其他工具，但基本的ALM步骤，变更集概念以及开发和测试环境是相同的。在新的开发模型下从事第一版工作的每个人至少都有一些熟悉的参考点。同样，加尔文很高兴使用Salesforce开发人员网站上的Trailhead和资源来发展他的技术技能和知识。
迁移到组织开发模型有助于使Zephyrus获得在整个公司范围内扩展使用Salesforce所需的控制权和效率。