Let the Bluemix build server run cf push

Source-control your work and deploy code more safely

Bluemix is IBM’s cloud computing platform, and it’s based on the excellent Cloud Foundry. To deploy apps, you describe the app configuration and dependencies in a manifest file. Then you run the cf push command, which pushes the files from your local machine to the cloud.

This approach is a great way to get started, but it’s not a process I’d recommend to a dev team. Pushing the contents of your local machine, rather than source control, is a recipe for at least a minor mishap, if not an actual disaster. However, help is at hand! Bluemix has a super-easy deployment pipeline tool that will run cf push for you, ensuring that you only deploy the things that are in your team’s source control repository and can therefore be traced, inspected, and all the other good stuff.

Set up a repo

On your app’s dashboard, click the app whose deployment you’d like to automate. If you’re not already using a Bluemix git repository with the project, then create one by clicking “Add a Git Repo”. If you usually store your git repositories elsewhere, such as on GitHub, BitBucket or GitLab, then don’t worry. The Bluemix repo can be added as an additional remote that you push to when you want to deploy. It’s common for teams to keep their production branch only on this repo and do active development elsewhere. Feel free to experiment to find a setup that works for you.

For this example, I’m using the Retro Guestbook app. You can find the source code for the guestbook on Github. This example has a few moving parts: in one repo I have a PHP web application, as well as two NodeJS worker scripts that have their own manifest files. This repo will show how you can configure deployment for even fairly complex applications quite easily. (If you’re interested, I blogged about how I deployed this app to Bluemix after developing it locally.)

If you create a new repo, it may start with an initial commit with a README.md file and a license file. For projects not already under source control, you can clone this repo, add your files, and keep working. For projects which already have git history elsewhere, I recommend that you add this new repo as a remote (mine is called “bluemix” so I’m clear about where I’m pushing to) on your existing local clone of the project. Then, you can force push to it. It’s not often I recommend a force push, but in this instance, it seems like a reasonable use case!

Configure the build

Once the code is in the repo, it’s time to tell the build server what to do when new code arrives. Your exact steps will vary but may include:

• static analysis of code
• tests to run
• actually shipping the code to the production platform

I’ll be focussing on the final point, as it’s common to all applications. To start, click the Build and Deploy buttons, and then choose to Add Stage. The input tab tells you when this job should run. When shipping code to production, you’ll normally be faced with these choices:

• run it manually
• run it when there’s a git push to a particular branch name
• run it when the previous stage has successfully completely

When you create the first stage, this third option isn’t available yet since there aren’t any previous stages. Set your stage to run when commits appear on whichever branch you use for production code (my examples are lazily set to master):

Next, visit the jobs tab. Here, you can create the various tasks to run for each stage. If you’re just automating the cf push command, then most of the work is done for you already: choose Add Job and pick the Deploy type of job. There are some options here, and you have full control over the script that this job actually runs. Take a look, but you probably don’t need to change anything at all, which is nice. You can come back and add or edit jobs, or the stage itself, at any time by clicking the cog config icon on the tile for this stage in pipeline view (pictured below).

Save the stage. From the main pipeline view, you can try running it (the play button next to the config icon in the top right of the stage tile). When you run these stages manually, they simply use the most recent commit in the git repo as the basis of what to deploy. As soon as the stage starts running, you can click a link to see the logs of the process as it happens. This way you can see the output you’d normally see if you were running it locally.

For my own application, I’m actually deploying three apps. So I simply repeat the steps above, changing the application name for each one, and create three stages. By setting up each stage to run in response to the git commit, rather than the previous stage completing, my stages will run in parallel with one another.

With the pipeline in place, my team and I can safely push code to a particular branch in a repo. We can be sure that the only code being deployed is code in our source control system. This centralized approach creates a more robust and reliable deployment process, and it’s super-simple to set up. You can extend and customise the pipelines to meet your application’s needs, even as it grows and evolves over time. Even here—where I simply showed you how to use cf push more safely—taking advantage of these tools is well worth the time you’ll need to set them up. Happy shipping!