The Shippable Blog

4 Scenarios Your CI Strategy Should Support

Continuous Integration (CI) is a hot topic right now.  Companies have embraced the idea that automatically integrating software changes early and often is an effective approach to reduce cycle time, increase quality, and reduce end-to-end costs.

But what constitutes early and often?  (Hint: the earlier the better, and you should do it at multiple stages of your software delivery process.)

To identify where to introduce CI, it helps to understand how the need for CI changes as the complexity of your software delivery process grows. 

Configure a Continuous Deployment to Digital Ocean for a Node.js App

Looking to configure a continuous deployment to Digital Ocean for a Node.js app? Tired of manually trying to configure git hooks to work with you? Is SCP just a little too old fashioned and clunky. Great news! Your search is finally over as today we'll show you how to combine Shippable and Dokku to fit your deployment needs!

Dokku describes itself as a 'docker powered mini-heroku' and it lives up to the claim! With Dokku installed on your droplet, you can interact with it very similarly as to how you would a heroku app. By orchestrating Docker, Buildstep, and Gitreceive  together, Dokku forms a simple, not to mention well functioning, roll your own PaaS. More information on Dokku can be found here.

Specifying Deployment Targets for Different Git Branches

So, you already have Shippable setup for all your CI needs, and you're itching to take the plunge into CD? Maybe the thing that's been holding you back is you aren't sure how you can easily deploy to your dev, staging, and prod machines, without accidently pushing to production prematurely? The good news is Shippable can easily be setup to accommodate such a work flow! You can specify different deployment procedures based on your git branch.

Let's say you want to use want Shippable to perform a build for every commit, but you only want to do a deployment if it's a commit to the master branch. We keep track of what branch was pushed to via the BRANCH environment variable; This environment  variable can be used to implement branch specific logic. Here is an example shippable.yml snippet:

env:
global:
- APP_NAME_PROD=shroudd-headland-1758

after_success:
- if [ "$BRANCH" == "master" ]; then git push -f git@heroku.com:$APP_NAME_PROD.git master; fi

This will push your app to Heroku, but will only do so for successful builds from the master branch. For those unfamiliar with using Shippable for continuous deployment to Heroku, please refer to our documentation.

This basic idea can be extended in many ways! For example, you could send commits from master to prod, and all other commits to dev:

AWS Code Deploy and Shippable

Here at Shippable, we have a strong history of working well with AWS workflows. With the recent release of AWS Code deploy, we wanted to take some time to let you know how easily you can use Shippable and Code Deploy together in your continuous deployment workflow!

First off, there are some prerequisites before your Shippable minions can trigger Code Deploy. On your AWS account, you must have the following setup:

  • An S3 bucket or Github repo to hold your project
  • Your AWS account's access and secret keys
  • A Code Deploy Application, Deployment group, and underlying EC2 resources

If you have any question on the above requirements, AWS provides detailed instruction on obtaining keys and setting up Code Deploy.

Using Custom Ruby Environments in your Shippable Minions



One of the most powerful aspects of your Shippable Minions is the ability to fully customize each build environment, right down to a very specific ruby version.  All ruby environments come pre-configured to use the  Ruby Version Manager  (RVM) .