Guidelines for deploying PHP applications

Transcription

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 Zend Technologies Follow us! (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 Development Testing/QA Staging Production 5 Increasing Maturity of PHP Applications

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

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

13 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

14 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

15 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 Uses xinetd One option is to move the source tree prior to the rsync

16 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

17 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

18 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

19 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

20 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

21 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

22 If you have a question you can Type in the Q&A panel Zend Technologies Follow us! (me!)

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