Release Management in the Cloud

openshift cloud deployment picture

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.

Run sudo gem install rhc, and rhc setup to configure your OpenShift "Red Hat Cloud" rhc command-line tools, and link your local development environment with your OpenShift Online account:

sudo gem install rhc
rhc setup

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.

Optional Step - Domain Aliasing:

If you have registered a domain name that you would like to use with your application, our F.A.Q. contains some excellent notes on configuring domain name aliasing on OpenShift.

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

2. Deployment to Staging

After reviewing and committing your changes locally, you can update your application staging environment with your latest work:

git push staging # or simply, git push

Then open a browser to this gear's APP_URL to test your latest code. OpenShift does a lot of work behind the scenes to update your live app whenever this simple git push operation occurs.

3. Deployment to Auto-Scaled Environments

If the changes look good in staging, you can make them available on your cloud-scaled application environment as well:

git push production # deploy to a gear w/ the Git remote label of "production"

It helps if you yell SHIP IT! while typing this command.

Emergency Rollbacks

Occasionally, an application bug may manage to sneak past your development and staging-area tests and make through to your production hosting environment.

If needed, you can quickly revert the status of a gear to a previous "known good"-version of your application code:

git log # to review your list of changes

The output should look something like this:

commit b021aaa7effee77a1ed501813c2fa8f65ba100de 
Author: ryanj <ryanj@redht.com>
Date:   Sun Feb 12 13:44:42 2013 -0800

    changing the application header text

commit 28c5555352a902c549c965da30cf7559c80f328e
Author: Template builder <builder@example.com>
Date:   Thu Feb 7 15:36:23 2013 -0500

    Creating template

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.

What's Next?

Invite your team to collaborate in your new release-management process, by following our notes on Team Collaboration and Secret-Free Source.

Happy Hacking!