Best Practices in PHP Application Deployment

15,615 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!

×