Are there any documented best practices for version control for SugarCRM v7.x?
## Sugar files we don't want# *.log silentUpgrade*.php upload/ cache/** custom/history/** custom/modulebuilder/** custom/working/** upgrades/** custom/modules/*/Ext/ custom/application/Ext/ portal2/config.js
Hi Francesca,
In addition to 'Best Practices for version control in v7.x?' , I would add 'Best Practices for development with IDE n v7.x?'
I did post a question to the community forum about 'Is there any tutorials and/or videos showing how to setup and debug SugarCRM 7.8.x + using either PhpStorm and/or some other IDE but no one has replied.
What do you use to develop SugarCRM with and do you have any links to help setup the environment. I know Sugar developers use PhpStorm but I am not able to find any' how to' help.
Thanks in advance,
Hi Delsugar,
I'm totally old school. I ssh to my development server and vi.
Same here and I am just as fast tracing through the code as my developers using their IDE
Drop a ".gitignore" empty file in your cache and upload directories to trick GIT to keep empty (blank directories). This way your whole platform except config.php is versioned.
FWIW - XDebug can work in VIM with breakpoints, variable inspection, pretty much all the standard features. If you guys need this let me know I can send a link.
Dear Michael,
It would be good if you can share the link with us, I'll be interested in using XDebug.
Best regards,
Enes
I'm a little late to the party but I thought I'd throw a few things in.
I do versioning on gitlab but it's a bit sloppy. First I create a <sugar root>/database folder and put a backup of the database there.
The I use 2 .gitignore files. One for the initial commit and then I switch to another for project work.
Initial commit: .gitignore Sugar Initial Commit ($4) · Snippets · GitLab
Working: .gitignore ($2) · Snippets · GitLab
Script I place in /usr/local/bin for downloading the two scripts above. Note it also does some other things like create .gitkeep files in the upload and cache folder. sugargetgitignore ($5) · Snippets · GitLab
So, while we're at it. Here's a script to reach into the config.php file and create a timestamped database backup. It is intended to be run from the <sugar root>database folder. It will also create a .htaccess file to ensure that nobody can download anything from that folder via the web. sugardbcreatebackup ($1) · Snippets · GitLab
To restore one of those backups: sugardbrestorebackup ($3) · Snippets · GitLab Note that for this one you have to pass the name of the backup file in as the first and only parameter. Also should be run from the <sugar root>/database folder.
This one actually takes care of the first two for you. You just run sugargetgitignore and it will ask if you want to install the initial .gitignore or the production .gitignore and then dowload the appropriate one. sugargetgitignore ($5) · Snippets · GitLab
I just have all of these scripts in my /usr/local/bin and then I can type sugar<tab> and get a list of them all if I forget their exact names.
Oh, yeah, the latest addition. sugarzip is to zip up a sugar folder into a timestamped .zip file with the same name as the sugar folder but it skips the upload, cache, and .git folder. So from the parent folder of the sugar installation you just run sugarzip mysugar and you get mysugar_2018-01-11_09_11_42.zip Sugar Zip ($15) · Snippets · GitLab
Sorry, a bit more than asked but I thought I would share.
-pat
However, in general, at Sugar Engineering we've standardized on Git and a variation of a Forking workflow that includes use of feature branches, etc, and the use of Pull Requests to contribute changes back to the "master" repository.
https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
It is a bit more complicated for us since we keep various parts of the Sugar application in different Git repositories (for example, sidecar framework, mobile, outlook plug-in, translations, etc.) so sometimes making a change requires coordination of changes made in multiple repositories.
For most CRM implementation projects, I've seen partners/customers check in the entire Sugar application into version control within a single repository. They make sure that each customer has their own repo, rather than just their own branch off a parent repo. This also makes managing access control and change management on a per-customer basis more sane.