Continuous Integration Engine

I have been working with our brand new continuous integration engine for about 1 year now and I have to say it is the best thing that happened to our programming team.

For those that don’t know what continuous integration is the definition from wikipedia:

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.

There are many implementations of CI in the world.  We work mostly with PHP, Javascript and MySQL and chose to glue it all together with a free application called Jenkins.  Jenkins allows us to automate all of the release, build and testing tasks that we would otherwise have to remember and coordinate across our team.


Our solution uses subversion to store our code in a repository.  There are many other solutions out there and you can read about my reasons to choose subversion here. So whenever we check something into our repository we have it configured to notify Jenkins.  Jenkins then kicks off a job that checks out a build copy and stands it up in our development website.  The whole process takes a couple of seconds.

The system is designed to use unit testing (J-J-J-J-J UNIT!) to validate the changes and with confidence produce a staging release copy.  The staging release copy is filtered in a special way to include only the relevant files in the release as there are a number of files we don’t want from our development site like the database configuration and theme files for example.

If everything checks out the system releases to our staging environment automatically.  It merges the release from earlier with some other files required to make the staging site unique.  We run through a series of tests and again if everything checks out it is released into production.



Diagram of a common SVN/Jenkins build process.

One of the biggest challenges we had with this system was handling the code changes combined with the database changes.  Our DB in development, staging and production are all different.  In our case we take a replicated copy of the production database and restore it into staging and run some modification scripts against it to simulate the same thing that will happen in the production release.  Perhaps a future post will elaborate on how this is achieved.  At any rate we are happily collaborating and releasing into production without breaking things and stepping on toes; this is a major advancement for our team as we have been doing it the other way for so long.