1 / 28

Guidelines for deploying PHP applications

Guidelines for deploying PHP applications. By Kevin Schroeder Technology Evangelist Zend Technologies. About me. Kevin Schroeder Technology Evangelist for Zend Programmer Sys Admin Author IBM i Programmer’s Guide to PHP You want to do WHAT with PHP? Coming up

ronna
Download Presentation

Guidelines for deploying PHP applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Guidelines for deploying PHP applications By Kevin Schroeder Technology Evangelist Zend Technologies

  2. About me • Kevin Schroeder • Technology Evangelist for Zend • Programmer • Sys Admin • Author • IBM i Programmer’s Guide to PHP • You want to do WHAT with PHP? • Coming up • Race Ferraris on the weekend • My Honda has a dismal win record bit.ly/ksbook

  3. Follow us! • Zend Technologies • http://twitter.com/zend • http://twitter.com/kpschrade (me!) www.eschrade.com

  4. What does Zend do • Zend Framework • Zend Studio (8.0 in public beta 1) • Zend Server • Monitoring, • Code tracing (freaking cool!!) • Job queuing • HA Session Clustering • Zend Server Cluster Manager • Does all of that in a clustered environment

  5. Agenda • What we will be talking about • Development->Testing->Staging->Production • Rsync/SVN/PEAR/yum mechanisms • What we will not be talking about • Build tools (Phing, Maven, etc.) • Database versioning/deployment • Continuous Integration • MSI installs (Sorry MS folks, I really wanted to but, y’know, time) • Test-Driven Development

  6. Before we get started • Who here is a developer? • Who here is a system administrator? • Who here has an existing deployment strategy? • Who here has edited a file in production? • Who here has wished they didn’t?

  7. Application Stages Development Testing/QA Staging Production Increasing Maturity of PHP Applications

  8. Uptime!! Testing & Validating Environment Testing & Validating Application Distinct Dev Environments Maturity Benefit Where are you? Structure Increasing Maturity of PHP Applications

  9. Development • Purpose • To provide developers an environment to write their code • Characteristics • Should be similar to production, though it usually isn’t • Often more open security • Usually local to the developer, though not required

  10. Testing • Purpose • To provide a non-programming environment to test functionality • Characteristics • Continuous Integration could be included • Generally no development occurs, only testing • Developers should not do the testing, if possible • Restricted outbound networking • Use Zend Server Monitoring and Code Tracing to help reproduce errors

  11. Prepared for and handed off to System Administrators (the stuff we’re here to talk about)

  12. Staging • Purpose • To test your deployment process/scripting (not your code) • Characteristics • Developers generally do not have access, unless they are also the sysadmin • Very restricted outbound networking • Mirrors production as best as possible

  13. Change Control • A formal process used to ensure that changes are introduced in a controlled and coordinated manner • Protect against unnecessary changes introduced to a system without forethought • Requires documenting the release process • Software version number • Plans for rollback (tested? y/n) • Expected outage time • Customer impact • Done prior to doing anything in production

  14. Pre-Production (Optional) • Purpose • Test the code in the production environment without impacting customers • Characteristics • Not likely to have use in the cloud or large scale deployments • Deployed in production immediately prior to making it live • Test the application with production settings without customer interaction

  15. Production • Purpose • Do whatever it is that it’s supposed to be doing • Characteristics • Developers do not have access (as they might be tempted to fix something) • Deployment should be done without requiring developer input • Very limited inbound traffic – generally only the service that is being served. i.e. HTTP

  16. Application considerations • Build the application to be aware of different environments • Zend_Config_* is good at this • Do not set the environment type in your code • Environment variables can be placed in server config • It means that you won’t accidentally keep your development settings turned on in production • Make production your default environment • Keeps accidental data leakage to a minimum bit.ly/phpDepApp

  17. Deployment Option 1 – rsync • Benefits • Easy • Already installed on your system • Drawbacks • No deployment script can be run • Not integrated with either PHP or the OS • Rollbacks require rolling back the entire source server • Does not understand versioning • One option is to move the source tree prior to the rsync • Uses xinetd bit.ly/phpDepRsync

  18. Deployment Option 2 – Source Control • Benefits • Easy • You should already be using source control • Has versioning • Can have pre/post install scripts • Easy to do automatic deployments • Drawbacks • Do you want to put details on how to access your source code on your production box? • Requires that your source control is accessible from production • Deny access to .svn directories bit.ly/phpDepSVN

  19. Deployment Option 3 – PEAR • Benefits • Designed for PHP • Very scriptable • Natural for doing things like clearing a cache • Has a better understanding of PHP • Cross platform compatible • Drawbacks • Requires admins to be familiar with PHP code • Limited to PHP deployment • Available tooling is restrictive/build your own package.xml • Define standardized locations (www, library, etc.) bit.ly/phpDepPEAR

  20. Deployment Option 3 – PEAR Creating your PEAR Channel pear channel-discover pear.pirum-project.org pear install pirum/Pirum-beta vi /var/www/pear/pirum.xml <server>  <name>qa/pear</name>  <summary>OurOrg PEAR channel</summary>  <alias>helloworld</alias>  <url>http://qa/pear/</url></server> php ./pirum build /var/www/pear/

  21. Deployment Option 3 - PEAR Creating your PEAR package php ./build-pear.php pear package pirum add /var/www/pear/ HelloWorld-0.1.3.tgz

  22. Deploying your app pear channel-discover qa/pear pear config-set www_dir /var/www pear install helloworld/HelloWorld pear clear-cache pear upgrade helloworld/HelloWorld Roll Back pear uninstall helloworld/HelloWorld pear install helloworld/HelloWorld-0.1.3

  23. Deployment Option 4 - OS-based • Benefits • Easily added as part of your server deployment • Very cloud friendly • Admins already know how to use it • Can describe OS-requirements/dependencies • Downtime limited to actual install, not network transfer time • Drawbacks • Depends on environment • Any PHP deployment scripting needs to be deployed with the application and executed in %post hook bit.ly/phpDepYum

  24. Which should you use? • Need something simple? rsync • Need to deploy to multiple disparate platforms? PEAR • Need to deploy internally/with minimal developer input?OS (yum/apt) • If using the OS consider maintaining an internal “blessed” repository instead of depending on the distribution

  25. Continuous Deployment • Using automated deployment • Very tight end-to-end integration • Requires a lot of trust that the developers have a fully tested application w/ backend and frontend code • Probably more work to manage if you can count the servers in your production environment with your fingers • Could be beneficial but make sure you know what you’re doing • You will need to have several testing experts

  26. Takeaways • No need for copy-and-paste deployment • No need for (S)FTP (Kinda not good for deployment) • Have an easy rollback mechanism • Prepare for errors in deployment • Try to minimize the amount of scripting needed for deployment • Consider using VMs on anything important to keep downtime to zero bit.ly/phpDepAll

  27. More takeaways • Do not deploy to NFS/SMB (slow!) • Cloud computing is really good for code rolls • Creating disposable applications

  28. Follow us! • Zend Technologies • http://twitter.com/zend • http://twitter.com/kpschrade (me!)

More Related