Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Continuous Integration in a LAMP environment

by g0n (Priest)
on May 21, 2010 at 11:38 UTC ( [id://841084]=perlquestion: print w/replies, xml ) Need Help??

g0n has asked for the wisdom of the Perl Monks concerning the following question:

Hi All,

I'm in the process of introducing/improving automated testing in our environment, and looking at how we run and monitor those tests.


We have a public facing web infrastructure based on Apache and mod perl, and a core customer facing client/server Java application. Development is done in a dev/test environment, unit tested by the developer there, then deployed into Integration where UAT testing happens. Finally it's deployed into production where end users break the use cases and script kiddies demonstrate that they have far less destructive imaginations than Joe User ;-) As usual, most of the testing for the website is manual, although we have an increasing number of TAP unit tests (the Java team have CI already - see below).

Continuous Integration

My initial thought was to run my '' script once a day, redirecting the html output to a webserver. I've got that basically set up, and it looks like a good start. It outputs some nicely HTML formatted TAP output courtesy of TAP::Formatter::HTML and Devel::Cover output. I'm also contemplating a spot of integration with CVS to show when tested files were last checked in as well.

But then one of our Java team mentioned continuous integration to me. I had a bit of a poke around in TeamCity (which the Java team use) and concluded that it would be really nice to integrate a CI system with our build process. The way I'm thinking, the overnight process becomes:

  1. Run build script
  2. deploy daily build to (an) integration server
  3. run unit tests and report output
  4. back out build
  5. run previous unit test set and report output

That would test not only the code, but the release/deployment process (subject to the limitations of automated tests of course) and the backout process too.

Incidentally this would probably entail a second integration server. The deployment process entails process controls on the integration environment, which is widely used outside our team so we can't risk regularly breaking it.

It would be a fairly time consuming and complex task to build this testing & CI infrastructure, and my initial idea is to do it gradually. The change plan would be:

  • Stage 1: a daily run in Dev of the existing unit test suite, outputting the results to TeamCity
  • Stage 2: build a 2nd integration server/VM and build the scripts to keep it in sync with the main integration server
  • Stage 3: get TeamCity running the build script daily, to ensure the build is successful
  • Stage 4: start deploying the build to the second integration server daily and recording the results
  • Stage 5: Before and after unit testing in integration as part of the process

To me it looks do-able, if a little time consuming, and likely to improve our release process significantly. I'd quite like to make the right choices before I start, so that I don't end up wasting a load of time on tools that won't do what I want. So:

  • Has anyone else built this kind of release infrastructure for a LAMP environment?
  • Will TeamCity work ok for this, or should I be looking at Smolder, or Hudson, or something else?
  • Anyone got any other suggestions/thoughts?




Suggestions on Deploying Perl Test Environment

TeamCity on CPAN


"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".


"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".

  • Comment on Continuous Integration in a LAMP environment

Replies are listed 'Best First'.
Re: Continuous Integration in a LAMP environment
by gchitte (Initiate) on May 21, 2010 at 12:07 UTC
    Hi Charles, I had previously build a complete Regression teting environment in Perl , I did not use any modules as you have mentioned but, Hudson can be a good choice as you can Build and deploy simultaneously into you teting evironment through command line. This makes you automation easy as well. But you have to check the feasibily to use the tool in your current environment, as to how much effort it need to integrate the build process with HUDSON .
Re: Continuous Integration in a LAMP environment
by pemungkah (Priest) on May 22, 2010 at 00:15 UTC
    Hudson is an excellent way to go. TAP::Formatter::JUnit will nicely format your test output as JUnit XML, and Hudson can happily pick that up.

    Devel::Cover's a little more complicated, but also workable.

    Hudson makes things really easy to set up, since it allows you to do "freestyle" builds, which essentially just execute arbitrary commands in order. Don't know if TeamCity can do that, but if it can, you should be able to integrate into the same server, which would be better from the standpoint of being able to watch all the builds at once ... looks like it doesn't, which is unfortunate, but you can work around that with Hudson. (Edit: fixed link)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://841084]
Approved by moritz
Front-paged by moritz
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2024-04-25 14:08 GMT
Find Nodes?
    Voting Booth?

    No recent polls found