Posts Tagged ‘continuous integration’

Travis CI

Monday, May 30th, 2016 | Programming, Tech

travis-ci

Travis CI is a cloud-based continuous integration tool. Notably, it is also free for open source projects. They do paid subscriptions as well if there is a private repo you want to test. If you just want to test a public GitHub project though, it’s free and really easy to set up.

You can log in with your GitHub account. Once you have done this, you are given a list of your projects and you can turn on Travis CI for each one individually. Using the GitHub hook, you can configure Travis CI to automatically run a build every time code is pushed to the repo.

It supports an array of different languages and platforms. To get up-and-running, you need to add a config file into your repo. This is pretty simple. Here one I am using for a PHP project:

language: php

php:
– ‘5.5’
– ‘5.6’
– ‘7.0’

install: composer install

This configures it to run it on three different versions of PHP, and install the dependencies before starting the test. It comes with many of the common PHP extensions already enabled, and an additional list of ones you can enable if you need them.

Conditional tasks in Ant

Thursday, February 28th, 2013 | Programming, Tech

If you’re using Ant build scripts, there is a good chance that you will want to do some tasks conditionally – for example, if you’re using CI you will want to run your unit tests every time some code is committed – but you might only want to regenerate documentation or update a stakeholders’ preview build every night.

There is a lot of talk about conditional tags, but all these really allow you to do is set even more variables. You can use if/then/else from Ant-Contrib but that involves adding extra libraries and complicating the issue.

Actually, it turns out it is really simple to set up conditional tasks in your build process. All you need to do is call the task, but in the task header use the if attribute.

For example, I have a build task which calls all the other tasks.

<target name="build" depends="clean,checkout,nightly,phpunit,documentation" />

Even though I’m running this every time, I’m calling the “nighty” task. Below shows how I define that.

<target name="nightly" if="${env.NIGHTLY}">

Finally, in my Jenkins CI install, I make the project a parameterised build, and add a boolean called NIGHTLY that defaults to false. I can then also trigger a build by cron that specifies the NIGHTLY parameter as true, so that when it runs on a night, it runs the additional tasks as well.

Continuous integration

Saturday, May 19th, 2012 | Limited, Tech

I’m currently consulting at a small software house in Leeds city centre and we’re making continuous integration a big thing.

Initially, we started off using CruiseControl which integrates nicely with phpUnderControl. Unfortunately, phpUC is now seriously showing its age – many of the components simply didn’t work anymore and it still uses phpDocumentor, a project that was abandoned years ago to the point where it is now unusable with modern code (though I’m glad to see the project has recently been rescued and a 2.0 version is being developed).

As a result, we’ve now switched to Jenkins and it’s really working out well. it seamlessly integrates with Subversion and using the Ant build script we’re able to integrate PHPUnit, PHP CodeSniffer, PHP Copy & Paste Detector and PHP Mess Detector, all of which provide great feedback on the standard of code which is being written.

You can then varying the log level and what classes as a failed build, so if you want to ensure everything is absolutely perfect, you can have Jenkins email you every time someone doesn’t quite space their code out right, or adds a local variable that they never use. Then again, you can just have that stuff running in the background and check it when you have time.

One issue you might run into when first integrating such tools is that builds can take a long time to run – CodeSniffer and Mess Detector can take up to 10 minutes each even on a small code, when there are lots of issues to resolve. However, once you have resolved most of these issues you will find that they run quickly again and should be able to get your build time down to a couple of minutes on even a large codebase.