Last night at DCPHP, I gave a short "lightning" talk on Continuous Integration and Deployment in the context of PHP applications. I really like the lightning talk format as it forces you to focus on the meat of your topic- there's no time to get distracted by details. As great as that is, though, I wanted to expand a little on the subject and touch on some of the details that I couldn't include in my presentation.

She starts off by talking about what's wrong with a lot of the more traditional build and development practices, noting that "it sucks" because of the processes involved. With the help of continuous integration, some of the process can be automated and make for less human-related errors during a deployment. She talks about some of the things you'll need to do to prepare your codebase and a few things to think about your future setup like:

• what does a successful build look like?
• how much code needs to be covered by tests to deploy?
• should a build be successful if standards are broken or issues found?

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.

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.

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 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.

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.

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.

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)

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.

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.