Salesforce 开发经验（1）

让我们来看看您的开发团队如何在基于组织的Salesforce开发模型中工作。

你是一个快节奏的高科技公司的发展领导者。对于您的版本，您需要定制核心CRM应用程序，并且还希望为您的公司构建一个内部应用程序。开发的第一步是确保获得生产组织的最新快照。在基于组织的模型中，您的生产组织是所有代码，配置和自定义的真实来源。

无论您正在构建什么，您最终都会创建适用于您的生产组织的部署。如图所示，即使您有多个团队在单独的开发项目上工作，他们也会使用相同的部署来开发和发布更新。一切都进入一个package.xml。

我们将此模型称为基于组织的开发，因为发布或部署是关于生产组织的。您的开发人员和发布经理将组织视为混合的代码和自定义集合。为了把这个观点带回家，再看看图。最终的部署不在“延时管理器”应用程序或CRM扩展范围内;它包括对组织的所有更改。

随着您的发展，您必须跟踪您正在改变的内容，以确保您知道要将什么部署到生产组织。你的改变与其他人改变了，所以这可能是一个棘手的，有点手动的过程。如果在这个过程中使用源代码管理，源代码管理系统就会体现出混合代码和定制的相同感觉。您将源代码库与组织的一部分（例如，“休假管理器”应用程序）对齐。

但是如果能够开发一种改进开发和发布工作流程的新范例呢？

Salesforce DX旨在通过提供与多个开发团队一起管理复杂组织所需的重大改进来重塑您的开发流程。为了实现这些改进，Salesforce DX将开发模式从单一的基于组织的开发流程转变为基于模块化的基于工件的开发流程。

Salesforce DX提供：

• 通过更改跟踪安装程序功能改进版本控制系统（VCS）同步
• 通过持续集成（CI）和持续交付（CD）来提高质量和上市时间的能力，
• 更细粒度的可视性和清晰的生产组织的变更管理
• 实施更灵活的版本管理流程的能力

这是什么意思？代替构建组织的代码和自定义，您可以将代码和自定义构建到表示组织的子集的工件（一组逻辑代码）。

那么什么是神器？工件是一组相关的代码和定制。工件可以独立于组织中的其他组件进行测试。一个神器也应该能够独立发布。工件中的元数据组件一次只能存在于一个工件中。

工件内的组件可以代表很多东西。工件可以是为支持销售团队而创建的一组定制。工件可以是组织中构建的应用程序的Lightning组件，对象和工作流程。或者，工件可以是您在从AppExchange安装的托管包周围构建的扩展。也就是说，AppExchange包本身是一个神器，但第三方拥有它。

VCS是开发人员最好的朋友，在Salesforce DX开发生命周期中起着不可或缺的作用。使用Salesforce DX，可以将工件的所有源代码存储在源代码管理存储库中;这就是真理源头所在的地方。您可以从该源构建Salesforce DX开发组织，以便专门处理您的工件。我们提供更改跟踪功能，以监视您在开发组织中创建，更新和删除的内容，以便您可以轻松地将修改后的源代码下载到您的文件系统，并将其检入到您的VCS中。

通过这个新的流程，您可以将您的组织组织为一组工件。通过将源代码和元数据组织到工件中，您可以更好地理解组织中元数据组件之间的关系。你的组织越大，这个过程就变得越重要，所以要尽早规划，总是在考虑如何组织你的组织。

基于模块化工件的开发使您可以更灵活地管理团队和版本。您可以指定小组拥有特定的工件。开发团队可以单独开发并构建工件发布版本，而不是发布组织更新。使用这个敏捷模型，您可以获得更频繁的独立版本，就像您在开发，构建和部署流程中看到的那样。

这也延伸到CI和CD。构建工件可让您创建专门为该项目设计的测试计划。您可以使用Salesforce DX工具自动执行测试计划，通过在多个环境中运行测试（通过VCS修改源代码）来确保连续的质量水平。