Once you know how you want to setup a work flow you may wish to automate some or all of it, to make the life of your team easier. This way you can provide a set of tools, which can be run from a command line, as plug ins for your favorite tool, or as part of a web interface.
Of course as git is a command line tool a shell script can be written that will do many of the standard git operations. So for example you could take some raw data, populate some templates, commit them into git and push them up to a server.
|
Note
|
TODO talk about GitHub’s web hosting |
However if you want to do something more complex then you may wish to use the GitHub api which lets you access many of the features of GitHub programmaticly instead of doing them via the web interface.
|
Note
|
TODO a few more examples |
If you are using GitHub for hosting your product you may wish to do Continous Integration with your GitHub repository. There are a number of ways to do this but one easy hosted solution is to use Travis CI (http://travis-ci.org) which is a hosted CI solution that can run tests with a number of different languages.
Travis-Ci was started by the ruby guys, but has since expanded to allow testing in C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, JavaScript (Node.js), Perl, PHP, Python and Scala. As Travis is open source if you need a language that is not on that list I am sure they would be happy to get a pull request from you that would make it work.
To setup travis-ci you need to add a yml file to the repository called .travis.yml which should contain the options for how to build your software.
When Travis goes to build your project it will create a new virtual machine and then build your project based on the instructions in the .travis.yml file. At the end of the build cycle it will destroy the virtual machine. Thus any changes to the VM made by one run will never be kept.
If you have a comprehensive set of tests it can be possible to build a tool to allow you to very easily zero in on a fault if one gets introduced into the system. If someone has pushed a set of changes into a project then those changes may have affected dozens of files and hundreds of tests. In addition there may have been 50 or more commits in that change set.
If you know that tests start failing then it would be possible to roll back to the last commit which all tests pass then by moving forward one commit at a time unit a test fails. At that point we can see which lines in which files have changed, and what lines of code are covered by the failing tests.
What we want is is to know is which lines are in common between the changes and the coverage of the failing tests. If the commits are small changes and the coverage of each test is tight then in many cases the developer can be directed to an area of 1-2 lines of code where the bug exists.