Posts Tagged ‘GitHub’

New Mike Release with GitHub integration and Functional Testing support

March 18, 2010

We are very pleased to be able announce a new release of our hosted CI platform. The release includes some major enhancements to allow our users to do much more with their builds while at the same time ensuring that they happen within a highly secure, controlled environment.

Here is summary of the new features:

CI support for projects hosted within public or private GitHub repositories that use Ant, Maven or Eclipse.

Each build is now executed in an entirely separated environment, which allows our users to:

  • Start, stop and deploy to embedded containers as part of their build process (e.g. Jetty or Glassfish).
  • Start, stop and deploy to provided (by Mike) instances of Apache Tomcat (v5 and 6) as part of their build process.
  • Run integration and functional tests, using frameworks such as HtmlUnit or JWebUnit against applications deployed to said containers or instances.
  • Fork additional processes as part of a build, such as bash scripts and other non-Java based tooling.
  • Use the full range of available Ant tasks and Maven plug-ins as part of a build.

Security hardening:

  • All network communication within Mike is encrypted using either key or token-based authentication.
  • All outbound network access from a build is transparently proxied and validated.
  • IP protection: all builds run in a clean, repeatable sand-boxed environment and all source code processed by a build is accessed using token-based authentication over encrypted channels. See the security section of our website for further details


  • Support for Maven Ant Tasks (v2.1.0) – Ant-based projects can now use Maven dependency management for their binary artefacts.
  • Gravatar integration for developer email addresses.

Be sure to check out our no-obligation, 14-day trial. You simply need to provide us with your company/project name and an email address. You can also use our sample applications to rapidly get started and experience our platform features. Our prices start from only $10 per month.

Working with Custom Maven Archetypes (Part 2)

January 26, 2010

In part 1 of this series of blog entries I demonstrated how you can quickly create a custom Maven archetype. This nice feature of Maven allows you to produce template or skeleton projects, which are great for bootstrapping your development efforts. In this second part of the series, I’ll show you how to ‘production-ize’ your archetype, which involves the following steps:

  • Add your archetype to version control
  • Update the appropriate metadata elements in your archetype’s POM
  • Release your archetype using the maven-release-plugin

Step 1 – Add your archetype to version control

I decided to use Git as the VCS (version control system) for my archetype. This is in part due to the fact that we will soon be releasing a new version of Mike that supports projects hosted on the popular ‘Social coding’ site GitHub. GitHub offers free project hosting for ‘public’ (AKA open source) projects.

So, lets get down to business. First off, you must have the Git client installed of course. If you are on a flavour of *nix this is a cinch, but there is tooling support for other OS’ including TortoiseGit, from the creators of the popular TortoiseSVN client. As there are already plenty of tutorials about using Git, i’m not going to replicate all steps here. Try Git for the lazy if you are time poor, for a good intro.

First up, I navigate to a directory, initialise my Git repository and add my fledgling archetype:

~/foo$ cd mikeci-archetype-springmvc-webapp
~/foo/mikeci-archetype-springmvc-webapp$ git init
Initialized empty Git repository in /home/leggetta/foo/mikeci-archetype-springmvc-webapp/.git/
~/foo/mikeci-archetype-springmvc-webapp$ git add .
~/foo/mikeci-archetype-springmvc-webapp$ git commit -m "Initial commit"
Created initial commit fad815f: Initial commit
 13 files changed, 513 insertions(+), 0 deletions(-)
 create mode 100644 pom.xml
 create mode 100644 src/main/resources/META-INF/maven/archetype-metadata.xml
 create mode 100644 src/main/resources/META-INF/maven/archetype.xml

Now that i have my archetype added to a local Git repo, I want to share this via GitHub. This obviously requires a GitHub account and you also need to ensure you have added a public key to provide you with the requisite privileges to ‘push’ your changes. Once you’ve set up a bare repository on GitHub, you can execute the following commands:

~/foo/mikeci-archetype-springmvc-webapp$ git remote add origin
~/foo/mikeci-archetype-springmvc-webapp$ git push origin master
Counting objects: 34, done.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (34/34), 21.23 KiB, done.
Total 34 (delta 1), reused 0 (delta 0)
 * [new branch]      master -> master

What did I just do? The command remote add origin [url] adds the location of the remote GitHub repository to my local repository configuration and calls it ‘origin’. When I type push origin master this sends or ‘pushes’ my local changes on the ‘master’ branch to the ‘origin’ server. The ‘master’ branch is one that is created by default for me when I initialized the repository above.

Step 2 – Updating the POM

For Maven to function effectively, you should always ensure that you include project VCS information in your POM file. Now that we’ve added the archetype to a Git repository we can include the appropriate <scm> configuration:


