Guidelines for deploying PHP applications

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!)