给SugarCRM二次开发人员的提醒和建议

SugarCRM开发最佳实践

当开发Sugar®定制作为CRM项目实施的一部分时，我们建议将整个Sugar应用程序文件系统置于源代码管理之下。Sugar开发人员知道对Sugar进行的自定义放置在./custom/目录下。但是在CRM实施的生命周期中，您将需要升级Sugar版本，这将更改核心文件。许多项目还需要跟踪可能并非全部是Sugar平台代码的其他相关项目文件。例如，飞行前SQL脚本，数据迁移脚本，Web服务器配置设置等。

对于SugarCloud项目和ISV，如果要构建旨在安装到许多Sugar实例（包括SugarCloud实例）中的自定义模块包或集成，则仅跟踪./custom/目录文件就足够了。

使用.gitignore文件

如今，许多开发人员选择使用Git作为其源代码管理。有一些您不想跟踪的Sugar应用程序文件；这些文件可能包含以下内容：其中大多数是在运行时创建的生成文件，或者是Sugar实例特定的配置文件。

以下是一个示例.gitignore文件，您可以使用它或将其适应您选择的源代码管理系统。

*.log
/cache
/config.php
/config_override.php
/.htaccess
/custom/application
/custom/history
/custom/modules/*/Ext
/custom/blowfish

给SugarCRM开发团队的建议

代码质量对于维护至关重要，因为Sugar定制与Sugar应用程序的其余部分在相同的环境中运行。这里有一些最佳实践，可以帮助开发团队保持代码质量。

• 采用适当的Git工作流程进行开发。作为参考，请参阅Atlassian的Git工作流程选项教程。
• 在合并回master中以保持master稳定之前在经过测试的功能分支中进行开发。
• 避免涉及开发人员直接提交到master分支的工作流，以防止代码不稳定。
• 开发团队应始终在合并新代码之前执行代码审查。

部署SugarCRM

计划将Sugar代码部署到何处是决定应如何部署Sugar代码以及如何管理项目的最大因素。

您是否正在为内部实施Sugar进行Sugar项目？您是否正在计划通过SugarExchange分发的自定义模块？您是否计划仅进行REST API集成？这些问题的答案指导您如何开发和部署Sugar代码。

• SugarCRM定制：开发利用糖的确切版本和风味这些自定义您计划在生产中使用。
• SugarCloud定制：制定关于糖的特殊味道客户购买最新版本这些定制。
• 自定义模块或集成：如果您打算通过SugarExchange或渠道合作伙伴将自定义项分发给许多Sugar客户，请在设计时考虑到Sugar的云服务。
  • 在支持的自定义方面，Sugar的云服务比我们的现场安装更具限制性。
  • 可以在Sugar现场实例中支持为Sugar的云服务设计的自定义，但并非总是如此。

有关Sugar的云服务限制的更多信息，请参考SugarCloud策略指南。

打包

对于许多Sugar项目而言，定制的包装并不是一个问题。许多项目仅使用Git（或其他文件版本控制）来管理Sugar代码定制的分发和部署。但是，在某些情况下，必须包装Sugar定制。

如果计划分发Sugar自定义代码，则必须将自定义打包为可模块加载的程序包  （包含所有自定义代码和清单文件的.zip文件）。通过自定义目录内容或通过从开发环境中提取自定义内容来编写脚本来构建可模块装入的软件包很容易。在此处和此处查看有关Github的示例。

在某些企业环境中，更改受到严格控制，各种Sugar应用程序组件的所有权可能分散在多个团队中，需要协调部署。例如，数据库管理员（DBA）可能负责实施数据库架构（DDL）更改，而系统管理员可能负责实施文件系统更改。

对于这些情况：

可以使用Git来考虑文件系统更改，以确定当前生产状态和要部署的最新更改之间的差异。

可以通过在Sugar生产实例的克隆上部署最新文件系统更改并运行Quick Repair命令来解决DDL更改。Sugar将提示您需要进行的任何DDL更改，然后您可以捕获它们并与您的DBA共享。

如有必要，应在SQL或PHP脚本中管理数据操作语言（DML）的更改。

部署方式

如果使用传统的基于Git的部署，则部署新的Sugar代码就像签出最新分支然后运行Quick Repair and Rebuild一样容易。从Sugar用户界面运行快速修复，或  编写脚本  以进行全自动部署。

当在Sugar的云服务上部署到实例时，必须使用Module Loader手动安装软件包。无法将包自动部署到Sugar的云服务上的实例中。

在协调部署中，应首先部署数据库更改，然后部署文件系统更改，再部署快速修复（如果允许）以清除系统缓存。您可以通过删除./cache/目录的内容，然后截断metadata_cacheSugar数据库中的表来手动清除缓存。Sugar应用程序根据需要重新生成这些缓存。

不建议使用Sugar Studio将更改部署到新环境（尤其是生产环境）中。使用Studio用户界面手动重新创建自定义设置可能会容易出错。它还冒着无意中覆盖其他代码自定义项的风险。最初使用文件系统上的扩展名手动创建自定义字段等可能较慢，但从长远来看，您将从更好的变更管理和自动化中受益。

管理多种环境

CRM是关键业务应用程序，因此永远不要在生产环境上直接执行开发。一个典型的Sugar项目涉及多个暂存环境以及每个Sugar开发人员用于实际编码的单独开发环境。

SugarCRM建议使用4种不同的环境：

• 生产环境：供实际用户使用
• 用户验收测试（UAT）环境：供业务涉众使用，以签署即将投入生产的变更
• 质量保证环境：用于测试和验证新功能和错误修复
• 开发环境：由各个Sugar开发人员用来创建和测试代码（通常在本地笔记本电脑或PC上运行）

在未经开发人员首先通过质量保证（QA）和用户接受测试（UAT）的情况下，不允许在开发环境中上游进行代码更改。中间环境充当开发和生产之间的大门，有助于在问题到达生产之前就对其进行拦截。

需要从生产环境流向下游的用户和CRM数据也应通过中间环境，以确保一致性，并清除或匿名化任何个人可识别或敏感信息。

一致性

对于这些环境中的每个环境，保持尽可能高的一致性至关重要。不一致的环境可能会产生这样的问题，即在一个环境中不能复制错误，而在其他环境中则无法复制（例如，仅在生产环境中出现的错误）。很多时候，这些错误都是由于配置参数引起的，这些配置参数与Sugar或正在开发的功能和自定义不直接相关。

为了尽可能准确地复制生产环境，我们建议您在开发和QA环境中使用VM或容器技术。

您的UAT环境应与生产环境的基础结构匹配。

SugarCRM在开发核心Sugar应用程序和进行Sugar项目中使用了多种容器技术。特别是，我们使用Virtual Box，VMWare，Amazon AMI，Docker容器，Vagrant和Packer。SugarCRM Engineering还使用Puppet集中管理所有这些不同环境的配置和配置。

测试中

SugarCRM建议使用多种测试方法来确保Sugar项目的质量。执行单元测试，功能测试（手动或GUI自动化），系统集成测试，用户验收测试和性能测试。

• 应该进行单元测试，以确保即使应用程序中最小的代码单元也能按预期运行。
• 应该执行功能测试以确保每个功能部件都按照其设计方式运行。
• 应该执行系统集成测试，以确保Sugar与外部系统共存，并确保数据在所有这些系统之间成功流动。
• 用户验收测试应该由主要的利益相关者执行，以确保您的项目满足业务需求。
• 应该执行性能测试，以确保Sugar应用程序的响应能力满足用户期望并且应用程序可以继续扩展。

根据我们的经验，忽略这些测试中的任何一项都会对Sugar项目的可维护性，客户满意度和业务成功产生负面影响。 

在下一节中，我们将介绍一些工具和开源资源，这些工具和开源资源可帮助您启动项目的质量检查实践。

SugarCRM测试工具

对于Sugar客户和合作伙伴，SugarCRM提供 了可用于验证和执行Sugar定制质量保证的测试工具。使用Sugar测试技术要求熟悉PHPUnit（用于PHP单元测试），Jasmine（用于JavaScript单元测试）和Apache JMeter（用于性能负载测试）。

SugarCRM 单位测试

Sugar单元测试套件是SugarCRM Engineering在构建和发布每个新Sugar版本的过程中开发和维护的自动化单元测试。作为我们开发过程的一部分，要求这些测试始终在每个主版本分支上运行“绿色”（100％通过）。本质上，这些测试构成了在我们受控的构建环境中运行的非定制版本的Sugar的回归测试套件。

基于这种理解，下面是推荐的方法来利用这些单元测试。

• 针对开发环境中未定制的Sugar副本运行测试套件以建立基准。并非所有测试都可以立即通过。由于开发环境和SugarCRM Engineering的受控构建环境之间的配置差异，有些可能会失败。
• 更正所有观察到的故障或跳过/删除失败的测试，以创建100％通过的基本测试套件。
• 在Sugar上开发自定义项时，请确保基本测试套件继续通过。
• 为您创建的新代码自定义创建新测试。

SugarCRM 性能测试

SugarCRM并没有为进行负载测试而对生产环境中的数据进行清理，而是提供了一个名为Tidbit的开源工具，该工具可用于生成伪随机数据，以可表示数据填充Sugar实例。

我们还向请求访问权限的Sugar客户和合作伙伴提供Apache JMeter方案。这些JMeter场景可用于根据Sugar使用的Sugar REST API接口来驱动模拟负载。他们可以验证您的自定义设置对Sugar实例的性能没有意外影响。

开发运维

为了促进和简化开发流程，Sugar建议实施DevOps自动化。使用诸如Jenkins之类的工具来协调测试自动化，在任何环境（开发，质量保证，UAT和产品）中分阶段进行更改以进行手动验证，并管理从一个环境到另一个环境的变更升级。

• 对每个提交执行自动化测试（例如，单元测试）。
• 阶段开发至少每晚更改一次，以供质量检查人员或演示人员使用。
• 根据需要自动回滚任何环境中的更改。
• 测试失败或构建部署失败时，自动向受影响和负责任的各方发送通知。

SugarCRM 与Studio定制共存

Sugar Studio和Module Builder使管理员用户可以对Sugar环境进行快速更改。但是Sugar Studio缺乏大型CRM项目所需的严格变更控制。有时，Studio更改甚至可能破坏代码级Sugar的自定义。因此，我们通常不鼓励在高度定制的Sugar实例上使用Studio。

但是，如果Sugar Studio是CRM项目的重要的前期要求，那么您可以采用一些策略来进行自定义以避免冲突。

Sugar Studio可用于修改Sugar中大多数模块的布局，字段和关系。模块构建器可用于定义新模块及其布局，字段和关系。实际上，这意味着可以使用简单的管理工具自定义任何模块的记录视图，列表视图，移动视图和子面板的字段和布局。

因此，Studio用户可能会破坏依赖于特定字段或具有特定布局或位置上的字段的代码自定义。以下是一些避免Studio自定义与自定义代码冲突的做法：

• 避免使用自定义记录，列表和子面板视图控制器，因为Studio用户可以更改影响控制器代码中期望值的字段和布局。
• 避免自定义记录验证，因为Studio用户可以更改验证代码中影响期望值的字段和布局。
• 避免依赖于特定字段的硬编码集成，因为Studio用户可以更改会影响集成期望的字段。
• 避免使用新的字段和关系vardefs定制，因为Studio用户可以创建新的字段和关系。
• 避免对记录，列表和子面板布局使用viewdefs自定义，因为Studio用户执行这些自定义。

许多自定义项与Studio自定义项相关的副作用的风险较小。以下是管理员用户无法通过Studio执行的一些更改的列表：

• 添加自定义仪表盘
• 在页脚或页眉中添加自定义布局或添加内容
• 在记录视图操作下拉菜单中添加自定义操作
• 添加感知元数据的集成，以发现系统上的字段和模块
• 添加逻辑挂钩

相反，某些自定义项可以为Studio用户提供其他工具：

• 添加自定义的Sugar Logic功能
• 添加自定义的Sugar字段类型