月度归档： 2018 年 1 月

现在您已经了解了如何使用Salesforce DX并认识到它的价值，您有兴趣继续研究它。那么你如何开始使用它？这取决于您的生产组织和相关开发流程的复杂性和成熟度。这里有一些建议可以帮助你开始。

评估你的开发过程的所有方面，寻找可能的方法转移到基于模块化神器的方法。在生产组织中寻找与其他一切不同的应用程序。你有不同的团队来建立和维护这些应用程序吗？如果是这样，你可以将这些应用程序分离成它们自己的工件。 AppExchange有许多独立应用程序的绝佳示例，它们遵循将源和元数据集合分离为单个工件的思路。

在某些情况下，您不会有可以拆分为工件的独特应用程序，但是您会发现一段时间内您的工作组中已经有不同的部分。例如，您的核心应用程序的扩展可能会作为工件发布。您可以将您在定制公司销售流程中所做的所有扩展分离成一个工件。如果您可以隔离特定于这些部分的元数据，则可以使用它来开发工件。

您也可以寻找已经或者希望与其他人分开制作和交付的团队。有些团队可能正在寻找更灵活和更灵活的机会 – 他们希望将他们的变更与其生产组织的更大变更管理流程分开。这些团队可以隔离他们的元数据并将其存储在自己的工件中。

一路上，确保您评估共享元数据组件的所有潜在工件。您不希望将共享元数据无意中隔离到特定团队或应用程序拥有的工件。如果元数据组件是共享的，我们建议您将这些共享组件组织到单个基本工件中。通过这种方式，您可以确保所有工件都可以引用共享工件中的组件。 （请记住，元数据组件一次只能在一个工件中生存。）

识别出潜在的工件后，您将使用Metadata API来检索与工件相关的来源。使用Salesforce DX模块查看应用程序开发，了解如何使用Salesforce CLI和测试组织来创建标识工件组件的package.xml。一旦你提取了源，为每个工件创建一个VCS存储库。从那里，您可以通过构建特定于这些应用程序的发布周期来继续分离过程。

你是一个只使用基于组织的开发模式的开发人员，还是以管理员身份开始职业生涯？那么Salesforce DX源代码驱动模型是一个接受更灵活和更灵活的开发流程的绝好机会。

如果你的组织有一个成熟的或者复杂的组织，那么随着时间的推移，转向源驱动的模型需要发生。你的生产组织是你最珍视的财产，所以要谨慎计划你的转变。使用本单元中的指导来确定您可以转移到Salesforce DX的部分组织。每次移动一件神器，并继续评估和改进您的流程。

现在您已经对Salesforce DX开发模型有了更多的了解，现在是时候通过尝试将指甲弄脏了。

如何使用Salesforce DX进行测试，构建和发布，是从当前应用程序生命周期转变而来的。然而，Salesforce DX提供了一些重要的优势。

当您准备好对您的开发工作进行手动/探索性测试时，请创建元数据并将其推送到为此目的指定的独立临时组织中。你永远不会从这个组织中提取任何东西，因为它只被用于测试/验证。

持续集成（CI）是针对与应用程序合并的每一组更改自动执行一致的测试运行。这可确保在任何损坏的更改进入源代码库之前的应用程序质量。

临时组织可以很容易地集成到CI流程中。 CLI可以创建临时组织，因此将它们脚本化为CI流程是一件小事。您可以使用适当版本的源存储库填充组织，并对特定更改运行测试。

与开发人员沙箱不同的是，可以全天创建抓取组织，而不是每天刷新一次。您可以删除一个临时组织，并在需要时快速创建一个新组织。你可以有多个划痕组织为不同的目的。从零开始组织给你一个很大的灵活性和非常有限的开销。

构建和部署过程与当前基于组织的交付方法相似。这意味着元数据API转换和部署过程将继续处理构建和部署用例。在您转换回Metadata API源代码后，您的所有工件源都可以部署。您可以部署所有源，部署操作负责更新已更改的文件。如果您需要从部署中省略某些文件，则可以通过构建package.xml文件来构建要部署的内容。

完成单元测试后，您就可以将源和元数据部署到沙箱。但首先，您需要以Salesforce DX格式获取项目中当前的源代码和元数据，并将其转换回Metadata API格式。然后，您可以使用Salesforce CLI将其部署到组织中。您可以在App Development with Salesforce DX模块中使用CLI尝试部署过程。

