We provide a brief synopsis of the challenges associated with applying version control to SugarCRM. While file-based versioning solutions (e.g., GIT, SVN) are widely available and free to use, decisions about what parts of the filesystem should be versioned and how to push file-based changes up through a multi-server lifecycle are not obvious. To complicate matters, changes to Sugar (such as the addition or modification of workflows and fields) sometimes result in modifications to both the database and the filesystem. Given that mainstream VCSs do not track database-level changes, what is the best methodology for tracking changes like these? We demonstrate how The Robin Hood Foundation has created an enterprise software development lifecycle solution (or SDLC) for Sugar incorporating VCS-based change-tracking with GIT, database-level change tracking, development protocols permitting scalable, remote and parallel work on the Sugar system, and business-facing change policies. Presented by Heather Johnson, Sr. Applications Manager, Robin Hood Foundation, at SugarCon 2011

1. SWEET CHANGE An SDLC Policy for Sugar Heather Johnson, Sr. Applications Manager The Robin Hood Foundation Wednesday, April 6th, 2011

2. Sweet Change: An SDLC Policy for SugarThe Robin Hood Foundation Founded in 1988, The Robin Hood Foundation targets poverty in New York City through the unique approach of applying sound investment principles to philanthropy. Robin Hood gives 100% of every donation to New Yorkers in need. It plays an active role in improving the effectiveness of the organizations it funds through Management Assistance programs and uses a Metrics-based approach to measure their success.

3. Sweet Change: An SDLC Policy for SugarAn Introduction to the Problem of Versioning in Sugar A Timeline

4. Sweet Change: An SDLC Policy for SugarSoftware Development Lifecycle (SDLC): What is it? A software development lifecycle (or SDLC) is the collection of processes and methodologies that govern how an application is created or altered. Goals of an SDLC include protection of an application’s integrity through change, effective requirements capture, stakeholder input and ownership, and provision of predictable, efficient timeframes for deployment. The Robin Hood Foundation’s SDLC Policy for Sugar consists of:

5. Sweet Change: An SDLC Policy for SugarSoftware Development Lifecycle (SDLC): What is it? A software development lifecycle (or SDLC) is the collection of processes and methodologies that govern how an application is created or altered. Goals of an SDLC include protection of an application’s integrity through change, effective requirements capture, stakeholder input and ownership, and provision of predictable, efficient timeframes for deployment. The Robin Hood Foundation’s SDLC Policy for Sugar consists of:

6. Sweet Change: An SDLC Policy for SugarSoftware Development Lifecycle (SDLC): What is it? A software development lifecycle (or SDLC) is the collection of processes and methodologies that govern how an application is created or altered. Goals of an SDLC include protection of an application’s integrity through change, effective requirements capture, stakeholder input and ownership, and provision of predictable, efficient timeframes for deployment. The Robin Hood Foundation’s SDLC Policy for Sugar consists of:

7. Sweet Change: An SDLC Policy for SugarTechnical Policy QA DB Dev DB Prod DB Gold Cpy Sbox 30 or triggered by pending Prod transport Sbox GIT GIT sugar (PROD) Developer, Partner, And Sugar support Branches sugardev sugarqa 60 60 Sbox Sbox SSH/SSHFS Refresh rate Push or Clone Dev cache QA cache Prod cache Externally hosted RH hosted

9. Tell GIT where you want your repository to reside (gitinit)

10. Tell GIT which files and directory to ignore (.gitignoreand gitrm, gitrm-r --cached)

11. Add your files to the repository (git add)

13. Checkout the branch (git checkout <name_of_branch>)

14. … or create and checkout the branch at the same time! (git checkout –b <name_of_branch>)

16. Make sure you either have a) a copy of the Sugar database at the destination or b) can configure Sugar to connect remotely to a database at the host.

17. Create an empty docroot your webserver can use.

18. Protocols for cloning

19. Clone your branch (gitclone ssh://username@host/path/to/remote/repository /path/to/local/docroot--branch <name_of_branch>)

20. Add files that are ignored in your repository (e.g., config.php, /cache, logos?)

22. Test in local, cloned branch

23. See if any changes impacted the database by checking Dev2Prod module. If so, move them up.

24. See what files have been modified (gitstatus)

25. Stage all modified files (gitadd –u)

26. Commit all staged files (gitcommit –a)

27. Push/merge changes committed locally into the origin. Note that GIT will not allow you to push to a branch that is currently checked out (gitpush origin)

28. Login to the DEV/Origin branch

29. Checkout your branch (gitcheckout <name_of_branch>)

30. Test in DEV

32. Clone that branch on your QA server

33. Copy production database to QA server

34. Perform pilot tests in QA

35. Backup database and file system on PROD

36. Create a PROD branch of the master repository

37. Clone that branch on your PROD server

38. Perform pilot tests in PRODgit clone Branch3 clone git merge git push or merge git clone QA branch clone git push or merge git clone PROD branch clone git push or merge

41. Dev2Prod can be “daisy chained” to manage changes among multiple environments

43. Prioritize new development

44. Meet with Sugar IT Team one week following deployments

45. Function as liaison between IT and Sugar users

46. Perform pilot testing

48. Changes deploy on a 60-day cycle

49. Changes that must be attended to mid-cycle are classified by urgency, impact to users and impact to cycle

50. Limit business user rights

53. It never hurts to make a backup

54. Limit the number of changes in a cycle

55. Manage expectations, maintain stability

57. Adrian Boerstra, Director Business Solutions, Intricity, LLC

58. SugarCRM