Home > Agile, Application Development > The point of Continuous Integration?

The point of Continuous Integration?

August 29th, 2008

I have always thought the point of Continuous Integration was feedback. By doing builds and running tests (unit, integration, and functional) as often as possible it provided the team a high degree of confidence that the application worked. Artifacts are simply a nice side effect.

I was in a retrospective today where the importance of the build seemed to focus more on the artifacts. We were discussing pipelining our build and the discussion centered around breaking the build down by artifacts as opposed to areas of feedback.

Personally, I find this a little strange. The last several projects I have been on, the various builds we had were all about providing feedback as quickly as possible. To this end, the first build ran unit and integration tests, the second build ran all the functional tests (think Selenium), with other builds running more in depth functional and acceptance tests.

To quote Martin Fowler, “The whole point of continuous integration is to find problems as soon as you can.” To me, this sounds like information and feedback, not artifacts.

My question to the greater, and more experienced, community is what do you think, should pipelining a build be about artifacts or feedback or a bit of both? Currently, one of our builds takes 2+ hours and we are looking to cut that down. I am not sure we can do this if we concentrate on artifacts instead of feedback. What do others think?

Categories: Agile, Application Development Tags:
  1. Julian Simpson
    August 29th, 2008 at 23:39 | #1
    Reply | Quote

    I think you make a good point. CI is (was) about feedback. But if you have a revision of your codebase that passes the tests, why not grab the artifacts at the same time so you know you have the best chance of getting those artifacts through the QA and release process?

    The problem with the above approach is that the two goals (getting developer feedback, getting known good artifacts) aren’t all that compatible.

    I’d recommend that either:

    - you set up 2 builds. One for tests, one for artifacts. Occasionally you’ll build some duff artifacts. Life could be worse.

    - you look at TW Studios new shiny CI server for a build pipeline. Also, Ant Hill Pro does a similar thing. Please do a follow up post :)

  2. Morgan Roderick
    August 30th, 2008 at 00:21 | #2
    Reply | Quote

    I certainly enjoy getting angry emails from CI when I break stuff, which to me is the primary use for CI.

    But, I can also imagine scenarios where artifacts would be important.

    One could set up a policy saying the the stable branch must have at least 80% test coverage (I know, it’s a lousy metric), or that cyclomatic complexity must not exceed a certain number, or that performance benchmarks must not degrade over time.

    These artifacts could serve as documentation for talks with clients, or to determine when your product would actually be considered “stable”.

    So, I guess what I am saying that artifacts could be very useful, but are not the primary use of CI, and should probably only be trusted when they come from a stable branch or a tagged version.

  3. Bernardo Heynemann
    September 7th, 2008 at 10:25 | #3
    Reply | Quote

    Yes I do agree that CI is all about feedback. Feedback that your codebase is in good shape.

    I think you are mistaking feedback for “having my unit tests pass”. You probably do run the build before committing anyway, right?

    Anyway, feedback, IMHO, is anything that can help you improve or find problems with your codebase. So, code coverage, code analysis, all qualify as being feedback, even though they would be “artifacts” of the build. Any other plug-in meant to give you insight of how your project is doing would be feedback for that matter.

    Now, if by artifact you mean versioning (deployment), meaning packaging the files for that build, well, that’s pretty important as well, since no two builds are the same. You gotta be able to try a given build in the easiest possible way. One easy way is if your build server spits releases for each build.

    As far as your 2h build goes, we’ve all been there. My suggestion would be to check the build log, see tasks that take longer (like acceptance tests) and try to cut on things that are not absolutely needed. Another thing you can check is that you’re not building the code many times. What I mean is, that when you have a pipelined build, what usually happens is that on each step of the pipeline the code gets rebuilt. That’s pretty expensive if you ask me.

    Well, my 2 cents anyway! Hope it helps! :)

    Cheers,
    Bernardo Heynemann
    ThoughtWorks UK

Comments are closed.