为了持续交付，您希望开始测试与部署到生产组织时相同的过程。在这个用例中，您需要使用您在构建阶段创建的元数据API包进行测试，并将其部署在沙箱上，这是生产组织的最佳表示形式。在沙箱中，您可以复制和测试将要发布到生产组织的步骤。

正如我们在前面的单元中所了解的那样，使用Salesforce DX，您可以决定使用哪些工具。您可以将您最喜爱的文本编辑器与Salesforce CLI或Salesforce Extensions for VS代码结合使用。您可以选择要使用的VCS。如果使用Salesforce Extensions for VS Code，我们提供了几个扩展来帮助用Salesforce DX进行开发。

对于源代码驱动的开发，您的源代码将根据您想要一起交付的一组功能或自定义设置组织为工件。 Salesforce DX项目反映了这种基于工件的方法来组织您的源代码。

Salesforce DX项目是工件来源和Salesforce DX元数据的本地目录结构，可让您使用Salesforce DX工具进行开发和测试。

它包含用于创建临时组织的配置文件。它可以包含要加载到组织以供开发或测试的数据。它还应该包含您依赖验证您的工件的测试。

当您使用CLI创建新的Salesforce DX项目时，它会为您创建项目目录结构。从零开始创建项目时，会为您创建许多事物。我们创建一个基础项目配置文件。我们为您的测试和样本数据集创建示例临时定义文件和目录。我们还为您的工件源创建了一个默认的“包”目录。

请记住，工件是一组相关的代码和自定义项。您可以独立于组织中的其他组件测试工件。一个神器也可以独立释放。工件中的元数据组件一次只能存在一个工件。

该项目至少管理一个工件的来源。也就是说，如果多个构件一起构建并发布，则可以将这些构件组织到单个SFDX项目中。每个工件都与项目配置文件中定义的软件包目录对齐。

从您的源代码和元数据构建的临时组织，使您可以轻松地一遍又一遍地构建应用程序。您只能使用特定项目的源和元数据。没有必要复制你不需要的东西（坦率地说，我们不推荐它）。由于临时组织是临时的Salesforce环境，因此可以为每个工件或开发项目快速创建新的临时组织。

一旦你的VCS被设置好了，你的源代码被组织到工件中，你就可以开始一个新的开发项目了。打开你最喜欢的IDE或文本编辑器，然后添加或修改你的源代码。当您准备好在组织中查看更改时，可以创建一个临时组织。

在创建一个scratch组织之后，您仍然需要完成一些设置任务。您需要将项目中的所有源码都推送到临时组织，设置权限，以及创建或加载使用工件所需的任何测试数据。

虽然IDE或文本编辑器可用于编程（基于代码）的开发，但您可以使用scratch org进行声明式（指向并单击）开发，就像您在沙盒或生产组织中进行的基于组织的开发模型。源驱动模型的不同之处在于，您可以将您从头开始的任何开发与本地项目同步。这使您可以提交设置页面中所做的更改以及在本地IDE中所做的更改。

在提交到版本控制系统之前，请确保运行测试。您可以使用相同的scratch org来运行测试，也可以在提交源代码之前专门进行测试。同样的测试模式将成为自动化持续集成系统的关键部分。

Salesforce DX的一个主要特点是，您可以轻松地保持项目和暂存组织的同步。所以你可以放弃那些粘滞便笺！您不必记下在本地文件系统，IDE或编辑器中更改的内容，或者在组织中更改的内容。

Salesforce DX跟踪您在项目中本地进行的任何更改以及您在从头开始的任何更改。

在将源元数据更改推送到临时组织之前，或者从临时组织中将更改提交到本地项目之前，可以查看您所做的更改列表。这就是Salesforce CLI在行动中的力量。

$ sfdx force:source:status

STATE                     FULL NAME    TYPE        PROJECT PATH
─────                     ──────────   ──────────  ─────────────────────────────────
Local Deleted             MyClass      ApexClass   /MyClass.cls-meta.xml
Local Deleted             MyClass      ApexClass   /MyClass.cls.xml
Local Add                 OtherClass   ApexClass   /OtherClass.cls-meta.xml
Local Add                 OtherClass   ApexClass   /OtherClass.cls.xml
Local Add                 Event        QuickAction /Event.quickAction-meta.xml
Remote Deleted            TempClass    ApexClass   /TempClass.cls-meta.xml
Remote Deleted            TempClass    ApexClass   /TempClass.cls.xml
Remote Changed (Conflict) NewClass     ApexClass   /NewClass.cls-meta.xml
Remote Changed (Conflict) NewClass     ApexClass   /NewClass.cls.xml

