This is a continuation from my previous post and overall the series on Continuous Delivery. If you haven't been following, that's okay, every topic is self-contained, so read along. The contents of these posts are taken from the book titled "Continuous Delivery" by Humble and Farley (resources below) overlaid with my own professional experience. In this article, we talk a bit more about Continuous Integration (CI) and some practices developers should follow to ensure a smooth environment.

He talks some about what "continuous integration" is and how much it relies on an automation of the process around your delivery of software. He mentions integration of testing (unit/acceptance/integration) and how it can help discover issues early. He includes a list of essential practices that come along with the idea of CI integration including:

• Don't check in on a broken build
• Keep a stable build at all times
• Anticipate being able to revert your changes
• Using TDD
• Distributed Version Control

He also recommends using any downtime (like waiting on a build to "go green" again) to take a few minutes away from the code - it can benefit you and your code.

Zend Server 6 is the ideal application platform for mobile and web applications, and this version brings a new level of enterprise capabilities. [...] Today, I'm also pleased to share that this newest version of Zend Server is now available on the Amazon Web Services Marketplace. Now, for one combined fee with Amazon Web Services, you can run your applications on a fully supported PHP application platform with Zend Server 6 running on Red Hat Enterprise Linux or Ubuntu Linux.

If you're interested in what Zend Server has to offer, check out the product page on the Zend website. Zend Server handles a lot of the base level things for you and can help you get up and running quickly. It includes things like detailed monitoring, error tracking, code tracing and a nice UI to for management and configuration of the server.

When deploying an application to Windows Azure Web Sites, a number of deployment steps are executed. For .NET projects, msbuild is triggered. For node.js applications, a list of dependencies is restored. For PHP applications, files are copied from source control to the actual web root which is served publicly. Wouldn't it be cool if Windows Azure Web Sites refused to deploy fresh source code whenever unit tests fail? In this post, I'll show you how.

He creates a super basic script using Silex and writes up a test with some dummy assertions, checking if true equals true. He then steps you through updating the current "deploy.sh" script to add in a call to execute PHPUnit and an "exitWithMessageOnError" statement. This statement kicks it back and causes the deployment to fail when tests don't pass (as seen here).

"PhpStorm is a lightweight and smart PHP IDE focused on developer productivity that deeply understands your code, provides smart code completion, quick navigation and on-the-fly error checking. It is always ready to help you shape your code, run unit-tests or provide visual debugging." In this tutorial I will show you how to use build in functionality in PhpStorm to deploy PHP application to OpenShift.

Screenshots are included in the post to guide you through the process - creating a new project, setting up the SFTP configuration and where to go to upload the changes to your system to OpenShift.

We've raved about the brilliance of Heroku before, mostly around the fact that it makes launching a Rails or Node app rather simple without having to configure your own server. But what if you want the same kind of freedom and speed of deployment with PHP? Fortunately, Heroku has quietly offered support for PHP for quite some time.

You'll need to get their CLI deployment tool and set up an account but the rest is pretty easy. The steps to set up the git repo, add a new "heroku" branch and push the checked in code directly out to the server.

Up until a few days ago I used to use a small bash deployment script to deploy a few simple sites to my live box. The process was a git archive and extract, then an rsync to the live site. Only inspecting it recently I realised that rsync no longer sent just the changes but all of the files, I'd never noticed before as the sites were so small the deploy was over very quickly. The rsync used to work fine before as I would deploy my current working code where the timestamps on files would match the server. Since I started using git at home for dev, the git archive method timestamps the files with the latest commit's timestamp. This messes up rsync.

His process involves a checked in version of Silex, a development branch, a push of the code to the live machine and an install script to set up Silex. He includes the "technical breakdown" and the information needed to replicate it - the .gitignore, setting up password-less SSHing, setting up the server and creating the git post-receive hook (a bash script).

This month Colin DeCarlo will be talking about a tool called Liquibase which allows you to manage and automate database deployments as part of your build and deployment process. He'll also be looking at how to integrate it with Jenkins and may even talk a little about how this tool is used at Freshbook...

If you'd like to attend, please let them know sometime today so they can know how many to expect!

If you have a user group meetup that you'd like to announce, email the information over and it'll get posted!

Suppose you have a web application that is installed on many hosts. Each installation may have a custom configuration, and the application is still in active development. You need an easy way to deploy new features and bug fixes to all of hosts. [...] In this article I show you how to use this knowledge [from this previous article] to write a boilerplate build file, one that can be customized and reused in your real-world applications. We'll use Phing's Subversion tasks to manage the repository and the FileSync extension to synchronize your local installation with a remote server.

He helps you to get the environment set up correctly (installing the needed PEAR packages), create a basic build file with the FTP settings in it and creating a "deploy" target to do the work. He also shows the settings/configuration involved in a "prepare" target that does the SVN work to do some of the pre-push work. Finally, he shows a "release" target that bundles up the files into a package and pushes it up to the server (via FTP).

This is something experimental I have been working on for our chef deployments. So the objective was/is to find a sane way to install PEAR packages and install dependencies with composer.

He shows how to set up the configuration script to discover a new PEAR channel, make the chef script not "fail hard" if a command returns a failed response code (as PEAR will do if the channel is already discovered). The "ignore_failure" configuration directive comes in handy for this. He also shows how to implement a LWRP in chef for both a PEAR and Composer resource.

You can find the code for this and other cookbook examples on his github account.

In this post, I'll show you how to deploy your PHPUnit tests with your application, have the tests run as a start up task, and have the results written to your storage account for analysis. Attached to this post is a .zip file that contains a skeleton project that you can use to automatically run PHPUnit tests when you deploy a PHP application to Azure. I'll walk you though how to use the skeleton project, then provide a bit more detail as to how it all works (so you can make modifications where necessary).

He has it broken up into a few easy-to-follow steps:

• Download the AzurePHPWebRole zip archive and unpack it
• Copy your application, tests and PHP installation into the resulting file structure
• Create a skeleton "ServiceConfiguration.cscfg" file with the "cspack" command and edit it to change the "osfamily" and "osversion" settings
• Use "cspack" to package up the application and deploy the application

He walks you through the "how it works" steps too - the things that happen for you automatically on the server side to do things like set up the file to log to, configure the PHP environment and execute the "runtests" Powershell file as included in the AzurePHPWebRole download.