Software Deployment Practices

Found a good article on deploying software here.

http://guides.beanstalkapp.com/deployments/best-practices.html

Setting up Continuous Integration with Jenkins for PHP

Some useful links I found for setting up Continuous Integration using Jenkins.

Server installation

http://aaronbonner.io/post/4965561040/getting-started-with-jenkins-for-php
http://aaronbonner.io/post/8339092868/installing-jenkins-on-ubuntu

Plugins

http://erichogue.ca/2011/05/php/continuous-integration-in-php/

- Credentials Plugin
- SSH Credentials Plugin
- Git Client Plugin
- Git Plugin
- Coverage Complexity Scatter Plot PlugIn
- Clover PHP Plugin
- xUnit Plugin
- JDepend Plugin
- Static Code Analysis Plug-ins
- Checkstyle Plugin
- PMD Plugin
- Plot Plugin
- Violations
- HTML Publisher Plugin
- DRY Plugin
- PHP Plugin
- Violations
- DRY Plugin
- Restarting Jenkins

Database Table Names and and URL Structure

URLs

I regularly have to work with a host of different naming conventions.  For example, when dealing with an entity eg. Opportunity I will often find the table containing these entities named 'Opportunities' and a set of URL's for CRUD defined as

• /opportunities
• /opportunity/
• /opportunity/create
• /opportunity/delete/
• /opportunity/update/

With URLs I find it much easier to work with plurals for consistency so I don't have to mess around mapping plural spellings to singular:

• /opportunities
• /opportunities/
• /opportunities/create
• /opportunities/delete/
• /opportunities/update/

All the above URL's would map to a OpportunitiesController which would use a OpportunityService for interacting with the database.

Databases

On the flip side, I much prefer singular in the case of database tables.  My main reason for this is when working with Doctrine I don't have to add annotations to all my entity classes mapping the Opportunity entity to the opportunities table.  It also reads better when you have related tables eg. OpportunityMetadata table reads better than OpportunitiesMetadata.

This is just the way I do it, personal conventions are not important as long as they're consistent.

Set up remote PHP debugging on Ubuntu in Netbeans

This is the configuration I found works (after installing everything that's needed) to get remote debugging in Netbeans for a site running on an Ubuntu server with Apache2.

(/etc/php5/apache2/conf.d/20-xdebug.ini

zend_extension=/usr/lib/php5/20100525/xdebug.so
xdebug.max_nesting_level=2000

xdebug.remote_enable=On
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_connect_back = 1
xdebug.profiler_enable = 1
xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_name = cachegrind.out.%t.%p

You also need to set up a path mapping in Netbeans like this:  https://blogs.oracle.com/netbeansphp/entry/path_mapping_in_php_debugger

Restart apache...