Make software-projects fit for git

More and more Projects at our company are taking advantage of distributed and local revision control by using git. So to make a complete software-project fit for git, by not only using git-svn with subversion and git on top, some more steps are required than just handling files with git, learning its syntax and understanding the way it works…

Source code has to be accessible.
We are used to use subversion, a central repository with the leading stage of developement, when using git – all repositories are equal. To take the best of both worlds we host a git-repository, which is defined to be leading (only by convention). We like to have things under control, so we use gitosis to serve these repositories, but we think about using gitolite because of better/easier access-management. You can also host at GitHub, they do great work and it´s their daily business.
What else do we need to develop an amazing piece of software in addition to good code and a working methodology? Which tools assist the development process and need capability to handle git-repositories?

Software should do what it is intended for.
To reach this goal we collect production requirements and fragment the subsequent work into processable packets with a project-management tool called redmine, more precisely chiliproject, an rapidly evolving fork of redmine.

Software is something executable,
plain source-code is for documentation purposes 😉
We have to build it. Most of our projects are written in Java and built with Apache Maven. To build the written code automatically and pursue the process of continuous integration we utilize a tool named hudson, more precisely Jenkins, an Oracle-independent fork (yeah we like using forks, especially when main developers from the origin project are switching to the new fork, if you are interested in all of our reasons read the blogpost written by Fabian)
So first mission is to make ChiliProject fit for git.
Luckily ChiliProject can handle git-repositories out of the box, but the repositories have to be cloned to localhost(the machine running chiliproject). This can be achieved by giving read-rights to the user running chiliproject, in our case this is generating a passwordless ssh-keypair, deploy the public part of it to gitosis and explicitly give rights to this public-key. To use the generated private-key every time we use git (in conjunction with ssh) we have to modify the file ~/.ssh/config:

Host            git.domain.tld
User            git
IdentityFile    ~/.ssh/git_key.priv

Now we need to clone the repository manually by login to the machine running Chili and do:

mkdir /path/to/git/repositories/
cd /path/to/git/repositories/
git clone git@gitosis.domain.tld:gitrepo.git

for sure git has to be installed on the server running Chili. And the repository already exists…
but how do we keep this cloned repository up to date? We solved this by installing a cronjob running as the user, running Chili, every 5 minutes:

*/5 * * * * for i in /path/to/git/repositories/*/; do cd $i && git fetch; git reset refs/remotes/origin/master; done >>/dev/null 2>&1

jap, you can log into a file instead of /dev/null, but we trust… 🙂
that´s it you can now add the local repository to your project in ChiliProject, but give full path including the “.git”-folder, it is little fussy in this point.
Get Jenkins to work with git
First, we have to do the same things done for ChiliProject, install the git-binary on the system running Jenkins, generate ssh-keypair, give read-rights to the user(possible stumbling block: we are running jenkins in a java-servlet-container so it´s the user running this container!)
modify ~/.ssh/config. Now we should be able to manually clone the targeted repositories, but that´s not what we want (remember automatically and continous integration?)
In order to be able to tag the built release version, the user running jenkins needs to give an author to the git-repository, so modify/create ~/.gitconfig of this user:

[user]
        name = "Jenkins"
        email = "jenkins@jenkins.domain.tld"

Jenkins is not able to handle git by default, we have to install a plugin: login -> Jenkins -> manage Jenkins -> manage plugins -> available -> Git plugin (that´s easy to remember)
After restarting Jenkins you´ll find, under “projectX”/configure -> Source Code Management, the new section git where you can insert the url of your repository -> save
Finally you can build the project(small prayer could help 😉 ) and enjoy the built software and Jenkins´ expandable workflow…