Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

My PHP Development Environment

DZone's Guide to

My PHP Development Environment

· Web Dev Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

I’ve been working in PHP at my new day job and despite the usual exclamation that comes with stating that (yeah, I hear you screaming “PHP!? Yech!!!”) I’m actually quite happy with a change in pace and the development environment I use. I like it enough I thought I’d share it. :)

Vagrant

Vagrant is a godsend for virtualizing server environments that often have different configurations. Since a lot of servers I work on can often have different and conflicting setups I’ve been setting up vagrant boxes for each of my projects with puppet manifests that tailor the specific settings those projects require. An added bonus is that I can also populate the virtual machine’s database on boot.

I also setup a host-only ip address in the Vagrantfile and edit my /etc/hosts file to resolve against it, usually some domain like local.example.com or the like. The benefit of all this? I can checkout a project, type vagrant up and BOOM! I can navigate to http://local.example.com and see a perfectly usable, runnable instance. And with /var/www/ mapped back to the project directory on the machine I can make changes and see them on the vm. It also creates a nice local environment to test out my capistrano deployment scripts.

Capistrano

It’s not much of a secret that I’m a big fan of capistrano and amusingly have never used it to deploy a rails application. I just find it to be the most easiest to use tool to painlessly deploy projects to remote servers and be able to rollback when I screw up. All with one command. In fact, I’ve even performed production rollbacks from my mobile phone while on a trip.

The big gain here is that capistrano checks the project out to a timestamped directory, does any softlinking that needs to be done (for example uploaded files and content not stored in version control) then finally updates a link for a current directory to the newly deployed application. This allows for a pretty seamless switchover with practically zero impact to end users.

Of course, capistrano by itself isn’t enough to make my deployment toolbelt complete. Since we’re working with a non-rails app, we need to remove the “railsness” of capistrano. railsless-deploy works well here by stripping out the more rails related tasks. I also use multi-stage deployments are used to deploy to staging and production. Finally, after the app is deployed (but not yet live as the symlink hasn’t been updated) my capistrano script runs composer on the app to gather dependencies.

Composer

When I last worked in the PHP world (2006!) PEAR was pretty much the de facto dependency management system, and it was “meh”. Not bad, but not as good as rubygems, pip, or npm. Imagine my joy last week when I discovered composer, which is heavily based off of ideas in npm. With composer I can define a composer.json file that defines all the dependencies my application has, whether they’re composer enabled or not. I’ve used this with composer based packages, pear, github projects, etc. Here’s a sample of one from a current project:

{
    "name": "zendframework/skeleton-application",
    "description": "Skeleton Application for ZF2",
    "license": "BSD-3-Clause",
    "keywords": [
        "framework",
        "zf2"
    ],
    "homepage": "http://framework.zend.com/",
    "require": {
        "php": ">=5.3.3",
        "zendframework/zendframework": "2.0.0rc7@dev",
        "doctrine/common": "2.2.3"
    },
    "autoload": {
      "psr-0": {
        "Zend":"vendor/zendframework/zendframework/library/Zend",
        "Album":"module/Album/src"
      }
    }
}

Basically I just run “composer install” from the project directory and all the dependencies are downloaded and placed under ./vendor. A nice addition is that it also handles psr-0 autoloading as well, which is a separate topic in its own right. :)

Jenkins

FInally, I tie all this together with Jenkins by using it to automatically check out projects on commit, run PHPUnit and php lint on the project, then ship it to staging if all goes well. I usually leave the production deployment to be manually kicked off but I can also automated that as well if I wanted to. If you’re not already using jenkins, why aren’t you?

That’s about all for now. In a nutshell I guess I could say PHP development isn’t great due to being very verbose but it’s tolerable. Knowing tools from other stacks goes a long way in making it fun. :)

 

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:

Published at DZone with permission of James Carr, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}