Migrating to Git
At work, we made the move from subversion to git as our version control tool. I used git for a few times before we migrate the whole project thanks to the git-svn bridge, and, apart from the usual headache when it comes to merging branches, I was rather convinced we would make the migration to git. To explain what branching model I was expecting to use, I dig the Internet for a good tool, hoping to migrate our so “1.0″ Trac version control and issue management to a more github like one.
There is not as much tools as I first thought, I found gitorious, which seems to be a good tool, but it looks complicated to setup and lacks (or I didn’t find it) a good graphical representation of the branches in the repository.
I came across gitlabhq, which is a starting project, but promising as it aims to mimic github in many ways. I’ve tried it and I must say I am very impressed, it is now one of the tool we use internally, it is not yet a perfect tool but it does its jobs very well. We still use our old Trac environment with git integration to hunt down our bugs and control ticket workflow with commit messages (blog post to come). We also use Trac’s wiki to write our internal documentation toward developpers.
After Continuous Integration, this is the word we see on the web these days. Its meaning is really simple, it consists in reducing steps in application deployment. In order to do so a set of tools actually exists, you can use the same PaaS images (thanks to the newcomer Micro Cloud Foundry by VMWare or use a special amazon ec2 instance) to have a development environment similar to production one. And you can use Chef to manage and automate your configuration. While these alternatives are really interesting, I think they are way too powerful and difficult to setup in simple cases.
I will explain my “simple” solution based on maven, shell scripts and hostname detection.
Example release archive
An example is better than a thousand words, you will find an example of my solution in a github repository Easy Release Archive. It is a maven project building a zip artifact containing everything to be deployed, and an example script to setup the Glassfish server.
What is inside ?
To understand how it works, the best thing is to look what’s inside.
- an assembly.xml file describing the files to include and their output name and location.
- a few scripts in /src/main/resources
- sanityCheck.sh : helper script sourcing the correct variables depending on the hostname of the machine and ensuring variables are correctly setup
- setupGlassfish.sh : a sample script used to setup a Glassfish server with its required datasources and other parameters
- a global folder containing global configuration files
- a per hostname folder (in my case samva-mbp) containing a shell/envSetup.sh shell script to setup necessary variables and a config folder for special environment configuration files.
- the pom.xml file describing artifact versions to use in the assembly and the lifecycle to use.
A simple mvn package will build the zip archive with everything described in the assembly.xml file. You will just have to unzip and run the script(s) corresponding to the application deployment for it to be done. You can add this command line to your build server and you will have a simple but powerful continuous delivery system !
I use JRebel to speed up my development. It is a really impressive tool allowing to develop full blended Java EE application as you would develop in PHP. No redeploy, at the cost of a little slow-down in development mode. The tool does what it says, and it’s worth the price ! The JRebel plugin for maven does the job very well by generating the
rebel.xml file that does the magic.
What’s the deal ?
Although JRebel is an awesome tool, there is some magic within, and, in special corner cases it might not work as expected. In my case I have a quite typical web application split in multiple parts:
- a web application (war)
- an ejb module (jar)
- other modules not involved in my problem
The web application includes, in its
WEB-INF/lib folder, the ejb-client artifact of my ejb module. To make it clear, ejb-client artifact is typically the jar containing the interfaces to be used by the client module(s).
The problem I had was that JRebel magic was reloading too much things : in fact, it reloaded classes even if they were not in the ejb-client. My application container (Glassfish 3.x) was not very keen on this thing. I opened a thread on ZeroTurnAround’s forum and the answer I got is that I have to find a way to ignore files in my ejb-client module. By digging in maven-ejb-plugin, I didn’t find anything to rename a file in the ejb-client module, and I didn’t find a parameter to pass to JRebel to specify which filenames can contain its configuration.
In my day to day activities, there is one thing I do everytime and I think every developer does : I tail the logs. The problem with logs checking is that you are rapidly facing a huge file, and the classic
tail -f is not enough. The sad part of log tailing is that you only have monochrome logs, without any colouring of any kind helping you identify critical lines against more common ones.