开发生命周期

Salesforce开发生命周期(4)跟踪和同步变更

学习目标

完成本单元后,您将能够:

  1. 建立生产环境变更流程
  2. 手动跟踪更改
  3. 使用Ant迁移工具跟踪更改
  4. 使用Force.com IDE跟踪更改
  5. 同步更改
  6. 同步多个沙箱
  7. 整合开发环境的变化

发布管理的一个挑战是跟踪更改。这在概念上听起来很简单,但在实践中,它可能不是。生产和开发组织以及Metadata API中可用和不可用的组件中的更改可以同时发生。

跟踪更改的最简单方法是使用传统开发工具对代码进行区分,合并和版本化。但是,这些工具仅适用于Metadata API中可用的组件,因此需要手动跟踪更改。这可能看起来很多工作,但能够跟踪和复制所有环境中的更改是确保在不覆盖生产组织更改的情况下成功部署功能的唯一方法。在Lightning平台上,跟踪更改的最重要原因是您可能必须手动将某些更改从一个组织迁移到另一个组织。

建立生产环境变更流程

使用Salesforce Web用户界面快速开发和定制生产组织中的应用程序的能力是Lightning Platform的众多优势之一。 但是,在开发企业应用程序时,这种易于开发可能会导致生产组织发生变化,同时在沙箱中开发应用程序。 为了确保成功部署到生产组织,您的开发环境必须具有与生产相同的更改。 将修改从生产组织转移到开发环境似乎是一件倒退的事情,但这是必要的,因为从开发迁移到生产可以覆盖已经在生产中进行的更改。

在生产组织上进行修改时,您可以执行沙箱刷新并获取最新更改。 但是,沙盒刷新并不总是可行(对于完整的沙箱,您只能每29天刷新一次),并且可能需要您执行配置更改,例如修改用户配置文件或权限集,以便您的开发人员具有必要的权限。

因此,跟踪生产和开发环境之间的变化,然后将这些差异从生产合并到开发,可能是一个必要的过程。 为了使这些任务更容易,为您的生产组织建立变更流程是个好主意。 更改过程确定可以对生产组织进行哪些类型的修改,何时可以发生以及谁负责进行更改。 您采用的更改过程取决于生产环境中所需的修改类型。 以下列表提出了一些变更流程的最佳实践,从最简单到最复杂。

  • 不允许更改生产 – 这是您可以执行的最简单,但也是最严厉的措施。 实际上,您正在牺牲即时设置更改以便于部署。 如果选择此过程,则所有开发都在沙箱上进行。
  • 仅修改元数据API中的组件 – 手动跟踪和部署更改比使用元数据API复杂得多。 如果您可以将生产更改限制为可通过Metadata API访问的组件,那么这将简化更改跟踪,合并和部署。
  • 只允许一个管理员进行设置更改 – 有些组织发现分配一个负责生产所有设置更改的管理员很有用。 这样可以更轻松地跟踪生产组织的更改,并将这些更改复制回沙箱刷新之间的开发环境中。 这是一种更灵活的方法,允许同时更改生产和基于项目的开发。 但是,如果您的组织足够小,以至于一个管理员可以进行所有设置更改,那么这只是一个可行的解决方案。
  • 安排生产更改 – 如果您的组织需要频繁更改生产环境,则可以安排时间将这些更改迁移到开发环境。 根据您拥有的组织数量,这可能是经常轻松迁移(可能是每周一次),也可能是较不复杂的流程(每季度一次)。

手动跟踪更改

您可以使用桌面工具跟踪和合并您对Metadata API中可用组件所做的任何更改。 如果使用Force.com IDE或Ant迁移工具,则可以将文件放在版本控制系统中,并且可以使用版本控制系统的内置功能跟踪更改。 但是,大多数IT组织会对未在Metadata API中表示的组件进行大量更改,因此需要手动跟踪生产和开发组织的更改。

拥有一种跟踪所有更改的方法非常重要,尤其重要的是,如果这些更改需要手动迁移。 一个有用的工具是一个更改请求表单,用户和管理员填写所请求的每个增强或执行的更改。 您可以在Salesforce中创建自定义应用程序,以记录更改请求和所做的实际更改。

提示:AppExchange包含可以安装以管理此过程的自定义应用程序,例如免费的 Change Control应用程序。

大多数IT组织还使用电子表格来记录和跟踪这些更改。 电子表格允许您在迁移或跟踪这些更改时按标题排序,创建数据透视表以及执行其他有用的操作。 在电子表格列表中发生的每个更改,包括:

  • 谁做出了改变
  • 发生变更的组织
  • 日期和时间
  • 哪个组件已更改

