For many PHP shops, moving code from development to production sounds like it should be easy, and it can be. The problem is that sometimes deployment strategies can result in longer downtime than is desired, rollbacks can be difficult or there can even be uncertainty on what is actually in the production environment. Watch the webinar at http://www.zend.com/webinar/Server/70170000000bHsS-webinar-guidelines-for-deploying-php-applications-20100617.flv and read the blog posts at http://www.eschrade.com/search/tag/id/deployment.

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

3. If you have a question you can Type in the Q&A panel Follow us! Zend Technologies http://twitter.com/zend http://twitter.com/kpschrade (me!)

4. Agenda What we will be talking about Deployment->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

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

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

7. 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

8. 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

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

10. 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

11. 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

12. 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

14. Do whatever it is that it’s supposed to be doing

15. Characteristics

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

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

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

20. 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 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 E.g. Invalidating the cache

21. 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

22. 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

23. Takeaways No need for copy-and-paste deployment No need for (S)FTP 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

24. If you have a question you can Type in the Q&A panel Follow us! Zend Technologies http://twitter.com/zend http://twitter.com/kpschrade (me!)

25. Get this information and all the examples at eschrade.com… once I’ve written it