PHPNW 2010 - Developing Easily Deployable PHP Applications

Here’s the scenario: you’ve written a PHP application designed to run on Linux, Apache, and MySQL. Now you have a customer who wants to run it on Windows. Or using Oracle. Or they like Memcache instead of APC. How do you do it without sacrificing performance, stability, simplicity, and your own sanity?In this talk we’ll look at how we approached solving this problem at SugarCRM and what lessons we learned in the process.

People fear the cloudPeople can’t use the cloudPeople want to use different cloudsOur customer base reflects this ( 1/3 sugar cloud, 1/3 on site, 1/3 on other clouds )

User base is diverse, likes different offerings, and will move between them.Lots of choices ( Web Servers / OSes / Databases / PHP versions ) as well as config possibilitiesHave to cover lots of platforms; can rely on particular hardware or software being available.

Relate in picture, mention about balance for needed control and simplicity.Talk about how we made this a big deal in Sugar 6

Types of testing we useTesting is hard

Performance story about GNs; very particular to make go fastNeed to balance performance and configurability; make the performance choices that make the most difference, and enable ways for those working with your software to make more.

6.
Design code that works for these platforms<br />DB abstraction layer or ORM<br />Make sure PHP features you are using are supported across support matrix<br />Assume very little about the underlying system<br />Example: Treat file system as case-sensitive, and file writes are only in one area.<br />Detect what features the server has for you to use, have API to talk to them<br />Example: User cache ( APC, Memcache, Wincache, etc )<br />7/22/2010<br />@2010 SugarCRM Inc. All rights reserved.<br />6<br />

7.
Build and deploy!<br />We build all 3 editions of SugarCRM from 1 codebase<br />We add code tags around sections specific to a certain version.<br />To test under each different edition, developers can run the build locally<br />We also can tag in or out features on a per edition basis.<br />7/22/2010<br />@2010 SugarCRM Inc. All rights reserved.<br />7<br />Source: http://www.flickr.com/photos/eastcapital/4554220770/<br />

15.
What we do to help performance<br />Try to do the basic stuff<br />Avoid writing slow code<br />Caching, and lots of it<br />Combine, minify, and version JS / CSS / images<br />Keep SQL queries as simple as possible<br />Leave the rest to the Sys Admin<br />Provide configuration options to turn off heavy features<br />Enable the application to take advantage of it’s environment<br />Example: Using APC, memcache, Zend_Cache, wincache with little to no configuration<br />Provide best practices for various environments<br />7/22/2010<br />@2010 SugarCRM Inc. All rights reserved.<br />15<br />

17.
What are the lessons we have learned?<br />Define what you will support and to what extent<br />Write your code to be flexible to any environment<br />Make customizing, configuring, and extending your application not painful for users or developers<br />Test across your support matrix, using automation as much as possible<br />Focus more on best practices and general performance, let admins handle it from there.<br />10/9/10<br />@2010 SugarCRM Inc. All rights reserved.<br />17<br />Source: http://www.flickr.com/photos/dlanod/126386070/<br />