The document outlines best practices for PHP deployment, focusing on the PHP application lifecycle and the various environments from development to production. It discusses the need for bridging gaps between developers and system administrators while ensuring controlled, repeatable processes that minimize downtime. Additionally, it introduces Zend's work on a new deployment solution still in prototype, emphasizing the necessity of user feedback.

1. Shahar Evron | Zend Technologies
Best Practices in
PHP Deployment

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. 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. Part I: Broken Cycles

5. The Development Lifecycle

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. 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. 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. 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. Bridging the Gap
developers sysadmins

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. 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. 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. 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. 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. Part II: The Bridge of Death

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. 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. 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. 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. 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. 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. 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. Part III: Deliberate Ambiguity

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. 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. 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. Questions? Feedback?
●
Find me at the Zend booth
●
Email me: shahar.e@zend.com
●
IRC: #zftalk, #zendserver @ FreeNode

29. Thank You!