Managing SugarCRM Customizations in Git

Posted 2012-08-04
Written by Matt Frost
Category code

The Problem

SugarCRM is a relatively complicated codebase when it comes to versioning customizations. The reason is because it was built to be easily customizable, there are a lot of things that happen behind that scenes that make managing customizations tricky.

GitIgnore

The .gitignore file is important here, as you might imagine. I've tried managing these every possible way under the sun, and this is really the only way I've been able to do it with any sort of success.

cache/
!cache/uploads
custom/working
custom/history
custom/modules/*/Ext/*.ext.php
custom/modulebuilder
Typically, you'll want to ignore everything else that isn't in the custom directory, what I've done is just not added it until I need it. Since we find we have to do some changes that aren't "upgrade safe", I'd typically suggest add those individual folders to the system when necessary.

Modules

I've kind of gone back and forth here, I've chose not to version the modules directory on my most recent project. If you aren't familiar with SugarCRM, modules are typically built through the GUI Module Builder process. When a new module is created a folder is generated in the modules directory, once this folder is here...it really doesn't ever change. Sugar provides the ability to export/import modules from system to system, so for moving a module that was created in a beta system to production; I think that's the best way to do it.

The Big Gotcha!

I was merging changes from a beta system this afternoon and I ran into the big gotcha. I knew about it before, but for whatever reason it didn't come to mind until 4:58. Once you have your new module, and you've pulled in all the new vardefs,detailview,editview and the like you still have sync the fields_meta_data in the database. A very large portion of the custom development is handled by files in the file system...however if you want your custom fields to show up correctly the table has to be copied. I don't know of a quick or automated way to do this... On the beta system...

mysqldump -u username -p databasename > fields_meta_data.sql
scp fields_meta_data.sql user@production:/home/user
An finally on the production side..
mysqldump -u username -p databasename > fields_meta_data_bkup.sql
mysql -u user -p database_name < fields_meta_data.sql
If anyone has other ideas, or ways that they do this...I'm all ears.

Why

So you might be thinking, building modules through the GUI, creating fields and changing layouts sounds really easy why not just do that process twice? If you have the ability to do that, go right ahead, that is very straight forward. Our developers don't set up modules in our instances through the GUI and our CRM Specialists that set them up don't want to do it twice; so this is how we've been doing it.

Conclusion

Having never run a CRM instance through version control, we had a pretty rough go of things on some of these projects. We had projects where we basically had the whole entire SugarCRM application version controlled. You quickly find that a lot of files change and tracking them isn't beneficial. If you track the custom/modules/*/Ext/*.ext.php files you will run into a conflict nightmare because every time you do a Repair/Rebuild (which you should do after completing this process by the way) the files that are generated have a comment inserted with date/time they were generated. There will be a merge conflict every single time.

It's a bit of a process, and I don't know how many people have SugarCRM beta/production systems that are setup quite this way. I found it might be helpful if I put this out there, by no means am I saying this is the only (or even the best) way to do it. If I'm doing something really dumb, please tell me. This is just another step along path of trying to work more efficiently with multiple SugarCRM systems.

Comments

There are no comments

Posting comments after has been disabled.