Salesforce DX解决了这个问题，它提供了一个新的源代码形式，可以分解这些大的源文件，使它们更容易理解，并且更易于使用版本控制系统进行管理。 例如，Salesforce DX将自定义对象和自定义对象翻译转换为多个文件和目录。 这个源结构使得更容易找到你想要更改或更新的内容。 源代码管理中的较小文件意味着团队开发过程中的合并冲突更少。 只要说再见，凌乱的合并！

完成开发之后，请始终将您的更改回复到VCS回购。 现在您已准备好使用Salesforce DX进行测试，构建和发布。

在Force.com平台上开发的特性之一是用于开发和部署的独特工具。一些工具很熟悉，比如Eclipse和ANT。有些是平台独有的，比如变更集和沙箱。总是有API来尝试集成到您喜欢的工具中，但这并不容易 – 尤其是考虑到Force.com平台的独特发布模式。

Salesforce DX的指导原则之一是支持与开发工具相关的开放标准。我们希望提供一种基础结构，使您能够使用熟悉的工具链，同时还提供一套建议的工具，如果您尚未使用任何工具，则可以使用这些工具。

如果Salesforce DX是一辆汽车，则Salesforce CLI将是其方向盘。如果Salesforce CLI是你的朋友，那将是你最好的朋友。你明白了。您可以使用CLI从命令行管理整个应用程序生命周期。而且它也做菜！ （不，不是真的，但不是很好？）

CLI结合了来自多个Salesforce API的许多功能，例如Metadata API和Packaging API。它还结合了其他Salesforce工具的功能，如Force.com迁移工具和Salesforce工作台。所有在一个地方。因为它在命令行，所以它是可以编写脚本的。想想你可以创建的所有酷脚本，使重复的​​开发任务更容易！

Salesforce CLI是一个机会均等的生产力增强器：

• 开发人员可以使用它来管理他们的Salesforce DX项目，创建（开发）临时组织，将资源和元数据推送到临时组织或从其中取出，并运行单元测试。
• DevOps可以将其用作构建自动化脚本的一部分，从源代码创建环境并运行测试。

将Visual Studio（VS）代码与Salesforce Extensions for VS Code结合使用时，您将获得一个强大的集成开发环境，该开发环境专门用于Salesforce平台上的定制开发。这些扩展提供：

• 与Salesforce CLI进行交互的功能
• 访问Apex语言服务器进行语法高亮显示和代码完成
• 支持Lightning组件捆绑
• 支持Visualforce页面和组件
• 支持实时Apex调试器

它也与Git预集成，但可以与其他版本控制系统一起使用。

VCS是源驱动开发的核心。您需要使用VCS来管理和版本化源，以充分利用Salesforce DX提供的功能。

所以如果你目前没有使用VCS，你怎么开始这个旅程呢？使用Salesforce DX，您的本地项目与存储库绑定。使用每个存储库保存您为工件完成的所有工作的历史记录。使用分支来跟踪每个版本的更改。每个项目至少包含一件神器。在更复杂的组织中，您可能会发现需要将多个相关的工件作为同一个工程的一部分进行开发。当一组组件和自定义取决于其他组件时，会发生这种情况。这在后面的单元中会有更多的讨论。

你是否厌倦了其他的孩子玩你的沙箱？当您使用划痕组织作为开发和测试过程的一部分时，您不会在您的眼睛里看到沙子。

设计为短暂且容易重新创建的，从头开始是适合的，可配置的Salesforce环境，您可以快速启动以实现许多不同的目的。他们可以成为你自己的个人发展环境，或者你可以创建无头的自动化测试。如果您想要：您可能会启动一个新的备份组织：

• 开始一个新的项目。
• 开始一个新的功能分支。
• 测试一个新功能。
• 开始自动化测试。
• 直接在组织中执行开发任务。
• 从一个新的组织“从头开始”。

您可以使用不同的Salesforce版本配置临时组织，只配置所需的功能和首选项。您可以与其他团队成员共享scratch org配置文件，这样您就可以拥有相同的基本组织机构来完成您的开发任务。

尽管我们认为创业公司将会摇摆您的世界并提高您的工作效率，但沙箱仍然是Salesforce开发生命周期中非常重要的一部分。 您仍将使用它们进行用户验收测试，作为从源代码构建的部署目标，作为临时环境，以及用于持续交付测试。 将源代码开发用例与您的临时组织对齐，并将发布/部署测试与您的沙箱对齐。 但更多的是在后来的单位。

让我们来看看您的开发团队如何在基于组织的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修改源代码）来确保连续的质量水平。