Archive for the ‘hosted services’ Category

Getting Started with Subversion or Git

September 17, 2010

A guest post by Mark Bathie, CTO of Codesion – a provider of version control hosting in the cloud.

For most software developers the question is not whether you should use version control, rather, what version control tool you should use. The most widely adopted is Subversion, but Git is the fastest growing.

Both are good, popular choices, but there are some core differences. Subversion, a centralized version control system, forces all developers to commit to a central server, whereas Git, a decentralized system, encourages many-to-many merging. For example, with Git you can merge to a fellow developer before merging with a central node (if there is one). There are other key differences I explore in this blog post and summarized below.



  • Centralized control, meaning its easier to keep one official history. Good for backups, accountability and security.
  • Security: Native subdirectory-level user access restrictions
  • Branches are easy and stored centrally
  • Gentlest learning curve for newbies, and operations like branching become quite intuitive as you progress
  • Ability to lock files, ensuring that others don’t work on the same binary files assets like documents & media files simultaneously
  • Widest adoption amongst developers
  • History of changes can’t be modified

  • Working offline means you can’t commit changes to the centralized repository until you have Internet connection, although this does not prevent developers from working on their local copy.
  • Generally slower than Git, since most operations need to synchronize with the central server, especially when merging large branches
  • Possible to revise history and preserve only their successes, not their failures



  • Decentralized model means many operations are faster, and makes offline work more practical
  • More merge options which are generally faster than Subversion
  • Branching is easier and faster
  • Comes with many tools like ‘bisect’ that can partly automate the process of finding where a bug was introduced

  • The local copy model means you need to be more careful of backing up your own workstations
  • The large set of commands can be esoteric and present a steeper learning curve
  • There are no locking for files which can cause issues with binary files
  • History can be changed, being able to edit past commits might not leave the strong paper-trail you’d prefer

Now that you’ve chosen your version control system (or your team has chosen for you), you’ll want to get up and running quickly. Here are some of the basics you’ll need to checkout and commit to a Subversion or Git repository.

If you’re creating a new project from scratch, you’ll need to add some files to a fresh repository. The first step is to create the blank repository. You may need to talk to your sysadmin to set this up for you, or use a cloud provider like Codesion. Once you have your repository access URL, checkout your files.

Checkout and Commit Using Subversion

Checkout your repository from the server to your local computer (your sandbox).
$> svn checkout –username mbathie

Now change into the directory and add a file.

$> cd mywidget

$> echo ‘echo “hello world”’ > hello.bash

Tell Subversion it should include this file (and any others) in the next commit, and in the repository from now on. Do this by using the “svn add” command.

$> svn add *

A    hello.bash

Then commit your new files to the server.

$> svn commit -m “adding my first file”

Adding         hello.bash

Transmitting file data ..

Committed revision 1.
Checkout and Commit Using Git

Checkout your repository from the server to your local computer (your sandbox).

git clone
This will prompt for your password, and then display the following

$> git clone

Initialized empty Git repository in /mywidget/.git/


Change into the directory and add a file.

$> cd mywidget

$> echo ‘echo “hello world”’ > hello.bash

Tell Git it should include this file (and any others) in the next commit, and in the repository from now on. Do this by using the “git add” command.

$> git add hello.bash

Commit the file to your local Git repository.

$> git commit -m “my first commit” hello.bash

Share your changes with other team members. In this case, we’ll push the changes to the designated central repository.

$> git push origin master

The remote Git server will respond with something like the following.

$> git push origin master


Counting objects: 3, done.

Writing objects: 100% (3/3), 228 bytes, done.

Total 3 (delta 0), reused 0 (delta 0)


* [new branch]      master -> master
Joining an existing project is essentially the same process as creating a new one, except when you perform the initial checkout or clone operation, you’ll be pulling down the files relevant to the project you are joining. You won’t be checking out a blank repository. You can then use the same commands above to add, commit and push your changes and share them with other team members.

Underdoing The Competition

September 6, 2010

Hosted, low-cost, internet-based services for software developers have been in existence since the formative years of the web itself. In their earliest incarnation, such services would usually involve obtaining some real estate on an Apache web server, accessible via FTP, with the ability to upload a web application and invoke some server-side technology (Perl/CGI hacking anyone?) to create the latest and greatest dot-com experimental idea for a business. Or maybe just a simple website.

Zoom forward a few years and these services start to encompass functionality that provides a platform for the activity of development itself. For example, hosted version control, issue tracking and task management applications. Now smaller web-based development shops, who are already used to renting infrastructure for their production environments from a hosting company, start to use these complimentary services – particularly when team members are not co-located. In fact, developers soon discover that these tools promote a model that supports geographically dispersed teams, and these ideas really begin to take root, like much technology these days, amongst the open source software community. The likes of Sourceforge for example, begin to acquire many thousands of projects, both large and small, due in part to providing accessible, web-based collaboration services for development. For private projects, pay-for services such as those provided by CvsDude (now Codesion) and Collabnet start to combine the power of the ideas taking root in the open source world with the industrial strength security and data protection required by larger IT businesses.

