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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
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:
Which means that it will get fixed immediately while the memory of the changes is still fresh.