We are in the process of evaluating SuiteCRM and the question has come up regarding version control and deployment across a development / testing / production server environment.
So I am wondering how other developers handle this when changes can be made from inside the application as well as the code base.
We use Git
Create an empty repository with a master branch and add your initial installation to that. We then create a develop branch and any code level changes are made to this. Once were are ready to deploy to a clients server or whatever we merge develop back into master and push use that to the sever.
However we use a pretty big git ignore file as there is a lot stuff in a sugar/suite installation that you don’t need in your git repository such as the entire cache folder etc…
Also when changes are made from inside the application we simply use git add -A to add any new files that are created then just commit the changes as normal.
In fact you could just check out the repository as it will have everything you need https://github.com/salesagility/SuiteCRM
Thanks for the reply. Sounds simple enough and shouldn’t be a hurdle.
Apologies for bumping an old thread, but I have an extension to this same question.
We are also creating a project based on CRM that will require considerably customisations. We also want to source control the CRM in Git. We will also have multiple environments. We will have multiple developers working on the project, possibly at the same time.
I am trying as architect to create the development environments and development workflows and I’m running into issues.
The main issue surrounds the CRM modifying itself when changes are applied via the UI. With a single developer this isn’t really an issue as they can make a change and commit the resulting PHP directory and a copy of a mysqldump. This will allow normal version control.
When you have multiple developers making changes on their own environments what scares me is the potential for database dump merges. If two developers add a field each to the same custom module and then edit various views and sub panels in studio, the resulting pull requests and the merges required will probably ruin my day.
As such we considered that the local dev environments could be sandbox only and when the developers have a clear idea of exactly what needs done they can apply those changes to a shared environment. Only that shared environment commits to git. The downside with this approach is that it is incompatible with the “Branch… commit… pull request… merge” workflow for code/change review we want to use. On the shared environment only one branch can be checked out at a time and so only one developer can work on it at a time.
I know SuiteCRM changes the schema when fields are added etc. To be honest I would not be ‘that’ concerned with merging simple schema changes. What I am less sure about is how much configuration data is stored in the database and how much change is likely to occur there. If “data” changes in the database are rare as a result of UI customisation then things should be easier. I am mostly concerned about two SQL dump files arriving with a large number of changes to merge in both configuration data and schema changes. (Note I intend to keep the test data very light in primary development and only fatten up the DB for performance and system testing).
Are there any suggestions, hints you guys can provide to help with this problem?
EDIT: How reliable is the “Repair Rebuild” for re-creating required database changes? is that a sensible option to manage them?
The only real database changes you need to worry about is in the fields_meta_data table where custom fields created by studio are added. The rest of the config changes are generally stored in the vardefs files and extensions. So when you do a quick repair and rebuild it will run the query’s to create the new fields and tables in the database. We dont generally have more than one developer working a single module. Multiple developers could be working on the same project but on entirely different parts of the project so there are not generally issue when merging in changes.
Thanks Andy. So you recommend just being smart and avoiding developers working in the same area.
I am thinking of doing two mysqldumps. One Schema only, one Data only with some excludes and committing them. Hopefully we won’t face merge hell.
So we have now been working this way for a month and we are still facing “merge hell” with every commit.
I can accept that the module builder stuff, as it is auto generated will always be a merge nightmare when two or more developers have even small changes within custom modules.
However… and my question to the SuiteCRM experts.
Regarding the Module Builder files, which of them are actually required to be kept and which are temporary files. I can see whole trees of duplicated code coming through in merges such as:
There seems to be 6 different copies of the custom modules build in Module Builder.
If we want to keep both the Module Builder version and a single deployed version, which of the above can we add to gitignore to limit the amount of file we are merging?
I’m not the best person to be responding to your question because I came here to learn how to do version control because I have not been in the past. My changes have been so minor, I’ve just been keeping copies of files (original and edited) so that when I do an upgrade I can cleanly get my changes incorporated.
HOWEVER… I can tell you this…
- SuiteCRM/modules/<custom_module_name> <- Very important is this is where much of your custom code should/would reside.
- SuiteCRM/custom/modules/<customer_module_name> <- Same as above, most of your custom code should live here
- SuiteCRM/upload/upgrades/module/<custom_paackage_nameDATETIME/ <-I personally ignore the entire upload directory, not sure if that is good idea or not.
- SuiteCRM/upload/upgrades/temp//SugarModules/modules/<custom_module_name> <- See previous note on uploads.
- SuiteCRM/custom/modulebuilder/packages/<custom_package>/<custom_module_name> <- Not sure, but it seems like this would be important for vers. control. Maybe not as critical if you export your builds.
- SuiteCRM/custom/modulebuilder/builds/<custom_package>/<custom_module_name> <- Again, not sure, but it seems like this would be important for vers. control. Maybe not as critical if you export your builds.
I also ignore the entire Cache directory, not sure if I should or not, but I do.