Setting up a deployment / build / CI cycle for PHP projects

Question

I've been through buildbot, CruiseControl.net, CruiseControl and Hudson. All though I really liked CruiseControl*, it was just too much of a hassle with really complex dependency cases. buildbot is not easy to set up, but it's got a nice aura (I just like python, that's all). But hudson won over the former three because:

1. It's just easy to set up
2. It's easy to customize
3. It looks good and got nice overview functionality
4. It got point-and-click updates, for itself and all installed plugins. This is a really nice feature, that I appreciate more and more

Caveat: I only ever used linux as base for the above mentioned build servers (CC.net ran on mono), but they should all - according to the docs - run cross-platform.

Setting up a hudson server

Prerequisites:

• Java (1.5 will serve you just fine)
• Read access to the subversion server (I have a separate account for the hudson user)

From here, it's just:

java -jar hudson.war

This will run a small server instance right off your console, and you should be able to browse the installation at your http://localhost:8080, if you don't have anything else running on that port in advance (you can specify another port by passing the --httpPort=ANOTHER_HTTP_PORT option to the above command) and everything went well in the 'installation' process.

If you go to the available plugins directory (http://localhost:8080/pluginManager/available), you'll find plugins for supporting your above mentioned tasks (subversion support is installed per default).

If that has whet you appetite, you should install a java application server, such as tomcat or jetty. Installation instructions are available for all major application servers

Update: Kohsuke Kawaguchi has constructed a windows service installer for hudson

Setting up a project in hudson

The links in the following walk-through assumes a running instance of hudson located at http://localhost:8080

1. Select new Job (http://localhost:8080/view/All/newJob) from the menu on the left
2. Give the job a name and tick Build a free-style software project on the list
3. Pressing 'ok' will take you to the configuration page of the job. All the options have a little question mark besides them. Pressing this will bring up a help text regarding the option.
4. Under the option group 'Source Code Management' you would be using Subversion. Hudson accepts both url access as well as local module access
5. Under the option group 'Build Triggers', you would use 'Poll SCM'. The syntax used here is that of cron, so polling the subversion repository every 5 minutes would be */5 * * * *
6. The process of building the project is specified under the option group 'Build'. If you already have an ant build file with all the targets you need, you're in luck. Just choose 'Invoke ant' and write the name of the target. The option group supports maven and shell commands as well out of the box, but there is also a plugin available for phing.
7. Tick off additional build actions in 'Post Build Actions', such as e-mail notifications or archiving of build artefacts.

For setting up processes for which hudson have no plugins, you can either call them directly through a shell script from within the build setup, or you could write you own plugin

Pitfalls:

• If you have it produce build artefacts, remember to have hudson clean up after itself in regular intervals.
• If you have more than 20 projects set up, consider not displaying their build status as the default main page on hudson

Good luck!

The term you are looking for is "continous integration."

Here is an example of someone who uses GIT + phpundercontrol: http://maff.ailoo.net/2009/09/continuous-integration-phpundercontrol-git/

CruiseControl (which is a CI server), can use Hosted SVN/GIT as a source. So you can even use it with GitHub or Beanstalk or something else.

Then you can integrate that with the following kind of software:

• PHPUnit
• php-codesniffer
• phpdocumentor
• PHP Gcov
• PHPXref
• Yasca
• etc.

You could also try this hosted CI: http://www.php-ci.net/hosting/create-project

Keep in mind though, that those tools need custom support if you integrate them yourself.

Have you also thought about project management and patch management?

You can use Redmine for project management. It has integrated continuous integration support, but only as client side (not as CI server).

Try using a hosted SVN/GIT/etc. solution, because they will cover your backups and keep their servers running, so you can focus on development.

For a tutorial on how to setup Hudson, see: http://toptopic.wordpress.com/2009/02/26/php-and-hudson/

I use Atlassian's Bamboo continous integration server for my main PHP project (along with their other products such as fisheye (repository browsing), jira (issue tracker) and clover (code coverage)).

It supports SVN and now supports Git and it has a great user interface. It is available for linux, windows and mac and can run standalone on its own tomcat server which is great for people (like me) who does not like to take days to setup their tools). Although it may look expensive, being a lone developer myself I purchased the starter kit license for 10$ (10$ by software). This is great for small teams and it is worth the look.

PHPTesting PHPCI This is nice, continuous integration server built in php.

Plus, its free and open source. :)

it has number of plugins..

PHPCI includes integration plugins for:

• Atoum
• Behat
• Campfire
• Codeception
• Composer
• Email
• Grunt
• IRC
• PHP
• Lint
• MySQL
• PDepend
• PostgreSQL
• PHP Code Sniffer
• PHP Copy/Paste Detector
• PHP Spec
• PHP Unit
• Shell Commands
• Tar / Zip

I am mostly a sys admin but sometimes I code PHP as well. As a side project I created some scripts that will make it simple and painless to set up a full blown PHP CI environment using Jenkins. It also runs a sample project for you so you can see how each build step is configured.

If you want to try it out all you need is a Debian/Ubuntu box and shell access.

http://yauh.de/articles/379/setting-up-a-ci-environment-for-php-projects-using-jenkins-ci

Update To add some content to my answer:

You can simply set up a Jenkins CI for PHP using Ansible. Since v1.4 it supports roles which you can download from their galaxy.ansibleworks.com community site and it will do the heavy lifting for you. It is called jenkins-php.

I would suggest using Jenkins http://jenkins-ci.org/ it's free and it's open source.

It's pretty straight forward to setup, works on multiple platforms and integrates well with other continuous integration tools like SonarQube (+ SQUALE) to measure technical debt and Thucydides for testing automation.

I would highly suggest using GIT or GIT Hub for version control instead of SVN. From my point of view it's just a better version control system that will help you scale your development efforts later.

Since you're working mostly with PHP project there are some other tools you can use.

PHPUnit - For unit testing

PHP CodeSniffer - Check for coding standards

PHP Depend - Shows your PHP code dependencies

XDEBUG - For performance testing

All of these tools and be triggered with a Jenkins job and helps with the quality and performance of your code.

Good luck and Enjoy!

I do not use many of the products, or even types of products that you use, but I will give you my experience.

I run a TEST environment in parrallel with my PROD environment. I have no local testing per se. If it is too hard to get soemthing up into a real TEST environment, then I fix my build process. I don't see the point in testing locally, as the environments are different. UPDATE: The only thing I do locally is run "php -l" before I upload anything. Stops the stupid mistakes.

The build process works with whatever is in the current workspace, which includes uncommitted code. This is not everyone's cup of tea, but I am going to TEST very often. Everything gets committed before going to PROD.

Part of my build process (similar to yours) creates two META files. One contains the last (typically) 100 changes and also gives me the current changelist number. The shows me what changes are installed. The other contains the CLIENTSPEC (in Perforce terms) which shows me exactly what branches were used in this build. Together these give me reproducible builds.

I do not build straight to the target environment, but to a staging area on the server. I use SSH so this makes sense. This gives me a few advantages. Most importantly it avoids dying half way through a large upload. It also gives me a place to store META files, and all the build files are automatically archived (so I can go straight back to any build). The script also logs the update (so there is an entry in the log stream and I can see pre- and post-) and kicks all daemons (I use daemontools so "svc -t"). All of these are better off on the target machine.

One other issue is DB changes. I keep a master script of the DB schema, which I update every time the schema changes. Each of the changes also go into a changes.sql script, which is uploaded with the build to the staging area. The script is run as part of the install script.