Why did we choose CodeShip?

These days there are plenty of continuous integration services.

We first started to maintain our own Jenkins server, but quickly realised that it was a waste of our time. So we quickly moved to Codeship.

We chose Codeship because:

• The config looked very simple.
• Their support was very responsive.
• Their blog! Seriously, the content is amazing.

So yes, we love Codeship, but all the tips presented here will work with any other CI services out there.

Pivotal Tracker meets Github

Our clients have full access to their Pivotal Tracker project, and Nathalie is the one collecting the status updates.

For those who don’t use it, Pivotal Tracker has a feature card system. Each card has a button to change the status of the card as followd:

  Non started -> Started -> Finished -> Delivered -> Accept / Reject

Thankfully, Github and Pivotal Tracker can talk to each other via Git Hooks.

To link your Pivotal Tracker account and your Github account, you only need to go into your Github project settings -> Service Hooks -> Pivotal Tracker.

Once you have filled in your token and activated the Hook, it’s ready to be used.

From now on, when you push your commit containing the Action and Card Id, it will automatically mark the card as finished.

Actions need to be committed as follows:

[(Finishes|Fixes|Delivers) #TRACKER_STORY_ID]

To finish the card #123 you write you commit like this:

git commit -m "Add Github hooks integration [Finishes #123]"

After a git push, your card will automatically be marked as finished on Pivotal Tracker.

You can read more about this integration on Pivotal Labs blog.

Codeship meets Pivotal Tracker

Codeship is dead easy to use.

You define your project on their interface, then enter some per branch deployment recipes and off you go. Now every time you git push some code, it will pass the tests and deploy the code to your server when it’s green.

But that means we would have to go back to Pivotal Tracker and update our cards status once Codeship has deployed it.

What we were looking for was marking our cards as deployed automatically when Codeship deploy them.

For this we use Tracker Git

First add this gem to your tests group in your project.

gem install tracker-git, require: nil, group: :test

Add a script to your deployment looking like:

traker projectId token

Now, after the deployment, if everything goes well, your Pivotal Tracker cards should be marked as deployed.

Also note, if you are not deploying a Ruby project, you can just add gem install tracker-git then add the traker code on a new line.

Codeship meets CodeClimate

CodeClimate analyses every push, but doesn’t pass your tests automatically, so we are using Codeship to send the test coverage information to CodeClimate.

For this just update your Codeship deployment recipe (we have only amended our dev branch) and add your CodeClimate export key before your rake tasks.

What did it change?

Knowing that your push will finish a certain card, and that this card is tagged in your source control, makes this very easy to go back to if a bug occurs.
The continuous integration / deployment, is one of those things that I will never look back on!
You should never be afraid to deploy. And knowing that every push (to certain branches) will perform this deploy forces to write a deployable code straight away.

The one I’m still unsure about is Code Climate. Don’t get me wrong this tool looks really good. But I’m wondering if our codebase is not too small to really justify the cost of a tool like this.

Peace of mind – we are sure not to push half-baked features, or that a lazy dev won’t pass the suite.
Easy deployment – in fact it looks like we never deploy really as it’s Codeship responsibility.