Luis Atencio has posted the latest article in his "Continuous Delivery" series today, this time with a focus on implementing a testing strategy. This is the fourth post in the series (part 1, part 2 and part 3).

There are three things in life that are always held to be true: we will die someday; we will pay taxes; and software will have bugs.... LOL [...] A testing strategy is often overlooked in software projects. This should not be too surprising, we want to build applications quickly and release them quickly. However, leaving quality out of the picture or towards the end are terrible mistakes.

He talks some about the different types of testing that revolve around software development - "business facing" and "technology facing." These are each split down even further into things like acceptance, integration and unit testing.

Luis Atencio has posted the third part of his continuous delivery series (parts one and two), this time with a focus on continuous integration as a part of the process.

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.

Luis Atencio has continued his series on continuous delivery with this second post. It focuses on the first step (and one of the most important) - keeping everything configuration-related in a version control system.

I will be continuing the topic on Continuous Delivery which began in my previous post: Notes on Continuous Integration; this time we will start looking at the first and most important step, Configuration Management. In the words of the authors (resource below): Configuration Management refers to the process by which all artifacts ... and the relationships between them, are stored, retrieved, uniquely identified, and modified.

He sets out four principles that can be used to set this process up in your workflow:

• Keep everything in version control
• Manage dependencies
• Manage software configuration
• Manage environments

Each point has an explanation and advice on what he's found the best way to implement the functionality. He finishes with a few other pieces of advice including avoiding branching in config repositories and having good communication practices with your ops team.

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.

DPCRadio (recordings of the sessions at this year's Dutch PHP Conference) has posted its latest episode - a recording of Josh Kalderimis' talk Travis CI - Distributed CI for the Masses!.

Continuous Integration has typically been a practice only performed by companies who want that piece of mind for their client software, but does it need to be like this? Travis CI is a continuous integration service for the open source community. We make testing OS projects dead simple and fun. But most importantly, we help improve code quality for large projects like Doctrine2 and symfony, to smaller libraries like FOSRest. The vision behind Travis CI is to become for builds what PEAR is for distributing libraries. In this talk Josh, one of the core members of the Travis CI team, will introduce you to the vision behind Travis, the how it is implemented, and why it matters to everyone in the OS community.

You can listen to this latest episode either by using the in-page player or by downloading the mp3. You can also subscribe to this podcast.

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 Reddit.com there's a recent post answering a question asked about PHP and continuous integration during a project's development.

Does anyone have experience with PHP and Continuous Integration? If so, what tools and / or platforms did you use?

Suggestions in the comments include:

• Codeception for unit testing
• the Jenkins PHP template
• Atlassian Bamboo
• Jenkins
• Travis-CI (more for open source projects)

Till Klampaeckel has a new post to his site showing how you can use the external continuous integration system Travis-CI to handle automated database testing for your PHP app using Doctrine.

Testing is important - most people understand that by now. A lot of people write tests for their open source code already, but in-house testing is still hard. [...] While I prefer to run my database tests against a SQLite in memory database, there are these edge cases, where I work with multiple database or I write a direct query (and by-pass the ORM-magic). In these cases I need to have that database server available in my test environment! The following blog posts explains how to solve these things with Travis-CI. I will walk you through the setup on Travis-CI's business service. But most of this applies to their open source offering as well.

He's broken it up into a few different steps - the setup and configuration of the ".travis.yml" file, adding in a "composer.json" file with the needed dependencies and the recommendation of a "phpunit.xml" in your project's root. He shows how to use Doctrine's "SchemaTool" utility to generate his schema off of the comments on his entities (instead of checking in SQL). This setup them gives him access to Doctrine's EntityManager object in his tests and he can go from there. If you're thinking about doing something similar, check Travis' list of supported databases before you do anything, just to be sure.

On his site Marcelo Gornstein has published a new guide to getting a basic automated continuous integration server set up with Jenkins and Phing.

This article is about how to use Phing in your projects, so a continuous integration server (in this case artifacts for your php application (deployment artifacts, documentation, code metrics, etc). I'll try to show why this will make your life easier when developing or auditing code, generating releases and deploying new versions, trace bugs, etc. All with just a handful of phing tasks.

He introduces the Phing tool and explains how it makes automating the steps of your process simpler, relating it to the Apache Ant tool for those familiar with it. He links to several of the resources used in the process including PHPLoc, DocBlox and the code for the article itself. He outlines the process and, complete with a screenshot of the final result, shows you how to get everything configured and running smoothly.

Following up from his previous post about setting up PHP with Jenkins, J Armando Jeronymo is back with part two of the series - setting up an example project to show how the pieces fit together.

In the first part of this article I presented the case for Continuous Integration. Now we'll install and set Jenkins up to monitor the automatic building of a simple demonstration PHP application. We'll begin with the demo project, then address Jenkins' installation, and finally set it up and watch it running.

He includes a sample project structure, complete with a PHP class and its tests. He shows how to manually run things first (so you'll know what the commands do), the contents of the class/tests and the example Ant configuration file. He's also included screenshots of the Jenkins interface, showing how to create a build, add a new step and let the build run to evaluate the results.