{"id":11339,"date":"2008-08-19T03:50:39","date_gmt":"2008-08-19T00:50:39","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=11339"},"modified":"2008-08-19T03:50:39","modified_gmt":"2008-08-19T00:50:39","slug":"sugarcrm-deployment-efforts","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2008\/08\/19\/sugarcrm-deployment-efforts\/","title":{"rendered":"SugarCRM deployment efforts"},"content":{"rendered":"\n

Since we started working on SugarCRM<\/a> in the office, one of the hardest tasks that we had was solving the deployment issue.\u00a0 On one hand, SugarCRM comes with some really nice GUI tools, such Studio<\/strong> and Module Builder<\/strong>.\u00a0 On the other hand, the system is large and complex and should be developed and tested in a separate, non-production environment.<\/p>\n

We’ve spent a lot of effort over the last couple of month trying to solve the puzzle.\u00a0 The problem is that there is a tricky combination of files updates and database changes, some of which can be just copied over while others have to be executed from the destination machine’s administration.<\/p>\n

So, what we did first was complete separation of environments.\u00a0 Each developer had his own machine on which he could install and configure as many instances of SugarCRM as he saw fit.\u00a0 Also, each developer had a separate branch in the Subversion, so that he could work on his own stuff without being afraid to run into conflict with anyone.<\/p>\n

After that, we created a development server with a checkout of common trunk.\u00a0 For extra insurance, we did a checkout from a system user, who does not have any write permissions in the repository.\u00a0 In this case, even if someone will accidentally try to commit from the development server, we would be sure that it fails.<\/p>\n

Now, each developer had to merge his changes into trunk, and then test them on the development server.\u00a0 This procedure is very similar to the production deployment and consisted of two parts.\u00a0 Firts part was updating all the relevant files (a bit more on this in a moment) with svn update<\/em>.\u00a0 Second part was logging into SugarCRM and doing Admin -> Repair -> Quick Repair and Rebuild<\/em>.<\/p>\n

The graphical tools that come with SugarCRM are powerful, but a bit confusing.\u00a0 The biggest confusion for me was (and maybe still is) between Module Builder and Studio.\u00a0 Studio can be used to customize core modules that are shipped with SugarCRM.\u00a0 The results of these customizations are stored in custom\/modules<\/em> directory, and when loaded into the database, can be observed in _cstm tables (for example, accounts_cstm<\/em>).\u00a0 This is where new custom fields and things like that are going.\u00a0 Module Builder is a tool which can help you customize existing modules or build the new ones. The confusion here is because both of these tools can be used to do the same things.\u00a0 But with Module Builder you’d be working closer to the core system and modifying “original” functionality.\u00a0 You can build your own modules too, by the way.\u00a0 The results of the Module Builder work with go into modules\/<\/em> directory, and changes in the database will take place in the original tables.\u00a0 One thing to remember though, is that you’ll need to push Save & Deploy<\/em> button every time you are finished with changes in Module Builder.\u00a0 This is like compiling and building a module.\u00a0 If you forget this step, then your module will hang in its source somewhere around custom\/modulebuilder<\/em> directory.<\/p>\n

Another thing to keep in mind is the sillyness of the machine trying to figure out another machine.\u00a0 Meaning that Subversion will often have issues trying to figure out the changes from the last commit, and these issues would be often caused by a lot of automatically generated code by SugarCRM.\u00a0 In most of these problematic cases, Subversion will just merge the changes, and this would often result in a broken system.\u00a0 I’ve found at least two reasons behind these: small context size that Subversion uses (3 lines or so) confuses it sometimes, bringing it to a wrong place in the file to do the merging; and rather messy automatically generated stuff by SugarCRM – unnecessary reordering and mixed (DOS and UNIX) ends of lines in a single file.\u00a0 These problems are mostly related to vardef files (vardef.php and anything *def.php) and language dictionaries (anything with *en_us*php, or whatever your locale is).\u00a0 The solution we are using at the moment is simple, although a bit heavy on the manual work – instead of merging the changes and checking them every time we simply remove old versions of files and add the new ones in two separate commits.\u00a0 These way Subversion treats the files as completely different ones and real removes and re-creates them instead of trying to merge.<\/p>\n

We follow exactly the same procedure now to deploy to the production server.\u00a0 We just merge code from trunk\/<\/em> to branches\/stable<\/em> , commit, then update the files on the production server, and then do the Quick Repair and Rebuild<\/em>.<\/p>\n

The thing about Quick Repair and Rebuild is that it takes the update definitions of your forms and layouts and rebuilds compiled templates.\u00a0 It also compares the structure of the database with the update definitions in the files and, if needed, updates the database scheme too.\u00a0 Sometimes you’d get an error of missing table (usually custom tables with _cstm suffix) – just create an empty table manually.\u00a0 Put a couple of standard fields like id_c, date_modified, and date_entered.\u00a0 After that, field modifications should be OK.\u00a0 In case you run into a problem with updates to several fields at once, make sure that SugarCRM put a semicolon (;) at the end of each SQL statement that it shows you in a popup window.\u00a0 For some weird reason, sometimes it just works, and sometimes it tries to execute several queries without separating them one from another.<\/p>\n

So far the setup seems to be working for us just fine, but I’m sure that we’ll have a few changes here and there.\u00a0 I’ll let you know once we find any better way of doing things.\u00a0 In the meantime, here are some links that might help your development efforts:<\/p>\n