Should small teams use Continuous Integration?

Question

I recently switched to a start-up organization providing a social network site. In my new organization, we are a small team of 8 developers/designers.

I heard a lot about continuous integration (e.g. Husdon/Jenkins) but never tried that, better say never needed them. For us, mentis is working fine until now.

Being a manager (ahh, my first assignment as manager), I need to continuously suggest process for better efficiency, without complicating developer's tasks. However, I'm not 100% sure if I should suggest CI for my organization, as I don't know a lot about CI. I don't want to miss better or more efficient ways of developing software, but at the same time I don't want to change the process just for the sake of it.

Can anyone please point out if using CI tools like Hudson/Jenkins will be beneficial to a small team, which already has a working process? If yes, what benefits will we get for that switch? Given the team size, is it worth investing my time to learn/try CI tools first?

Edit

Sorry for missing some required context. Current workflow: Our product is based on symfony 1.4, we use mentis, and symfony console tools for builds. For every release version, we create SVN tags and update server with SVN tags, after manual testing.

Answer 1

I was managing a team of five developers and we started out with CI using CruiseControl. I am hard-pressed to think of a situation involving more than one developer where it would not be advantageous to do CI. Hudson/Jenkins is a good platform and we later moved to it.

Also, you get A LOT more bang for your buck if you are doing CI against a build system that performs automated regression tests with each build. I would very strongly recommend that you include unit tests and general regression tests as deliverables for every feature you implement. It takes more time up front, but you can really, really work a lot faster later in the process and sleep well at night knowing that the quality of your product isn't being compromised.

At one point in our product, we had over 7,000 regression tests that were getting executed with every build. Our product took 20-30 minutes to build and 5 hours to test. Those tests were all put in place during the development of the product and it was one aspect of the project I was most happy with.

Hudson/Jenkins has a very strong regression test dashboard. Make a rule that no one is done with their feature work until their code builds in the build process and all tests are passing. After you get the server set up and people have been using it for a couple of weeks, you won't even think about doing without it.

Answer 2

The Purpose of CI for Project Management

While the question as originally posed isn't really an ideal fit for this site (e.g. it's more about development practice than about managing projects) it is nevertheless a useful question when properly framed.

The Value of Automation to a Project Manager

From a project management perspective, real-world projects typically require (among other things):

• Validation against requirements.
• Regression testing of existing features.
• Acceptance testing of new features.

Continuous integration fulfills this role in an automated way, meaning that it doesn't have to be explicitly managed. This often creates efficiencies for the project over time. From the perspective of a project manager, it may also mean fewer bugs will go unnoticed long enough to impact the overall project estimates or release dates negatively.

Can you do this without CI? Sure. But if you have even two developers on your team, then there will also be integration work (you did plan on feature integration in your project plan, didn't you?) that can and should be automated.

From a project management perspective, frequent integration testing means fewer integration death marches at the end of a project. In my experience, any big project without automated integration testing has a strong tendency to blow its schedule because the effort and complexity of manual integration testing grows over time--and if it's left until the end of the project, you won't be able to accurately estimate the size of the effort involved.

Information Dashboards

Another purpose of CI is as an information dashboard. A good CI system with both effective tests and sufficient code coverage will communicate the status of the project quickly to anyone who's interested. CI won't tell anyone what features are available in the code base, but a green dashboard will certainly tell stakeholders that whatever features are present and tested are ready to ship.

Of course, just like any other tool or project management technique, the CI dashboard can be abused. For example, taking out failing tests just to "green up" the dashboard violates the principles of effective communication and transparency that all project managers should strive for, but I've seen it happen for political reasons and through organizational dysfunction.

As a project manager, communication of project status is extremely important. If some of that communication can be automated, that represents a project efficiency that usually adds measurable value.

Conclusion

While CI is useful from a technical point of view, it can also be useful to create efficiencies and enhance communication within a project management framework. Unless your project is truly trivial, avoiding the overhead of automating tests is usually a false economy.

Answer 3

I'm at a risk of down-votes, but I don't think that you need Continuous Integration in that project. It is a good thing that you are checking it out before introducing it, but it would be also good to know if your organization needs it at all - demand first, supply second approach.

Continuous Integration is good for finding those issues which appear because of working on the same code base on the same time, like build problems, regression testing and possible deployment issues (it is more likely a Continuous Deployment thing). If your organization can develop and test in parallel without any major issues, then the Continuous Integration won't bring any value.

Additionally, Continuous Integration systems have a certain continuous maintenance expense in the beginning. I'm not talking about updating the tool, but taking care of failing build, making it faster and more responsive. If the team has low interest in this - in other words they don't benefit from the system - it will slowly die.

If you still want to use it in your project, before introducing it, keep a demo or hire a good expert who can show the benefits and explain the idea behind Continuous Integration (if he or she starts with the tools then find somebody else).

Answer 4

Small teams, if the codebase is small as well, can get away without CI, since their test suite takes so little time to run (just 3-10 minutes, probably).

The real strengths of CI come in when either:

• you have a complex build to automate
• you have 20+ minutes of tests to run
• you publicly display your red-green test scroll by the company water-cooler.