Sugar Project Control Best Practices

SugarCRM Best Practices

Post By: Shervin Hassanzadeh, Development Manager at FayeBSG

Sugar projects can get big, extensive and hard to manage. Here are some guidelines to keep larger projects on track.

Version Control

In order to keep track of changes and ensure the collaborative development environment is not getting in the way of having a clean code base, we keep our code in Version Control software.

Here are our recommendations on this structure and methodology.

Keep Master Clean

Keep a copy of the working version of Sugar code in the master branch. Utilize capabilities like tags to keep track of your versions.

Fork Out

No development should be done on the master branch. Developers should have their own accounts and fork the main repo when they want to work on the project. The fork’s main branch should be updated on a regular basis with the latest code in the master repository.


Use branches extensively. Try to tie in your branches with your ticketing/project management system, that way back tracking the development processes are easier. Use meaningful branch names e.g. {TicketNumber}_{BriefFeatureTitle}
If the ticketing system is setup correctly you can create the branches based on the stories.

Commit Frequently

Each commit should have the following characteristics:

• Code that is committed should be complete and tested.
• Each commit should have a meaningful commit message
• Tie the commits to project tracking tickets. For example, if you are working with bitBucket and JIRA all you need is to do is to start your commits with the ticket number.

Mange Pull Requests

All the changes to the main master branch should be through a “Pull Request”. Try to stray away from direct updates to the master branch of the main repository at all times. That will allow a second round of code review and central place for filtering the updates.


When dealing with live systems the following setup will give both the development team and the client a great environment to work on the product while always keeping the application running for the end users:

• Development Environment
• Staging/Testing Environment
• Production

Development Environment

Development environments usually exist on your developers local machine. They work off of a fork of the main repo and will have the code and features that are in the development process. There is no outside access required for this environment.

Staging/Testing Environment

Both the client and the development team should have access to this environment. Once the latest features passed the initial testing in the Development Environment, the code is pushed to the Staging Server for client testing. The code in this environment is usually a branch of the master that has the new features in it. The branch will change based on the current user testing plan. Once the user testing process is completed and the feature is approved, the changes from the staging will be pushed to the master branch and will become part of the active product.


Production servers will always have the stable version of the instance. Only the features that are approved from the staging server will be pushed to this branch. There are no direct code changes allowed to the production server. A regular update of the master branch should be arranged only to push the changes that are made through the applications UI to the main branch.