Thursday, 8 December 2011

Continuous Integration

Ctrl^V: In software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. Ref. Link:

Basic CI Workflow

1. Checkout code from repository
2. Code a new feature
3. Run automated build on my machine (repeate 2-3 until tests pass)
4. Merge with lastes changes from SCM (fix and rebuild until tests pass)
5. Commit
6. Run a build on a clean machine (immediately fix bugs and integration issues)

Fowler's 10 Practices of CI

1. Maintain a single source repository
2. Automate the build
3. Make the build self-testing
4. Commit every day
5. Every commit builds on an integration machine

1. Keep the build fast
2. Test in a clone of the production environment
3. Make it easy to get the last executable
4. Everyone can see what's is happening
5. Automate deployment

If you want to drink from the source you can have a look at:


Continuous Integration with automated test execution has seen broad adoption in recent years. Here we use Jenkins (http:// for CI, according to its own website, Jenkins is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs:

- Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.

- Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.

The guys here made a .NET plugin to Jenkins that basically will curse your name when you break the code or play a loud Aleluia when everything goes smooth. Every day very early in the morning you could listen to it as soon as the whole test process goes fine. Crazy shit. It feels so geeky high-tech that I could cry... until I’ve seen on those guys who basically adapted a USB missile launcher which will literally fire on the poor programmer’s head when he/she screws ups:


Here together with Jenkins we use Phing. PHing is a PHP project build system or build tool based on  Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make, and its use of simple XML build files and extensible PHP "task" classes make it an easy-to-use and highly flexible build framework. Features include running PHPUnit and SimpleTest unit tests (including test result and coverage reports), file transformations (e.g. token replacement, XSLT transformation, Smarty template transformations), file system operations, interactive build support, SQL execution, CVS/SVN operations, tools for creating PEAR packages, documentation generation (DocBlox, PhpDocumentor) and much more.

No comments:

Post a Comment