And here we are today, with a proliferation of Software-as-a-Service (SaaS) companies that offer a full range of services along the application lifecycle management continuum. Certain types of services lend themselves well to the SaaS model – the barrier to entry is relatively low, especially when the tool or service is already web-enabled. An example is hosted bug tracking solutions. These are implicitly suited to the multi-tenant application model used by most SaaS businesses. They have a very predictable resource consumption profile and a security model that easily supports multiple users. Data protection and recovery can be usually handled using industry standard practices for RDBMS management. There are a lot of businesses that offer these types of services.

When we look to other services along the ALM continuum, hosted SaaS offerings are few and far between, an example being services that support Continuous Integration. Hopefully, by now, all thinking software engineers believe that CI is integral to the practice of modern software development. In fact, I’d go further, anyone who thinks otherwise is not fit to call themselves a (thinking) software engineer. You’ve no excuse, really, and if you don’t embrace its benefits then CI is likely to be imposed on you anyway.

So, it’s 2009, you have your hosted low-cost SCM system, you’ve got your cheap web based bug tracker and your rented deployment environment (still Apache, or maybe Google App Engine?). You search for “hosted continuous integration” and hmmm…no dice. “Why does nobody do this stuff?” you ask, “Didn’t I read somewhere that its ‘integral to the practice of modern software development’ ?”. I know the answer – a simple reason really – a hosted CI service is damn hard thing to deliver.

For a hosted solution to be low-cost and truly multi-tenant it needs to be very efficient with resources. This usually involves sharing of such resources amongst many users, a model which does not easily lend itself to CI. Secondly, a hosted solution must be secure, especially with respect to user data. User data in the world of CI includes source code, build metrics and the built artefact’s themselves. Reconciling resource optimization with data security is the biggest challenge here. To illustrate this point, if such a solution provided every user with a dedicated, isolated, physical environment for their builds it would need to incorporate the associated costs into the offering. This would quickly place the service into the realms of ‘expensive luxury’ for our small agile team example. As a comparison, consider Codesions ‘Team Edition’ for hosted Subversion which starts at $6.99/month. To be competitive, the CI provider has to get very clever with shared resource optimization while still ensuring data protection and security for its users.

In addition to data protection and resource management, there are additional security concerns relating to what a build can be permitted to do in such an environment. This is usually never a concern for an on-premise CI server. Want to scan for available ports, open particular sockets or start and stop certain daemon processes? No problemo. However, I’m afraid that in the shared real-estate scenario there are some necessary limitations on what build tools might be able to do. This is something of a compromise that a user has to take on the chin if they wish to use a low-cost hosted solution. If their build process requires a bunch of ‘non-orthodox’ things to happen, they need to understand that these types of advanced builds will never play well in a shared environment. But…if your project conforms to the standard life-cycle of ‘prepare-compile-test-package’ then this model fits much better and probably covers the majority of day-to-day software builds. This is just simple pareto principle logic really – a low-cost, shared hosted solution can only realistically cover the 80% well and assume that its not the right choice anyway for the remaining 20%.

So we’ve articulated some of the challenges of establishing a hosted CI offering, but what are the potential benefits that such a solution might provide to end-users? These may seem obvious, but are worth stating:

  • Zero cost initial implementation for CI infrastructure.
  • Lowers the barrier to entry for CI, simply login, configure project(s) and use it.
  • Significantly reduced software and hardware maintenance costs. Less software hosted internally means less hardware
 required, which also translates into a reduced burden of patches and patch support complexity.
  • Reduced staffing (sorry guys/gals).
  • Better use of skills/ resources.
  • Pay for what you use and no more. Subscription models for SaaS typically allow for cancellation given a months notice. Try-before-buy is very common too.

One final consideration is the range of features that hosted solutions offer when compared with the wide variety of open source and proprietary CI servers available today. There are some very slick options out there that you can download, install, configure and use. At the moment, the available low-cost multi-tenant hosted CI solutions will not win in a feature beauty contest against these tools. However, in my humble opinion this new breed of services offer something quite different, something that sets them apart. To bend a phrase from Bill Clinton: “Its because they are hosted, stupid!”. Personally, I’m a firm believer in the idea that you should (to borrow a concept from 37signals), ‘under-do the competition’. Hosted CI should solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of one-upping, it should one-down. Instead of outdoing, it should under-do. Hosted CI should stick to what’s truly essential.

What’s it Like Using Hosted Continuous Integration

August 19, 2010

