Release Management in the Cloud

Building a pipeline to Deploy Town

OpenShift allows developers to stand up their own release-management pipeline, including: local development, a single-gear staging environment, and a production-quality, cloud-scaling clustered environment – all in two simple steps!

Disclaimers and prep-work:

If this is your first OpenShift app – Congratulations, and welcome to the club!

You’ll need to sign up for a free OpenShift Online account, and make sure that you have a recent version of the git, and rubygems command-line tools available in your local development environment in order to proceed.

Step1: Local Development and Staging

Start by provisioning a new cloud-hosted application. First, you’ll need to choose an APP_NAME and CARTRIDGE_TYPE to supply the initial starter-code for your app. Type rhc cartridge list to see a complete list of cartridge types and/or available application-hosting languages.

When ready, start up a new gear using the rhc command-line tools.

This command will output a local Git repo, so make sure to run it from within a folder where you would like to store your development source:

rhc app create APP_NAME CARTRIDGE_TYPE

For example, you can create a new application named onegear using node.js, by typing:

rhc app create onegear nodejs-0.6

This single-gear application hosting environment will be configured with a remote git source code repository (or repo) and several other services. It will also create a local clone of your application source, stored in a folder matching your chosen APP_NAME.

The rhc app create command output should also include a live web URL where your application code has been staged.

For local development and testing work, enter your local application folder (cd APP_NAME) and make a few changes to your code. If you followed the above example and created a new node.js application, running npm start will allow you to test your changes locally.

Step 2: Clustered, Auto-Scaling Environments

Now that we have established our application’s development and staging environments, let’s add a multi-gear auto-scaling stage to the mix!

This time, when provisioning your gear:

Add a -s flag to the rhc app create command to take advantage of OpenShift’s auto-scaling capabilities.

Use the --no-git flag to avoid creating an extra copy of the default application source, since we already have locally-available application code from Step 1.

rhc app create --no-git -s multigear nodejs-0.6

The above command should return a new remote Git URL that your local project will need to be made aware of.

Run the following command from within your application source folder, inserting your own NEW_GIT_URL address. In these examples, I’ve chosen to name the Git remote for our clustered app, production:

git remote add production -m master NEW_GIT_URL

To see a list of each of your remote Git repositories, enter:

git remote -v

Now that you have a secondary Git remote configured, you’ll need to force push your project’s commit history over to your multi-gear application instance. This will establish a consistent commit history across each of your environments, and deploy the latest version of your code to your production cluster:

git push -f production master

You can optionally rename your staging environment’s Git remote label to help clarify the purpose of that machine. By default, OpenShift sets your primary application’s remote Git URL name to origin.

git remote rename origin staging

I’ll be using the name staging when pushing to my app’s single-gear environment in the remaining examples.

Release Management Workflows

Now that you have successfully established each of your application hosting environments, the following deployment workflows should be possible:

1. Local Development

With node.js, you can enter your local project (cd APP_NAME), and start up a development server with npm start.

Make a few changes and reload your local server to test your edits locally. When you’re happy with your changes, check them into your local repo before promoting them on to the next application-hosting stage.

git diff # to review your changes
git add # each file name that is ready to be deployed
git commit # to record a batch of changes locally

For example, if I knew that the previous release of my code was bug-free – the following command should allow me to reset my staging server to the most recently-listed commit hash (28c5555352a902c549c965da30cf7559c80f328e):

git push staging 28c5555352a902c549c965da30cf7559c80f328e:master

Resetting your production environment to the same commit revision only requires a small change:

git push production 28c5555352a902c549c965da30cf7559c80f328e:master

Once the bug has been identified and patched in your local development environment, you can repeat the previous deployment steps (without a commit hash) to update your application with your latest project source.