The CI/CD and DevOps Blog

Ever wish your build minions could boss around your other minions for you? Well, with the help of the new API, now they can! Today, I'm going to show you how you can have a successful build of one project, kick off a build of a different project. In honor of the new API, we are gonna do it all without leaving the terminal! Warning: You must have a startup or custom plan to use the API.

For illustrative purposes, I've created two repos that contain only shippable.yml files. I'm going to call one project "kicker" and the other project "kicke". The kicker project will kick the kicke project into building, after kicker finishes building successfully. Here is the code for the kicke project's shippable.yml file

install:
  - true
script: 
  - true

Basically, a build that will always run successfully under normal conditions.

Before you do ANYTHING with the api, you're gonna need to get your api token; don't worry though... It's easy! All you have to do is go to your account permissions page and generate a token. We will use this token in the header of our http requests.

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.

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:

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.