Just recently I got the opportunity to use yet another continuous integration service: Codeship Continuous Integration.

The hosted service builds GitHub and Bitbucket projects and offers various options for deployment. This post will give a brief overview how to build and deploy with Codeship.

Simple Setup

Setting up Codeship to build your projects is quick and straightforward: Sign up, select a repository, enter the build commands and configure where to deploy.

Sign Up

You can sign up with your GitHub or Bitbucket account. Right after that you can select the repository to be built from a list of repositories that you have access to.

Build

Next, you will be asked to set up the commands to run the build. You can choose from a list of templates for popular technologies like Ruby, Python, node.js, PHP, Java or just enter a command like mvn --quiet verify.

From now on, whenever you push to your repository a build will be triggered and Codeship will
1. clone the repository
2. cd into the work directory of that clone
3. checkout the commit to build
4. and execute the command(s) that you entered to run the build

The screenshot shows the build progress – and progress is at a fast pace. I made the first test-drive of Codeship with a Maven-based build with a large unit test suite and (UI) integration tests. It takes almost ten Minutes on my local machine with good computing power but finishes in little more than six Minutes on the Codeship infrastructure. All in all the perceived performance is real good.

Deploy

Now that your first build succeeded you will probably want to deploy the artifacts to a place where they can be downloaded or put into production. The ‘Project Settings’ page has a ‘Deployment’ tab under which you can choose from a list of deployment options.

For popular PaaS providers like Heroku, EngineYard, Google AppEngine and the likes, there are ready-made forms. You just need to fill in the information that the respective provider requires.

If none of them matches your needs, you can always specify a custom script – for example to copy the build artifacts to a download server with scp or sftp. A key pair is created for each Codeship project whose public key can be placed on the remote server to authorize the build server.

Multiple deployment steps can be assembled to a deployment pipeline, and the order in which the steps should take place can be specified. A deployment pipeline (of one or more steps) is always assigned to a specific branch. Thus, you can, for example, deploy all commits on branch ‘production’ to the production system and set up another branch to deploy to test or staging systems.

Team Members

Unlike, for example Travis-CI, all Codeship builds are private, even those of the free plan and of open source projects.

For others to be able to see build output, change settings or re-run builds they need to become ‘Team Members’. You can select your future team members from the list of repository collaborators or invite them by email.

Skipping Builds

Codeship builds every commit that is pushed – independently of the branch it appears on. To skip builds, you can add --skip-ci or [skip ci] to the commit message of the last commit before it is pushed and that push will be ignored.

And then there is another reason you may want to skip certain builds. If a repository has disconnected branches, it is likely that they contain unrelated artifacts, e.g. source code in ‘master’ and the project’s homepage in ‘gh-pages’. In such a case you certainly need different build commands for each of the branches, or no build at all for one branch. Otherwise, the build would fail each time a commit to ‘gh-pages’ is pushed because it tries to run the build commands suitable for ‘master’ but not for ‘gh-pages’.

To work around the issue, you could wrap your build commands in a script that skips the build execution if the commit is not on the right branch.

#!/bin/sh
if [ `git name-rev --name-only --refs=refs/heads/* $CI_COMMIT_ID` == "master" ]; then
  exec ./run-build.sh;
fi

Pull Requests

Codeship not only builds every commit that is made by repository collaborators but also takes care of pull requests. Every commit in the pull request triggers a build that – once done – leaves a comment in the pull request discussion.

That way you can see if a pull request breaks anything without any extra effort.

If you don’t want pull requests to be built or prevent them from being deployed you can evaluate the $CI_PULL_REQUEST environment variable and act accordingly.

Build Status

By default, email notifications are sent for all failed builds. This policy can be changed to receive notifications for your builds and the master branch only.

The build status can also be sent through various other channels like Hipchat, GitHub’s commit status API, Campfire or webhooks. And you can of course embed links to status images on your project’s home page.

Give Codeship Continuous Integration a Try

Now it is your turn to take Codeship for a spin if you like. You’ll be up and running really fast. In case you need assistance, search the documentation or use the chat window to directly talk to the Codeship staff.

The service is free to use for open source projects. Beside that you have 100 builds per month free for up to five private projects. And of course there are commercial offerings for higher demands.

• Author
• Recent Posts

Follow me

Rüdiger Herrmann

Routined programmer, team lead, presenter, blog writer, and convinced open source contributor with two decades experience in the field.

Strong focus on quality backed up by agile methods like test driven development, modularization, pair programming, clean code, continuous integration.

Specialized in Java with JEE, REST, OSGi, RCP, RAP and building developer tools based on the Eclipse IDE and Visual Studio Code.

Follow me

Latest posts by Rüdiger Herrmann (see all)

• Extras for Eclipse: Neon Update - 6. July 2016
• What’s the Difference? Creating Diffs with JGit - 16. June 2016
• Terminate and Relaunch in Eclipse - 19. April 2016