An overview of the challenges in managing the web application development lifecycle and how a correct deployment system can help. A few common deployment techniques are reviewed. In addition, some info on an upcoming Zend Server deployment feature.

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!