So here's a bit of background on Travis: http://en.wikipedia.org/wiki/Travis_CI
Basically, what it does is on every checkin of code (some people call this a push or a merge, or a pull request) into github, then it will kick off a Travis run. The Travis run is essentially a bunch of tests to verify that what's been comitted isn't breaking anything.
At work we have it setup so that just creating a pull request causes a travis run to go against the pull request. Then you can know that the PR won't break things when it gets merged.
I think this is our live test results from work (I don't work on this area of the code much)
(shows whats building right now)
(shows what has finished building)
green means that the tests passed, red means something failed, and IIRC yellow is in progress.
Travis and github can be integrated. For example, if you look at this:
you'll see a red X beside the git hash. It you hover your mouse over it then it will say that it failed (and there is also a Failed notification beside the merge icon).
Here's a success example:
The mbedmicro repository also has integration with Travis setup:
(you can see the green checkmarks here)
Lets suppose I wanted to commit a change to micropython, then the process should go something like this:
- I do my changes locally and then create a pull request (PR)
- Creating the PR should kick off some travis tests which go and verify that I didn't break anything
- Once the travis tests are green (and Damien is otherwise happy with the PR), then Damien would go ahead and merge it.
- This would probably kick off another set of tests
- When tests start failing, then someone needs to figure out if the test si bad or if the commited code is bad.
If the commited code is bad, then it generally gets backed out
If the tests are bad, then the tests need to be fixed.
A non-Travis example of continuous integration (this is what I actually use on a day-to-day basis):
B is for builds. If you scroll down a bit, you'll start to see other letters and numbers beside the B. Those are test suites (each one is hundreds or perhaps even thousands of tests). You'll see that we run builds and tests on a variety of different platforms, with both Debug and non-Debug builds. Things with a star beside them are failures that have a known reason for failing.
If a commit gets an unknown failure, then it typically gets backed out and the developer has to investigate what went wrong, fix it, and resubmit. At work we also use integration and master branches. The link I posted above was for an integration branch. Periodically, (once or twice a day) when the integration branch is green, then it gets merged to the master branch, and the whole process is repeated on the master branch.
When things start failing really badly (lots of red), then the trees will sometimes be closed for further checkins until it can be brought back to a green state.
By running tests on every checkin, it makes it much easier to figure out which particular checking caused a problem and then back it out. We have hundreds of commits per day, so without this type of automation, things would be broken most of the time, whereas the way things are now, the stuff on master is actually fairly stable.
If you still have questions, please feel free to ask away.
And although I may know a bunch about continuous integration and how it works, I've never actually set something like this up.