As far as I can tell, services like Travis CI and CircleCI take your project and run its test suite whenever you push a new change to your repository.
Assuming that it’s also possible to either manually or automatically run such test suite locally before you commit or push your change, what’s the point in using a service like this?
1
I’m not familar with those services but CI in general is good for
It gets rid of the “Builds on my machine” excuse for comitting bad work.
If it doesn’t work in CI it doesn’t work.
You can then take the known working code from there and use it for things like Continuous deployment.
Some provide a history so you can tag Version 1.0, 1.1 etc so its easy to go back to them if there is some unforseen problem in the new version or you just need to release the old version.
1
- Are you sure everyone will run the tests? E.g. those commits when you’re late for the plane – and that change is tiny and really-really can’t break anything.
- Are you sure you want to run the whole testsuite on your system before every push? Some testsuites run for hours (UI automation) or execute slow tools like
valgrind. - Are you sure you will run the testsuite on all supported platforms? E.g. if you do a C++ application on Linux/Mac OS X/Windows it is trivial to break compilation on other platforms if you don’t test there. Imagine that sometimes you may even need to test Windows7 and Windows8 separately.
- Build/package the whole application may take awhile by itself. CI lets you simply download the package built on the server.
One of the most common ways I’ve seen people break the build is when they’re working on several different things at once, and they check in what they think is all the changes needed for one particular task that they have just finished.
Turns out they missed a file, or they checked in a change that was part of a separate task that isn’t finished yet.
In cases like this, the tests probably do all run correctly on their machine. But the committed code no longer builds, runs, and passes all tests.
Basically, if the CI tool can get latest from source control, build it, and run the tests, you can be confident that anyone can get latest and get a working codebase.
The key idea with continuous integration is to always have a working build, that is, a build that completes successfully and passes unit tests in canonical build enviroment. This is because it’s much easier to ensure that the build always works than to fix a build that accidentally got broken a while ago, esp. when no one is quite sure who broke it and when.
With continuous integration, you will immediately know if:
- Someone has accidentally committed code without including a new source file
- Someone accidentally used an absolute reference path
- Someone just plain screwed up
Which means that it will get fixed immediately while the memory of the changes is still fresh.
1