This is the 3rd post in a series ‘How to get started with CI’

Previously, we talked about choosing the correct infrastructure for your CI system. We will now talk about CI tools themselves. There are lots of CI tools out there. Many more than I know about and have listed here. Some tools are good and some, not to my liking.

If you have used a CI tool before then you may find yourself comfortable with that, if that is the case then I’d love to hear about your experiences. Alternatively, if you are new to these tools I have included a few things to consider when choosing a tool:

1. Technology

Don’t choose a CI tool that is not compatible with your environment e.g. if you run linux based servers then you would not choose a windows based tool unless you had the ability to create a windows VM. Before choosing a tool, make sure to investigate the requirements needed by it.

2. Cost

If you have little or no budget then you will be limited to some of the tools that are either free or have community versions. Check the license agreement for terms and conditions about their uses – its best to know what is expected before you start using it.



3. Support &/or Community

Choose a tool that has a good user base or support forums. If you choose otherwise then it may be difficult (if at all) to get help if things do not go as expected or if there are issues with the software. A more established and well known tool means there is a greater probability of someone having a similar issue to you and thus a resolution may be more readily available.

4. Ease of Use & Maintainability

If you choose a tool that is difficult to use, then it will be difficult to adopt into your organisation. For example. CCNET, hugely powerful tool (and one I started with) is configured mostly via XML files (special editors may be available) and build scripts. There is no easy UI to make things smoother. In my opinion, unless you like creating scripts in notepad (or your favourite text editor) then it may not be the one for you. Remember, you probably won’t be at a company forever, so think of the guy that has to pick up this system after you leave – unless you have a simple system, it may get neglected or trashed completely.

5. Choose something ‘Cool’

I personally love new shiny tools. In fact, if there is a developer out there who doesn’t then I’d love to speak with them to find out why. I enjoy testing, evaluating and writing about new tools. So when a new CI system appears on my radar, I give it a go. If you find a tool that keeps you interested then you will enjoy using it.

It is very important for your tool to not be a hassle to use, configure or maintain. If you have to reason for “CI” maintenance that may take hours out of your week then the team is less likely to buy into that situation. My top tip is to use a scoring matrix and score each of the sections above 1 – 10 (1 being worst, 10 being best) and then get a shortlist of the tools that you like. After you have got a shortlist of say 3 tools, then trial them. It is very important to trial them, they may look great on paper but they may not work out how you imagine.

This article talks about the points worth considering when choosing a CI tool. It you have been through this process and feel there are other points worth considering then please do comment and I will add them to the list. If you feel that a particular CI tool was missed from this article then please do add that as well with a link to its website.

The next post in this series will talk about how to implement your first project into a CI tool.