Pull requests
We've already see that pull request management allows us to control the integration of code into the core software. We said at the time, that you should ideally only do this if it passes the Unit Tests. But at the time we assumed those would be run by whoever was issuing the pull request. Now, however, we have Travis involved.
Try initiating a pull request now. Whereas previously, as owner, we saw this:
...we now see this:
...or if the tests fail, this:
That is, Travis will run the yml script when the pull request is made, and flag whether any tests are passed. This means the owner can instantly see whether the code is good to merge or not. Genius!
Overall, then, Travis not only helps automate the process of Unit Testing, recording the results for us on GitHub, but also allows us to structure the merging of code into the core software around whether bugs are present or not, and whether the branch code matches the interface interactions the Unit Tests embody. The circle is closed – if we've designed the Unit Tests well, the software management process will structure the building of the software in a robust and bug-minimising way!
Obviously, as Travis puts a virtual machine at your disposal for software testing and checking, there are a huge number of things you can do with it. You can, for example, build conditional statements into the yml script to determine what happens if the tests are passed or not, or build against particular versions of Python (details). If you're building the core software branch, you can tell Travis to build a release (details for GitHub and GitHub Pages), though this is a little more involved. The Travis documentation is extremely good, and worth a browse as your starting point after this practice.
For now, though, try breaking your code and pushing it to GitHub/initiating a pull request, and see how Travis and GitHub respond.