Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Best Practices in PHP Application Deployment

15,835 views

Published on

An overview of the challenges in managing the web application development lifecycle and how a correct deployment system can help. A few common deployment techniques are reviewed. In addition, some info on an upcoming Zend Server deployment feature.

Published in: Technology
  • My workflow for deploying php application include github + envoyer. Envoyer has made auto deployment much easier for me. Here is a tutorial on that: https://www.cloudways.com/blog/php-laravel-envoyer-deployment/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I don't like presentations where I don't learn something..
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • you can skip the first 6 minutes of the mp3
    (http://devzone.zend.com/article/13217-ZendCon-Sessions-Episode-042-Best-Practices-in-PHP-Application-Deployment)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Best Practices in PHP Application Deployment

  1. 1. Shahar Evron | Zend Technologies Best Practices in PHP Deployment
  2. 2. Agenda ● The PHP Application Lifecycle ● What problem are we trying to solve? ● What are the current ways to solve it? ● A little bit of what Zend is working on ● Hopefully more discussion than talk ● This is what I've learned ● Maybe you know better
  3. 3. A few things about me... ● Shahar Evron (‫ֹן‬‫ו‬‫ְר‬‫ב‬ֶ‫ע‬ ‫ַר‬‫ח‬ָ‫ש‬) ● Working with PHP since 2002 ● In Zend since 2005 ● “Technical Product Manager” ● I'm not a programmer, I decide stuff ;) ● I get to play with cool technical sh!t ● My boss is in marketing (but I do not talk about it) ● I also try to contribute to Zend Framework
  4. 4. Part I: Broken Cycles
  5. 5. The Development Lifecycle
  6. 6. Development ● Purpose ● Provide developers with an environment to work in efficiently ● Characteristics ● Should be similar to production, though it usually isn’t ● Often more open security ● Error reporting and debugging enabled ● Local or semi-local to the developer
  7. 7. Testing ● Purpose ● Provide a stable environment to test functionality on ● Characteristics ● Continuous Integration could be included ● Environment closer to production setup ● Stable - no development occurs, only testing ● Test a specific code snapshot / tag ● Developers should not do the testing
  8. 8. Staging ● Purpose ● To test your deployment process / scripting ● Not your code! ● Characteristics ● A specific version is pushed after it passes QA ● No developer access! ● Very restricted outbound networking ● Mirrors production as best as possible
  9. 9. Production ● Purpose ● Do whatever it is that it’s supposed to be doing (duh) ● Characteristics ● Developers do not have access ● Deployment should be done without requiring developer input ● Tuned for high performance and security
  10. 10. Bridging the Gap developers sysadmins
  11. 11. What Are We Trying To Solve? ● Bridge the gap ● And be able to safely cross the bridge a few times a day ● Avoid technical difficulties along the way ● Controlled, repeatable process ● Zero downtime ● Cluster-wide consistency ● Planned recovery
  12. 12. Application Considerations ● Build Semi-Portable Applications ● Separate configuration from code ● Configuration can be environment aware ● Zend_Config is good at this ● Environment should be set outside code ● Default to production configuration to reduce risk
  13. 13. A Quick ZF Example: config.ini [production] log.verbosity = WARN php.display_errors = off php.error_reporting = E_ALL & ~E_NOTICE db.adapter = PDO_MYSQL db.hostname = myhugedbcluster.myapp.lan db.dbname = productiondb [testing:production] log.verbosity = NOTICE php.error_reporting = E_ALL | E_STRICT db.hostname = mytestdb.myapp.lan db.dbname = testingdb [development:testing] log.verbosity = DEBUG php.display_errors = on db.adapter = PDO_SQLITE db.dbname = localdev.sq3
  14. 14. A Quick ZF Example: index.php /* Set the application environment */ if (! ($environment = getenv('MYAPP_ENV'))) { $environment = 'production'; } /* Or, in enigmatic PHP 5.3 shorthand style ;) */ $environment = getenv('MYAPP_ENV') ?: 'production'; /* Load configuration file */ $config = new Zend_Config_Ini($configFile, $environment); /* Do the usual stuff... */ Zend_Registry::set('config', $config);
  15. 15. A Quick ZF Example: httpd.conf Alias /myapp-dev /home/shahar/Sites/myapp-dev/public <Directory /home/shahar/Sites/myapp-dev/public> Order allow,deny Allow from all AllowOverride All # Set the application environment SetENV MYAPP_ENV development </Directory>
  16. 16. Part II: The Bridge of Death
  17. 17. Requirements ● Supports upgrading existing code ● Can roll back in case of a blowup ● Can deploy to different environments ● Reproducible deployments ● Minimal downtime ● Minimal in-house development ● Maximal consistency
  18. 18. Solution #1: rsync ● Benefits ● Widely available and used by *nix sysadmins ● Incremental pushes ● Drawbacks ● No deployment hook scripts support ● Basically a file-system copying solution ● Does not understand versioning or context ● Incremental pushes
  19. 19. Solution #2: Source Control ● Benefits ● Easy, fits in the workflow ● You already use it (god I hope you do...) ● Supports versioning, pre/post deploy hooks ● Drawbacks ● Requires production access to entire source repository (security) ● Usually no context understanding ● Developers cross over to the admin side
  20. 20. Solution #3: PEAR ● Benefits ● Designed for PHP, maintained by PHP folks ● Very scriptable ● Understands PHP context ● Cross Platform ● Drawbacks ● Format not 100% ideal for app deployment ● Available tooling is restrictive ● Admins cross over to the developer side
  21. 21. Solution #4: OS Native ● Benefits ● Works natively with server provisioning ● Your sysadmin will buy you a beer ● Can describe OS-level requirements ● Lots of problems solved by someone else ● Drawbacks ● Environment specific ● No tight PHP integration ● Will require quite a lot of “build” knowhow
  22. 22. Solution #5: Capistrano ● Benefits ● Clustering Support ● Designed for Web Deployments ● Drawbacks ● Designed for RoR deployments ● Will require some manual scripting to support PHP ● Usually has tight SCM coupling
  23. 23. What should I use? ● Where are you on the maturity scale? ● How much control do you need? ● How portable do you need to be? ● Can you afford downtime? ● Can you afford a non-scalable solution? ● Can you afford in-house maintenance?
  24. 24. Part III: Deliberate Ambiguity
  25. 25. So what's up with Zend Server? ● Zend is working on a deployment solution ● You have seen some of it in today's keynote ● IT'S NOT READY YET! ● I cannot say when it's going to be ready ● It's a prototype, lots of things may change ● I want your feedback!
  26. 26. Zend Server Deployment ● Based on an open, simple package format ● Basically a zip/tarball with an XML descriptor ● You can create it using common tools ● Package includes and defines: ● Code, hook scripts ● Configuration, dependancies ● Required and optional parameters
  27. 27. Zend Server Deployment ● Synchronized cluster deployments ● Two-step stage / activate workflow ● Apache / IIS integration ● Will define vhost / alias as needed ● Upgrades ● Rollbacks ● A simple switch-back to the previous version which is already staged
  28. 28. Questions? Feedback? ● Find me at the Zend booth ● Email me: shahar.e@zend.com ● IRC: #zftalk, #zendserver @ FreeNode
  29. 29. Thank You!

×