>Git + Hudson = New Ways to Develop

>One of the things over the last six months that has changed and improved the quality of code I produce, has been using git and Hudson. I wrote a while ago about how you can setup local builds of a system using git and Hudson. The advantage here is that Hudson will automatically run if there are changes in your local git repository. I can’t tell you how many times when working on various projects, both commercial and open source this has saved me. Especially when I’m not working on a project that is tied to one particular IDE.

Just because it works in my IDE doesn’t necessarily mean it’ll work in the build. Having Hudson run the build locally, helps catch the errors that I would have pushed otherwise to the main repository. There is an a fundamental requirement of Test Driven development, to run the tests often. Hudson and Git have allowed me to do that with more ease. Once I know the local build from Hudson succeeds, I’m fairly confident that I can push the changes to the main repo.

The other advantage git lets me do is work in a branch and then merge back. I can setup the local build to pull from that branch and when I’m ready, I can either rebase my commits in the branch, or bring them in as they are. By integrating and running a build locally before I push to the main repository, I’m again fairly certain I’m not breaking the build or anybody else.

Another thing running Hudson locally enforces, it makes sure that your build can be run by anybody on any machine. It’s not tied to a particular platform. One thing many eclipse builds still struggle with.

For those that are still on the fence, waiting for eGit to get to the point of CVS integration at eclipse, you really are missing some good productivity and code quality gains. I’ve been using eGit off and on for some projects, and it really is very close to hitting that 80/20 threshold. It really does need the critical Pull ability, and a Recursive Merge. Otherwise it is almost ready for daily use.

If you are an eclipse user, and still haven’t given git a chance, you really should.

Advertisements
This entry was posted in build, eclipse, hudson. Bookmark the permalink.

3 Responses to >Git + Hudson = New Ways to Develop

  1. AlBlue says:

    >One of the things that I have done in past projects is to have a separate CVS tag (or SVN branch) to denote code that has compiled successfully, or code that has been tested successfully e.g. with TESTED or COMPILED tags.With Git, these are even easier, since they can be used as movable branches on the master line. You can develop(e) code against the known-good branches even if the stuff in HEAD is still changing.Git can also be used to record the state of code from a build system, by creating a tag (immutable branch) to record specific releases or builds. Since tagging is virtually free, you can create a tag for each build very easily. They can even be signed to verify the authenticity of the branches.Lastly, Git also has other features, like Git notes (see http://www.kernel.org/pub/software/scm/git/docs/git-notes.html for more). You could use this to e.g. record the state of the README.txt at points during the development of the project separately introspectable by tools outside of the repository's contents.Finally, EGit is usually written with a capital E and capital G. 🙂

  2. >Good points. However I think having true merge in EGit is essential before starting to use it.Also I believe you missed the case where people write JUnit tests that test UI components. At least for Riena we have roughly 900 unit tests for the UI and not only do they take a while but they also require that no one uses the computer (keyboard and mouse). So a local hudson does not really work for all usecases.but interesting post. I like the part about the improved code quality. I know a number of people who claim that everything that can be done with Git can also be done with CVS and I dont think thats right.

  3. David Carver says:

    >@Christian If you are running on Linux/Mac/Unix etc the answer to the UI testing is to make sure that you have the XVNC plugin enabled for Hudson. This will allow your ui tests to run in a separate virtual window. For a Windows machine, then a virtual machine might be best to run the build in so that it again it has it's own virtual screen that it is running in.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s