您何时需要手动跟踪更改?

  • 对不在Metadata API中的组件所做的更改 – 您必须手动跟踪对Metadata API中不可用的组件的每个更改。
  • 使用Salesforce Web用户界面所做的更改 – 即使组件通过Metadata API可用,您也应该跟踪使用Web工具所做的更改。 Web工具和Metadata API之间的并发更改通常会创建依赖关系,并且是部署问题的常见来源。 为了安全起见,最好手动跟踪通过Web界面进行的所有更改。

Salesforce Web用户界面中所做的更改将记录在安装审核跟踪中。 将审计跟踪与手动更改跟踪工具结合使用是确保您不会错过任何更改的最佳方法。 您如何管理此流程取决于您,但最好定期将审计跟踪中的所有更改传输到您的更改列表(例如,每周一次),或仅使用审计跟踪来交叉检查更改 你的变更清单。 有关使用设置审计跟踪的详细信息,请参阅Salesforce联机帮助中的“监视设置更改”。

使用Ant迁移工具跟踪更改

Ant迁移工具对于基于脚本的部署尤其有用,例如迁移批量组件。 另一个特别有用的批处理脚本可以编写为diff元数据更改。 这样的脚本允许您在预定的时间或不同的组件集执行差异。

  1. 创建一个列出要比较的组件的xml文件。
  2. 创建检索目标以下载组件。 例如:
    <target name=”retrieve-production”>
    <sf:retrieve
    username=”${sf.username}”
    password=”${sf.password}”
    serverurl=”${sf.serverurl}”
    retrieveTarget=”production”
    unpackaged=”package.xml” />
  3. 编写外部脚本来区分文件。
  4. 指定调用脚本的目标并将结果输出到文件。 例如:
    <target name=”show-production-differences”>
    <!– get metadata from organization –>
    <antcall target=”retrieve-production”/>
    <!– perl script to find changes –>
    <exec executable=”/bin/bash”>
    <arg value-“-c” />
    <arg value-“cd production;
    svn stat|../showdiffs.perl>../report.txt”/>
    </exec>
    </target>

注意:此过程仅是执行编程差异所需的基本步骤的示例。 您可能希望定义多个文件夹和package.xml文件,以便可以批量检索组件。

使用Force.com IDE跟踪更改

使用Eclipse中的内置功能或任何其他更改跟踪实用程序,可以轻松跟踪和合并Force.com IDE中所做的任何更改。 有关更多信息,请单击Force.com IDE中的“帮助”。

同步更改

Metadata API将Lightning Platform组件描述为可在不同环境之间传输的基于文本的文件。 使用第三方工具,可以在开发人员和开发环境之间存储,版本化和划分这些文件。 随着您引入诸如多个开发环境,代码分支,版本等概念,应用程序开发生命周期的复杂性也会增加。

同步所有这些变化可能是一个挑战。 例如,您可能有一个开发沙箱专用于生产组织中现有应用程序的增强,另一个开发沙箱用于新应用程序。 每个组织都可以有多个项目,所有项目都在同一时间进行更改。 合并这些更改需要两个单独的流程:在同一组织中的项目之间同步更改,然后在组织之间集成更改。

同步多个沙箱

传统软件开发和云计算之间的根本区别在于,在云计算中,服务器始终具有组件的真实定义。 您在本地Lightning Platform项目中使用的文件是服务器上对象的表示。 这是一个重要的区别,因为直接在项目之间,但在每个项目和服务器之间不会发生同步:

如果使用Force.com IDE,则将更改与主组织同步就像单击“保存”按钮一样简单。 对于在两个组织中同时发生的更改,同步工具允许您以任一方向覆盖文件,或合并更改。 Force.com IDE帮助中介绍了如何保存,同步和刷新文件。

整合开发环境的变化

如果您有多个开发环境,则必须将所有更改合并到可以部署的组织中。 如果您只有两个沙箱,则可以非常轻松地在它们之间来回迁移更改。 每个沙箱都可用于将更改部署到其他组织或生产。

在添加开发环境时,同步它们的复杂性呈指数级增长。 在这种情况下,将更改合并到单独的集成沙箱组织中要比彼此更容易。 在这种情况下,从开发沙箱迁移到集成只是一种方式:

如果使用更改集来迁移组件,则可以编辑部署连接,以使更改遵循定义的集成路径。

你可能也会喜欢...