Managing SugarCRM Customizations in Git
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.
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.
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...
scp fields_meta_data.sql user@production:/home/user
mysql -u user -p database_name < fields_meta_data.sql
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.
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.