I believe that one of the biggest advantages of using CI is capability of detecting defects, which makes integration and deployment tasks easier.
It is not clear to me, however, how does CI improves software quality. Obviously, the use of a good test suite results in less bugs, but does it changes anything regarding other software quality factors like, for example, maintainability, completeness or consistency?
CI ensures that what was checked in will compile and the unit tests will pass.
So, each build you could give to users and have them test, to ensure that the software will meet there needs.
That is the big way it helps, in an agile environment, to allow people to get their hands on working code and try it, without going through a release cycle.
I think this is enough (original text by Joel :) )
Here are some of the many benefits of daily builds:
- When a bug is fixed, testers get the new version quickly and can retest to see if the bug was really fixed.
- Developers can feel more secure that a change they made isn't going to break any of the 1024 versions of the system that get produced, without actually having an OS/2 box on their desk to test on.
- Developers who check in their changes right before the scheduled daily build know that they aren't going to hose everybody else by checking in something which "breaks the build" -- that is, something that causes nobody to be able to compile. This is the equivalent of the Blue Screen of Death for an entire programming team, and happens a lot when a programmer forgets to add a new file they created to the repository. The build runs fine on their machines, but when anyone else checks out, they get linker errors and are stopped cold from doing any work.
- Outside groups like marketing, beta customer sites, and so forth who need to use the immature product can pick a build that is known to be fairly stable and keep using it for a while.
- By maintaining an archive of all daily builds, when you discover a really strange, new bug and you have no idea what's causing it, you can use binary search on the historical archive to pinpoint when the bug first appeared in the code. Combined with good source control, you can probably track down which check-in caused the problem.
- When a tester reports a problem that the programmer thinks is fixed, the tester can say which build they saw the problem in. Then the programmer looks at when he checked in the fix and figure out whether it's really fixed.
Since your are asking about other quality factors:
maintainability: CI enforces that your build process is fully automated hence anybody can setup the project when she knows the CI. This is great for getting new developers on the team, or even a complete team.
maintainability: You could add tests based on code quality metrics, thus ensuring the codebase to stay reasonable clean.
consistency in the sense of consistent style: you could check that through automated test to some extend. Which then would be come part of your CI
completeness: I guess one could create a suite of acceptance tests first, which would tell you when you are done. But I don't think it is workable.
Yet I think the question is a little strange. CI provides fast feedback on testresults, which is a huge value. Why are you looking for more reasons?
G'day,
I'd highly recommend the original paper on CI by Martin Fowler. It is a short read and even has a section on the Benefits of Continuous Integration.
Oh, Martin Fowler was one of the first people along with Kent Beck to popularise the concept. The first version of that paper I've suggested is from the turn of the millenium.
BTW I'm a big fan of CI after using it on a large scale project (>3,500kSLOC) and seeing the many benefits it brings.
HTH
'Avahappy,
There are some obvious easy CI helps code quality and some subtle ways.
The obvious way is what it does directly by improving feedback. That feedback could be running unit tests and catching defects but it could also be running code metrics like Crap4J so you see what's happening to your code over time.
A more subtle effect comes from the confidence you get from having the CI safety net. Lots of teams I've visited know they have ugly code but they are afraid to fix it because they might break something and not find out until it is too late. Having the feeling that if you make a mistake that your CI system will tell you in 5 minutes is very empowering!
Finally there's the simply the result of extra time. With CI you catch some problems sooner which makes them easier to fix. Now how do you reinvest that time savings? If you spend it refactoring or doing extra testing (or both if you include your QA team) you're going to end up with higher quality code.
CI itself is mainly about interoperability of all changes within the source code amongst devs.
The biggest advantage you can get with consistency, though, is the things that having such a setup allow you do to:
Consistency is achieved via the deployment method, IMHO, and making sure that nothing is deployed that isn't confirmed first; and all things work as they did before.
For me working alone, there is no real need to integrate changes between anyone (CI), but the big benefit is everything else.