A tip for continuous integration shops

Recently I have been working on cleaning up our continuous integration enviornment. Continuous integration is pretty cool but don’t shoot yourself in the foot by making bad build plans and not being very specific about your build requirements. If you have a package dependancy for a build make sure you put it in your requirements. If you need specific access to a database to do fixture tests SPECIFY it.

In the short term you can see the benefits of continuous integration  without doing these things. But as people cycle in and out of your orginization having a clear record of all the requirements for a build is crucial.


  • Ah, cool. Not being a developer, I was unfamiliar with the concept of continuous integration. I looked it up (http://www.martinfowler.com/articles/continuousIntegration.html) and it seems useful to the dev teams.

    What are some of the differences in the underlying infrastructure between a normal CVS/SVN environment and a continuous integration setup?

  • I should clarify I am _not_ a developer either. 🙂

    So the main thing is that upon each check-in a build is performed. Source code is compiled (if needed), unit tests are run, system tests are run. The idea is you can catch breakage right away. You try to keep “bad” commits from entering the repo by placing importance on the fact that _any_ revision of the main repository should successfully build. For dynamic languages a build could include running unit tests in the code, pushing the code to a staging server, running your fixtures and system tests. So really there is no change for your typical CVS/SVN you just add the build server to the mix. It monitors your repos for changes and upon change it kicks off a build. You then get trends of your breakage etc … I think it is also useful to show the importance of automation. Its easy to not have automatic deployment but that possible variation by not being automated is dangerous for troubleshooting later.

  • Continuous Integration is actually getting more and more play outside of the “pure dev” team. It has and continues to be applied to teams of documentation writers, QA test developers, and to other IT areas successfully.

    As you state, it’s the practice of ensuring that whatever is committed to the shared repository plays well with everything else already there and doesn’t introduce any automatically detectable regressions in the code/docs/tests/etc.

    I agree with your assessment, you have to have a plan when putting CI into place. For the small team/small project it’s easy to get up and running quickly. But for larger projects, everything should be defined in the CI system. It becomes the repository of knowledge for how the whole system is put together.

    Thanks for the post!

    Mr. Hericus

  • Nice post. Just thought I’d add to the comment from Mr Hericus (hello again!) that CI looks set to become more and more central to the release process in organisations. A lot of shops now generate tags from the CI processs and use them to track artifacts through to deployment. There’s a couple of CI servers now that allow you to invoke all your deploy steps from the server itself. Which could be good with the right security and process.

Leave a Reply

Your email is never shared.Required fields are marked *

To submit your comment, click the image below where it asks you to...
Clickcha - The One-Click Captcha