I have recently been part of a group that has released, SpiffyUI, a new GWT framework as an open source project. One of the things that we have taken for granted in our full-time positions is the infrastructure we have available for any projects we start in our walled garden. As well as version control we are able to associate team collaboration tools like wikis, continuous integration (CI) services, continuous deployment instances and continuous analysis like sonar. We can also publish artifacts to our maven repositories for other projects to consume.
In this article I want to describe how we managed to use various exceptional resources to be able to check-in source code and automatically build and publish artifacts from our project to a public maven repository. Since we are an open source project the resource providers allow us to do this without having to pay money for their services.
Code Hosting
There are a plethora of version control and code hosting services that we could choose from, though we elected for Google code. It was a close thing between that and github, but the majority of the team were more familiar with subversion rather than git. Google code provides us with a core set of services to allow our project team to work together. Importantly, we get a wiki to start documenting different aspects of our project. We also get an integrated issues area to use for bugs and new feature requests. Finally, there is a way to enable a code review service that people can use to submit patches that the team can review, and it integrates into both the source control and the issue system.
Continuous Integration
CI was solved by CloudBees. They provide a Jenkins instance for projects hosted on their servers. As an open source project we are restricted to a 300 build minutes from their m1.small profile, for our build per month. This forces us to be mindful of the frequency of our automated build jobs. We only have access to their essential Jenkins plugins to use in our builds. With all of that in mind, we still get everything we need to build our project, publish the checkstyle results and deploy artifacts to a maven snapshot repository.
We poll the svn repository every 4 hours. As a side note this also serves as the first opportunity for the project team to get informed about any build failures after recent svn commits.
One thing we make use of, to be able to isolate the publishing credentials away from the build files, is a private filesystem area that CloudBees makes available to all of their hosted projects. This allows us to place a custom maven settings.xml file in the private folder, and reference it from the Jenkins build job. Through maven profiles we can use a special set of credentials that identify the cloudbees jenkins build as the source for snapshot deployments.
Maven Repository
For the maven repository we elected to sign up our project on the Sonatype servers. They allow open source projects to host their release and snapshot maven artifacts on the sonatype servers. They can also synchronize artifacts over to maven central. Their documentation is awesome, and through their JIRA system you can register your project and get team members added as users who can deploy to your project repositories. With this in place projects that are using our snapshot builds will have access to binaries built with the latest code.
Continuous Deployment
The final part of our infrastructure which is not automated at the moment, is our use of Google app engine to deploy a running instance of our sample application.
Over time this could be built upon to generate a continuous deployment server that could use the latest snapshot artifact to host an integration test application.