We’re always keen on finding out what people think about using MikeCI.

With hosted continuous integration being a fairly new concept we are embarking into new territory and want to ensure that we are heading in the right direction. As a result we’ve been keen on hearing our client feedback to see how they’ve found their MikeCI experience.

Lead Developer, Alex Bertram kindly took some time out of his busy schedule in The Hague, Netherlands to talk about how MikeCI was being used in his Sigmah (previously ActivityInfo) project.

What are you working on?

Project Sigmah is an information management platform designed for humanitarian organisations and was originally developed for UNICEF but has since expanded. The platform allows users to create their own databases online and track, map and analyse performance indicators over time.

Why did you choose MikeCI?

“There aren’t too many choices out there and MikeCI offered the strongest support for our technology stack. Our stack consisted of Subversion SCM, Java and Maven, which MikeCI supported. The great Maven integration provided a simple straight forward environment in which to build our project.”

How has your experience been with MikeCI?

“It’s become pretty key over the last month. Another organization won a grant to expand ActivityInfo (now Sigmah) and hired a team in Paris to add the components they wanted. As we continue development here in the Netherlands for the original client, MikeCI has become the referee that keeps the two teams from stepping on each others toes.

With geographically dispersed teams, we needed a CI server that could be accessed from any location and allowed multiple teams to submit code.

I’ve set up my email account to forward all reports from MikeCI to our development mailing list, so everyone is getting a pretty constant stream of activity with updates and code reviews from SVN, build reports, etc. It’s nice.

We are really embracing cloud computing solutions by using and developing SAAS software. Our team uses Google Apps, ProjectLocker for SVN, Amazon EC2 and Google App engine and of course MikeCI.”

How could MikeCI be improved?

“For me the next great thing would be making the results of the build available. It would be awesome to be able to link to the most recent javadocs or code coverage reports, or just a big widget for the forge site.

Also having some sort of API would be terrific as this would help us automate releases and deployment to the server, which we’re trying to do every 2-3 weeks.”

MikeCI – Developing an API has always been on our agenda and is certainly something we would look to include on our roadmap. Similarly making builds available publicly is something we would like to include somewhere down the line.

A big thanks to Alex for his input and we wish him all the success and many happy builds to come.

If you would like to share your experiences with MikeCI or try MikeCI with a free 30 day trial, then email or register here today.

Try MikeCI Today

Kiln Repository Support

May 25, 2010

Today we are pleased to announce support for projects hosted within Kiln On-Demand repositories.

Kiln Logo

For those of you who are unfamiliar with Kiln, it is based upon the popular open source Distributed Version Control System (DVCS) Mercurial.

We have created a short screen cast that demonstrates this new feature using the Java Petstore (built using Maven) as an example project.

You can also find additional information about our support for Kiln in our new, comprehensive, on-line user guide

Bootstrap your Agile Java Startup Infrastructure in < 30 minutes

March 25, 2010

So, you have a great idea for the next web-based killer application. You have assembled a small but geographically dispersed team with the requisite amount of Agile Java development-fu to get the job done. What you need now is some hosted infrastructure so you can all get to work effectively.

In less than 30 minutes.

Step 1 – Get some IDE

Get Eclipse Galileo (JEE version). Hopefully your pipe is fat enough (~190 MB download). Fire it up and use update sites to obtain m2eclipse and subclipse (we’re assuming SVN for a repository, but you could use Git). Install Tomcat and configure as a server.

Step 2 – Get some Scaffolding

Within Eclipse go to File>New>Other, to open the Select a wizard dialog. From the scrollbox, select Maven Project and then click Next. Move through the wizard to select an archetype of an appropriate type (e.g. Appfuse). Click Finish. Validate you can build and deploy your app.

Step 3 – Get some Version Control

While you are waiting for your build to complete, pick a hosted version control provider. There are a number who provide low-cost or even free hosted Subversion for private projects, typically with a trial period. Here is a list. Once signed-up with a clean repository, use subclipse to share the scaffolding app created in (2).

Step 4 – Get some Project Tracking and Wiki

The majority of providers listed in (3) also offer something in the area of hosted task/issue tracking apps that often have sufficient wiki capabilities. Alternatively you can try those who specialise
in this area such as FogBugz or Agilo. We use Agilo on Mike. And you might want to get Basecamp. We use that too.

Step 5 – Get some CI

You could roll your own on Amazon EC2, but that isn’t happening in 30 minutes or 30 hours, probably! Hmmm…Oh I almost forgot – you could use our excellent hosted service ;).

Step 6 – Get some BRM

Whats a BRM? Its Binary Repository Manager. If you’re using Maven, I’d recommend you use one. The only hosted one I’m aware of is provided by Artifactory Online.

Right. We are good to go. What are you waiting for?