1

I will be moving to git for my version control soon. My continuous build system is Hudson and I use maven to build my artifacts.

Anyone have a best practice for setting up git to work best with these other tools.

recommendations on how packages and plugins should be managed in git to most easily pull down into Hudson would also be appreciated.

Please and thank you.

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
Mahdi Yusuf
  • 19,931
  • 26
  • 72
  • 101
  • Actually... http://stackoverflow.com/questions/3209208/what-is-the-cleverest-use-of-source-repository-that-you-have-ever-seen/3209767#3209767: no more hudson ;) – VonC Aug 18 '10 at 19:35
  • @VonC: I'll take more time to reread everything later but I don't see how the solution described by David is that different from a local build (that you are supposed to run before to commit) and I don't think it allows to remove a "central" CI server. *"No more Hudson"* sounds like an exaggerated shortcut. – Pascal Thivent Aug 18 '10 at 20:13
  • @Pascal: "No more Hudson" sounds like an exaggerated shortcut... because it is;) But the fact remains that for private building you don't need a job scheduler. Just another local Git repo with a script for managing the builds and pushing valid ones (i.e. commits that compile) to a remote repo. *There* (i.e. on the remote repo), more complex jobs can take places (static analysis, unit testings, ...), scheduled by Hudson. – VonC Aug 18 '10 at 20:50
  • @VonC: Ok :) Thanks for the clarifying. But as I said, I'll reread all this carefully because I'm still missing the revolutionary part (I guess it's more in the workflow) compared to a "local build". – Pascal Thivent Aug 18 '10 at 22:12
  • 2
    @Pascal: yes the workflow is important: you can keep up committing *while* the other repo is updated (on demand only, no job polling the data). That other repo can be scraped and recreated any time (to avoid any 'cache' effect). And it can do more than just local build (quick unit testing or small static analysis can actually be done there as well, in the comfort of your *local* workstation, without depending on the network). Again, main advantage: lots of local tasks (build, test, analysis) done locally *while* you are still working. Complex jobs are handled on a remote repo. – VonC Aug 19 '10 at 05:49
  • @VonC: This sounds interesting, I'll just need some time to digest everything, do some experimentations :) Thanks for the follow-up. – Pascal Thivent Aug 19 '10 at 08:14

1 Answers1

6

We are using git-maven-hudson daily.

For hudson there is a git plugin which works great and has a killer feature.

Maven takes care of its own dependencies and does not need to know about either git or hudson, which makes for nice decoupling and less moving parts.

Now for the killer feature :

We work ticket based. In git we use a branch per ticket and do all development for a single ticket on that branch. When ready to share we push the branch to a central repo. The Git plugin will check and load all new branches, merge them to the master and compile/run tests/deploy to Nexus and push the patches to the master branch.

We pull regularly from the master branch to keep close to head.

This works incrediby well with hardly any merge conflicts on the server.

Peter Tillemans
  • 34,983
  • 11
  • 83
  • 114