It’s important to understand the meaning of each of the child elements of <scm>. The <connection> element defines a read-only url and the <developerConnection> element a read+write url. For both of these elements the url must adhere to the following convention:

 scm:<scm implementation>:<scm implementation-specific path>

Finally, the <url> element content should point to a browsable location and for me this is the GitHub repository home page. Note that in all cases, I’m using an interpolated value which is my project artifactId.

One handy tip is that you can verify this configuration by using the maven-scm-plugin. This plugin offers ‘vendor’ independent access to common VCS commands by offering a set of command mappings for the configured VCS. The validate goal should confirm all is well:

~/foo/mikeci-archetype-springmvc-webapp$ mvn scm:validate
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'scm'.
[INFO] --------------------------------------------------------------
[INFO] Building MikeCI Spring-Mvc web application archetype
[INFO]    task-segment: [scm:validate] (aggregator-style)
[INFO] --------------------------------------------------------------
[INFO] Preparing scm:validate
[INFO] No goals needed for project - skipping
[INFO] [scm:validate {execution: default-cli}]
[INFO] connectionUrl scm connection string is valid.
[INFO] project.scm.connection scm connection string is valid.
[INFO] project.scm.developerConnection scm connection string is valid.
[INFO] --------------------------------------------------------------
[INFO] --------------------------------------------------------------

We also have to update the POM to tell Maven (or rather, the maven-deploy-plugin) where to deploy snapshot and released versions of our archetype. For the time being, i’m just going to specify my local filesystem as this destination, but in a real world example this would most likely point to a location appropriate for a Maven repository manager, such as Nexus or Artifactory:


Once satisfied with the POM modifications, I commit to my local Git repo and then push the changes to GitHub.

Step 3 – Releasing the archetype

So, i’m now almost ready to create my first early release of the archetype. I can accomplish this using the maven-release-plugin. This plugin exposes two major goals – prepare and perform.
The prepare goal does some pre-flight checking by running a build and verifying all is well before promoting the version in the pom and creating a tag of the release. The perform goal then checks out this tag, builds the project and deploys the resulting artefact to the Maven <repository> specified in your <distributionManagement> section.

Its always a good idea to use the most recent version of the maven-release-plugin, which is currently 2.0-beta-9. This will require a further POM modification and Git commit+push:


Next, run the release:prepare goal. By default this runs interactively, prompting you in your shell to provide info about the release version and subsequent development version:

:~/foo/mikeci-archetype-springmvc-webapp$ mvn release:prepare
[INFO] Scanning for projects...
[INFO] --------------------------------------------------------------
[INFO] Building MikeCI Spring-Mvc web application archetype
[INFO]    task-segment: [release:prepare] (aggregator-style)
[INFO] --------------------------------------------------------------
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for "MikeCI Spring-Mvc web application archetype"? (com.mikeci:mikeci-archetype-springmvc-webapp) 0.1.2: : 
[INFO] Release preparation complete.
[INFO] --------------------------------------------------------------
[INFO] --------------------------------------------------------------

Then run release:perform. If it all goes smoothly, you should have something akin to the following in your remote repository:

~/foo$ ls -1 release-repository/com/mikeci/mikeci-archetype-springmvc-webapp/0.1.2/

So, to summarise, I now have the appropriate configuration management in place to make changes to my archetype and release it to a Maven repository.
In the next part of this series, I’ll look into the different ways you can integrate your archetype into the development process.

Why DVCS won’t kill Subversion in 2010

January 21, 2010

At Mike HQ we are currently implementing support for GitHub as this has been requested by a number of our private beta participants. We like Git and are currently undergoing an internal debate/argument as to whether we should switch (no pun intended) to a DVCS from Subversion for our own source code management.

I was going to write something that discussed why, although we might decide to use Git ourselves, it isn’t suitable for everyone – I firmly believe that Subversion usage will continue to thrive in 2010.

However, after searching some, I discovered a comment from this blog entry which more or less summed up my own thoughts. I’m simply going to reproduce it here verbatim (courtesy of clr_lite whoever you are):

  • distributed version control is not for everyone
  • too many people are enamored of a tool or something because it’s new
  • every organization has it’s own situation and needs
  • getting a full repository and allowing people to work in silos without collaboration is not necessarily a good thing
  • git addresses the needs of linux kernel development, with many contibutors funnelling to a gatekeeper
  • some development shops benefit from a locking checkout model which forces developers to communicate and plan
  • subversion has a lot of users and knowledge pool; this can be important for some situations
  • distributed model has it’s plusses; getting all the history, changes, diffs, etc, while offline can be real helpful, but it all depends on the nature of the development and the developers
  • no one tool or process is ‘right’ for everyone

Well put, I thought.