如何通过 GIT 使用 SuiteCRM

Question

我的公司做出了一个糟糕的决定。他们决定使用 SuiteCRM，有人为他们安装了它，现在我应该支持和开发它。我们应该对它进行很多自定义，当然它需要创建许多关系、自定义字段等 但是...我们如何通过 git 来做到这一点？在 Admin/Studio 系统中进行任何更改后，会在文件中创建大约 30-40 处更改，并且无法对其进行管理。每次修复和重建后，都会有数百次更改。它是可怕的。

是否有使用 CRM 和 git 的“正确方法”？我试图通过代码而不是 GUI 查找有关关系和字段更改的文档，并找到了许多不同的说明和方法......有一种正确的方法吗？

谢谢。

Answer 1

• 正如其他人指出的那样，您想使用.gitignore文件来忽略某些文件和文件夹，例如/*.log /custom/working,/cache和/upload. 还生成了/custom/modules/中的.ext.php文件，并且可能不会被 git 跟踪。
• 如果您使用 Studio 添加或更改字段，您还必须编写转储/加载数据库表内容的钩子fields_meta_data（提示：我建议使用 mysqldump--skip-extended-insert --skip-dump-date来避免 git 不可维护的转储格式）。作为替代方案，您可以将它们转换为vardefs
• 如果您还想忽略// created: <timestamp>行，则必须查看git-attributes/filters并且可能会遇到一些麻烦。如果您为此找到了可行的解决方案 - 请随时分享:)

Answer 2

并不是那么糟糕。多年来，我一直在为 Sugar 使用不同级别的 Git 和 SVN 管理。

这是我通常开始使用的模板 .gitignore：

# Ignore Everything
/*

# Except .htaccess and Config files
!.htaccess
!config.php
!config_override.php
!.gitignore

# Except custom
!/custom/

# but do ignore some of custom and Extensions stuff
/custom/backup
/custom/blowfish
/custom/history
/custom/index.html
/custom/workflow
/custom/modulebuilder
custom/modules/Connectors
/custom/modules/*/Ext
/custom/application/Ext

# and do track custom modules
!/modules/
/modules/*
!/modules/org_MyModule/

确保您手动跟踪最后一个部分。创建模块时，将其添加到该列表中。

如果你最终修改了核心文件，无论是为了修复错误还是增强（你应该尽量避免），你可以明确地将它们添加到你的 .gitignore

我最终遇到的最大问题是config.php和config_override.php。根据您的环境设置，这些并不是那么糟糕，但是site_url参数需要根据系统的 URL 进行更改，因此有点像 PITA。不过不要认为你可以只跟踪其中一个，因为 Sugar 的配置更新过程可以定期且有些不可预测地重写它们。

至于每次更改都会导致数十个文件更改的说法，是和否。这取决于一点，但我肯定见过它。您可以做的一件事是确保您已禁用不使用的语言。我曾参与过一些项目，它们正在跟踪组织中没有人发言的数万个语言文件。只有英文。我们将 Sugar 配置为不生成这些文件，而我创建的删除这些文件的差异太大，以至于我们的 GUI 差异工具无法显示它。

生产中的数据库或工作室更改怎么样？

轻松是最大的困难。您可能知道，Sugar 将字段信息存储在vardef文件和数据库表中fields_meta_data。

根据您的开发/部署设置，您可以通过几种方法之一解决此问题。我把我看到的一些概述一下

1. 每晚备份
   • 数据库模式
   • fields_meta_data
   • 产品目录、产品类别表
   • 用户表（但擦洗了 user_hash 数据）
   • 电子邮件地址表，但仅适用于用户

这种方法允许生产的开发匹配非常好，但会清除一些敏感数据而不包括不必要的数据。缺点是需要使用自定义脚本来 (1) 处理备份和 (2) 处理您的开发。备份的环境下载

2. 一个频繁的 CRON 驱动脚本，用于mysqldump将关键表（例如config, fields_meta_data, users）备份到单个文件，然后检测“实际更改”（例如配置为忽略空白时间戳的差异），如果找到它们，则将这些文件提交给 master。

您可以将其与一个类似的脚本配对，该脚本监视git status生产中的输出；我还看到Inotify用于此目的。当发现这些更改时（再次在生产中），它们会自动提交给 master。

一旦完善，此方法将更加自动化，如果您的一位业务经理在 Studio 中进行更改，甚至会收到通知。当您开始提交本地开发更改时，您会注意到您的 master 与 origin/master 不同，您可以在那里处理潜在的冲突。