Lukasz Kujawa has a new post to his site introducing you to deployment of your web-based PHP applications using the Phing build tool.

How many steps are required to deploy your software? Some people say it shouldn't be more than one. I'm little bit more relaxed about it so I would say two steps are still fine. If it takes more than two then most likely you need a build script. [...] Phing is a PHP project build system or build tool based on ​Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make. It use simple XML build files and extensible PHP "task" classes.

He shows how to get it installed via Composer and how to create a simple "build.xml" file with a few targets inside. He shows how to use the "build.properties" configuration file and how to set them from the command line if needed. He also includes details on doing database migrations using the "dbdeploy" tasks.

On NetTuts.com today Gabriel Manricks walks you through setting up a staging environment using Vagrant to install and setup a virtual machine running Apache 2 and PHP 5.4.

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.

In a new post to his site Luis Atencio talks some about one of the things many development groups strive for but have a hard time achieving - continuous delivery of their application.

In the rapid changing software world of today, companies and individuals have come up with many methods in order to minimize the time to market gap, i.e the time it takes for your idea to materialize in production. Specially in the very competitive world of mobile and web applications. [...] We want our Operations team to be able to deploy correct and tested code in a manner that is automated and not stressful. [...] However, there is a down side to this: while it is important to beat the market and be innovative, it is also equally important to do this with a process that allows you to have a reliable product release.

He introduces the concepts behind "continuous delivery" and includes an illustration of how the flow would commonly work. He also mentions some benefits to implementing this into your project's flow including easy auditing and versioning, quicker deployments and the creation of a simplified, unified deployment system across platforms/environments. It's not without its challenges, though, so there's a bit of discussion about those as well.

In a new post to his site Benjamin Eberlei continues his look at using various platform-as-a-service (PaaS) offerings for PHP available today and talks about using Composer with Windows Azure via its post deployment hooks.

It turns out that Azure Websites - to support other platforms that require compiling - actually has an extremly robust deployment system (as far as I understood its internals). If Composer fails during this step, the website will still be served from the currently running version and you don't have to face unexpected downtime. To actually run Composer as a post-deployment tool you have to do some manual work.

This manual work comes in the form of a special ".deployment" file included in the root of your repository that defines the command to execute (a custom script). Included there at the end of the post is the PHP code you'll need to put in this custom script to get the latest version of composer and then require the phar file for use later in your application.

Jeremy Cook has a recent post to his site showing how he set up Capifony and Jenkins to do continuous deployment with a Symfony2-based application (including a full recipe for the deployment).

It seems that many people talk about setting up a continuous deployment system but few actually take the plunge and make it a reality. I've recently set up continuous deployment for an API project at work and thought I would blog about how I got it all to work.

He starts by laying out the plan for the system and what it's intended to do (an excellent first step). This is followed by details on Capifony and what kind of advantages it offers for deployment. He shares the full contents of his "deploy.rb" file that includes the actual steps for the deployment including a git checkout, a Composer install, warming up the Symfony cache and restarting Apache. He also includes how they have it set up with Jenkins, having the build triggered when the main project's build completes successfully.

On DZone.com there's a recent article posted by Kasia Gogolek that walks you through the deployment of a web application with the Webistrano tool, a web UI for working with Capistrano. This follows the first article where they talk about the Webistrano installation.

Most of the applications I write, are PHP based, so all of my examples will be based on that assumption, but you can re-use the ideas mentioned for software written in any other programming language. The setup [in the example] discusses just the deployment to the test project. Deployment to the production will be similar, and by the end of the article, you should understand what differences it will require.

She walks you through the creation of a new project, an example of the contents of the "base.rb" configuration file and how to create the stages (environments) to deploy to. Next up is the "recipes" themselves - the configuration steps for the deployment process. In their examples they show how to set permissions, update a database, manage asset files and a bit more to get Plesk installed on a server.

The folks over at Fortrabbit.com have officially announced the opening of their cloud-based, PHP-focused hosting platform:

We do managed hosting for over 5 years - a business where reliability is one of the core values. And Platform as a Service is just a label for a modern approach of scalable hassle-free hosting solutions. This PaaS market is very young and still a changing category in the wide field of cloud hosting. Listening to customers and their needs will influence the way current services work.

They offer a "Bootstrap" service if you'd like to try it out. It supports PHP 5.4, APC, MySQL, Git integration, Composer support, SSH/SFTP access and DNS management. You can also add on memcache and SSL support if desired.

On the Fortrabbit.com blog, there's a new post looking at a system for multi-stage deployment at a high level, applicable to most of the tools out there.

This article targets new developers and developers which never had the chance working with multi versioned websites before. If this fit's you: Read it. Staging is a good tool in your belt you won't regret to know. [...] You, your co-developers, authors and whatnot using [staging] to prepare and test stuff which is to be released into production. In short: you do not perform open-heart surgery by coding directly on the production website.

He talks about the "stages" part of the "multi-stage" structure, mentioning the separation of purpose they provide and an example of a three level configuration (dev, staging, production). An optional fourth level can be added as well for testing purposes. There are some downsides to this approach, though: data synchronization, code deployment delay and complexity. There's also a mention of gitflow and how it could help make this environment easier to set up for your applications.

In this recent post Anthony Ferrara has a new post showing how he created a multi-version build system to make working with multiple PHP installs (different versions) simpler....with the help of Jenkins.

I've been using Jenkins to manage builds of my projects for a while now. This was fine for a while, but now that my projects need to support multiple versions of PHP, it left something to be desired. I wanted a system that could build against multiple versions of PHP. And more so, I wanted to be able to build against multiple compiles of the same version (different options, etc). This is how I built just such a system...

He gives an overview of the Jenkins system, the hardware and operating system that runs the server as well as examples of his "php-build" command to generate the different environments. He uses a modified version of the PHP template for Jenkins as a base.

On the MaltBlue.com blog Matt has posted four different keys he sees to making a good software development environment and make for happier developers (and managers).

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.