Creating a staging environment is specific to your production environment. There is no magic solution that works in every situation. But most cases follow a similar pattern, and I'll cover all the key points as we go along. It's fair to assume that most people deploy their apps with some kind of versioning tool (like GIT). [...] Besides GIT, you have to think about the languages, software, and "special" features your production servers offer.

All of the commands and configuration files you'll need to make the automatic setup work are included in the article. It's based on a Debian (Squeeze) base image and uses packages to install the needed software. They also install other PHP extensions like mycrypt, GD, curl, APC and database support (MySQL, SQLite and Postgres). They help you get Apache set up to serve the application and work with git and its hooks to push the code and run Composer.

I've been developing PHP apps for over eleven years. PHP remains 85% of what I do on a daily basis. Over that time, I've tried lots of WAMP packages to run sites on my Windows computers and, since going Mac, I've used the native Apache install that comes with Mac OS X. Six months ago, I decided to try out a remote VPS for my development. The results have been so good that I forget the pain I used to experience on a daily basis doing it any other way.

He walks you through the entire process (you'll need a VPS first) - it uses an Ubuntu-based setup, but the instructions are relatively easy to port over to other distributions. He helps you set up the system's hostname, install all needed packages/tools and generate the wildcard self-signed SSL certificate. Finally, he shows how to configure Apache's virtual hosts and set up a basic site.

Now-a-days, you have frameworks that need to be setup [as a part of your environment], include paths that need to be changed, modules that need to be installed, web servers that need to be configured for your routing, etc. Then you might not just have MySQL, but Redis, Mongo, Couch, Memcached, Postgres, or any other dozen other servers. Then in Production you might have load balancers, multiple web servers, clusters of databases, and the list goes on. Simply put: web development environments are complex.

He introduces Vagrant and talks a bit about how it helped them with the setup and configuration of two new remote developers they had limited contact with. After some initial quirks, Vagrant made it simple for them to get up and running with new environments in a day.

If you use a framework such as Symfony2 this problem is solved for you, but if you aren't using any framework you probably need to solve it in one way or another. [...] The solution that I like for this kind of problem [with having different environments] is to use apache's environ variables. We inject the environ variables in the virtual host configuration.

He shows how to add a variable to the VirtualHost section of your Apache config, how to use the getenv function to retrieve its value and how to use it to select a configuration set. This method can also be applied to other kinds of information including settings you may not want to hard-code directly in you app (like possible database credentials).

So you're all excited to try out ZF2. You clone the skeleton, install some modules, maybe even follow Rob Allen's excellent ZF2 tutorial, and finally, start building your application. Now, if you're a former ZF1 user or refugee from another framework, you might be troubled at this point by the fact that, at first glance, ZF2 doesn't appear to take into consideration environment-specific configuration values (e.g., development, testing, staging, production). Luckily, this is not the case!

He includes a bit of sample code showing how you can use a simple getenv call to pull in the value from an "APPLICATION_ENV" environment variable and put it into an autoload path.

A lot of the time when we're developing applications they're likely to be based around customizing or extending an existing application, such as WordPress, Joomla, Oxid eSales et al. In these cases, there's a clear set of rules and guidelines to work with. [...] But what about when we're building our own applications, bespoke ones, from scratch. [...] What do we do then? How do we set up a great software development methodology or set of processes to ensure that we develop cleanly, clearly and efficiently? In today's post, I'm going to go through 4 areas which can serve as a solid and reliable basis for us to do just this.

The four key elements he sees are:

• Organized Development Environment
• Organized Deployment Approach
• Organized Testing Approach
• Have a Professional Bug/Issues Database

For each of these elements, he describes some of the methods and tools that can help make them possible.

These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

In case you've been living under a rock for the past couple of years, Vagrant is the latest development in easily controlled virtualised environments. [...] Vagrant automates creation and provisioning of virtual machines within VirtualBox via the command line, whilst also allowing for easy distribution and reuse across multiple projects. In this article, I'm going to look at how it can make life considerably easier when dealing with development environments.

Included in the post is just about everything you'll need to get started using this powerful tool:

• A link to Vagrant images
• A guide to the VagrantFile
• the Provisioning process
• Interacting/Controllig the Vagrant VMs

He also includes a basic setup of an environment (with the Vagrant config to create it) and an example of using Puppet to provision the Vagrant VMs.

Doing development on multiple projects can be a burden from time to time. One project would be running on PHP 5.3, while another still needs 5.1. Sometimes you need a MySQL server, while on other occasions, you need a NoSQL solution like couchDB or MongoDB together with all kind of gearman functionality. This article shows you how I've setup such a development platform that allows you to quickly create new projects, and still maintain flexibility when you need it.

He uses VirtualBox with either a Debian or CentOS installation as a base platform. He uses Vagrant to set up and configure the machines to make setup almost automatic. He still has to go in and configure a few things like the VirtualHost and DNS settings for the site/application he's working on. Next up is setting up the tools he uses, specifically XDebug and setting up his editor of choice (PHPStorm) for remote debugging.

I've been playing around with Sublime Text (because of the awesome vim bindings) and was thinking about why do I always have to be logged into the remote server to do my work. Normally I connect using SSH, then attach to my tmux session and then fire up vim. This is okay but it lacks a certain elegance in it's approach. [...] What I'm chafing against is having to deal with multiple environments all the time to get my work done.

His ultimate goal is to be able to update and commit code without having to be logged into the remote server - essentially to replicate the local development experience regardless of the underlying technology. Have a suggestion or a method that's currently working for you? Leave him a comment!