Editor’s Note: Please check out the note from Heather after the attachment on a update to this document.
At SugarCon this past spring, Heather Johnson from the Robin Hood Foundation did an excellent talk about her work in developing a Systems Development Life Cycle ( or SDLC for short ) for the SugarCRM instance in use by the group. It is a very customized instance with lots of moving parts, and with the limited documentation and use cases out there for such an endeavor, she put together a guide detailing the strategy they used to manage it. It’s a great document and provides a concise and complete strategy to properly manage software development on the Sugar Platform.
A quick update on this that might be helpful: We have found that, using the method described in the article above, we often have to commit changes that result from running a Quick Repair and Rebuild. Not only is this annoying but it can potentially create merge conflicts. For example, running a QR&RB in Production may modify files that have to be merged backwards in the lifecycle to SUGARDEV and though one assumes that the same changes would have been made to the same files when one ran QR&RB in SUGARDEV a few minutes earlier, the world just doesn’t always seem to work that way – and who wants to deal with the overhead of pulling down QR&RB-related changes anyway? So we have made the following change in policy: In addition to ignoring the cache, we now ignore all files that are automatically generated by a QR&RB. No such files are tracked in the index. Since many of these auto-generated files are critical to Sugar’s operation, the upshot of this change in policy is that you now *have* to run a QR&RB each time you promote changes up through the lifecycle that would require it – not just in your sandbox. This has the effect of taking the changes made to tracked files, and using them to take care of any modifications that are needed to the auto-generated files. Since no auto-generated files are tracked in the index, there is no more worry about seeing such files show up, unwanted, in a git status. Here is a quick how-to on getting rid of these auto-generated files from your repo (assuming you started out by tracking them and that you are doing something very like what is described in the attached article):
On SUGARDEV and on your sandbox, you should replace your current .gitignore file with the following:
../*.log ../cache/ ../config.php ../config_override.php ../custom/themes/default/images/company_logo.png ../custom/application/* ../custom/modules/*/Ext/*
(Note, we don’t track company_logo.png because we like to make cute little logos for the different environments we’re developing in)
Still on SUGARDEV:
1. Remove the unwanted files from your index (but leave them intact in the working directory):
git rm -r --cached custom/application/* custom/modules/*/Ext/*
2. Update any branches off the main branch on DEV. First switch to the branch you want to update
git checkout //note, you may have to do a git checkout -f to force the checkout to occur as git sees that by switching branches it will be overwriting some working tree files no longer indexed in the current branch with files that are still indexed in yours. This should only be an issue once.
3. Then merge the MASTER branch into yours – this will remove all of the auto-generated files from the index associated with your branch
git merge MASTER
4. For any other active branches on SUGARDEV, repeat steps 2 & 3.
5. Re-run your permissions
sudo chown -R www-data.www-data /sugar/doc/root sudo chmod -R ug+rw /sugar/doc/root
on your SANDBOX:
6. Pull down the changes. On your sandbox, do:
git pull origin
After you do this, you should be able to run a QR&RB any time you want to in any environment and it will not modify the index or create files that need checking in. Once again, only files that are looked at as the *source* of the auto-generated files will be indexed.
Thank you to Steve Williams of AtCore Systems for this suggested change!