Deploy to IBM Cloud With TravisCI

Getting started with automated deployment in a few simple steps

Automated deployment is an expected part of the development lifecycle, but setting it up can be a headache. In this post, we’ll look at a super-simple application deployed to Cloud Foundry on IBM Cloud using the excellent TravisCI service. Today’s example is a public GitHub repository that you can clone and try yourself for free on, but the same process would apply equally to private repositories and a Travis subscription.

How Many Days Until Christmas?

I’m writing this post as the winter arrives, and it seems like there is Christmas music in every shop. So today I’ve built a “Christmas Countdown”: a simple PHP script that works out the difference between today’s date and December 25th, and outputs some information about what it found. (Note: pull requests are welcome. Especially ones that make it prettier.)

Like I said, it’s a simple application. We’re focused on the deployment pipeline in this article.

All the code used today is available on GitHub: Feel free to fork this repository and follow along. You just need a GitHub account and an IBM Cloud account to join in.

Get Ready for IBM Cloud

This application is designed to run on the IBM Cloud Foundry runtimes, using PHP. To configure it, I referred mostly to my previous post about deploying PHP to IBM Cloud and set up the following:

The Manifest

The manifest.yml can contain all kinds of settings for our app, but this one basically sets the name:

- name: christmas-countdown
random-route: true

It also sets the random-route parameter so that if you try this example, your deployment won't fail because someone else already tried it and deployed to that URL.

PHP Version

The Cloud Foundry platform will pick up which version of PHP and any extensions are needed from the composer.json file, along with the userland PHP requirements. In this case, there aren't any extra libraries but the file specifies which version of PHP to use:

"require": {
"php": "~7.1"

Since PHP 7.1 is current, stable, and available in the default buildpack, it’s a great choice for our app.

Webroot Location

The entrypoint for this project is public/index.php. The webroot is set in a buildpack configuration file called .bp-config/options.json.

"WEBDIR": "public"

This folder will be used as the default root for the web project, meaning that all the other non-web-facing files won’t be served.

Gathering Facts

In order to deploy to IBM Cloud, we’ll need some key pieces of information:

  • the region we want to deploy to
  • which organization the app should be under
  • which space to use
  • an access token so that the deployment system can log in (but not using our actual credentials)

The first three should be fairly straightforward. These details are available along the top of your dashboard in the web console for IBM Cloud. To generate an access token, go to “Manage” -> “Security” -> “Platform API Keys”.

Creating an API key is easy on the IBM Cloud.

You can create a new key here — copy the value and put it somewhere safe — we’ll need it in a moment.

Configure TravisCI

To get started with TravisCI, you will need to go to and log in with your GitHub account. It will present you with a list of your repositories (if you already had an account, press the sync button for it to pick up a new repository). Turn on the switch next to the repository you are interested in.

Flipping the switch for our christmas-countdown repo synced to our account on Travis CI.

In order to run our deployment successfully, Travis will need some environment variables, specifically log in details and deployment location. These are configured in the “Settings” tab of the repository.

Entering the environment variables into the settings for our repo on Travis.

The variables needed for this project are the ones we gathered earlier:

  • BXIAM – the access token
  • CF_API – the endpoint for our region, e.g. or, etc.
  • CF_ORGANIZATION – the organisation to deploy to
  • CF_SPACE – the space to deploy to

With this set up, the next step is to instruct TravisCI on what to do when we push code.

Creating .travis.yml

The .travis.yml file tells TravisCI what sort of a project we have, what build steps to run, and which versions of a particular runtime to use. It can also handle deployment of our projects, and that is the focus of this post. Here is the travis.yml file from the repo:

This is a very simple PHP project, so it’s configured using just our desired version of PHP. It’s common to give a list of language versions if your project is targeted at multiple versions. The sudo option is set since we need root access later in the deployment process. Also, the usual tests step is disabled here by adding an echo statement to the script section. For a more-than-one-line-of-PHP project, you'd usually put your PHPUnit command in the script section.

The interesting bit here is the deploy section, which is how the deployment actually happens. There are a few different deployment options, but by using script you can reference a shell script so that TravisCI can run the same commands you'd use locally to manually push the code in the cloud. This example also has the on: section, so that this deployment part is only run when the masterbranch changes. The other build steps will still run when we push to other branches or open/update pull requests.

Deployment Steps

The first part of the deployment is actually in the before_deploy: section above. The deployment uses the IBM Cloud CLI, so this section downloads that tool. It also gets the file permissions sorted out on the CLI tools and the script.

The script works through, checking that the environment variables have been set, and then does the actual deployment.

The actual deployment is the last five lines or so of the script. First the bluemix command is configured to avoid prompting us interactively to update to a new version. Next the API endpoint is set for our target region from the environment variable. After logging in and setting the organization and space, finally the bluemix cf push command is run and the application is deployed.

The TravisCI interface allows inspection of this process as it runs, with an expandable log for you to inspect.

Travis provides a wonderful log of our deployment activity.

Automated Deployment

Using automated deployment means getting all the right deployment steps run, automatically, every time. I’ve used TravisCI on many of my projects for running tests and doing other build steps. Being able to expand it to also handle the deployment, including holding the secrets required, is a very welcome addition to my project process.

Hopefully the steps outlined here will help you to spread the same magic to your own projects too. Add a comment to let us know how you get on!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store