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
rubygems command-line tools available in your local development environment in order to proceed.
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
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
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
-sflag to the
rhc app createcommand to take advantage of OpenShift’s auto-scaling capabilities.
- Use the
--no-gitflag 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
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.
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 <email@example.com> Date: Sun Feb 12 13:44:42 2013 -0800 changing the application header text commit 28c5555352a902c549c965da30cf7559c80f328e Author: Template builder <firstname.lastname@example.org> 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 (
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.
Invite your team to collaborate in your new release-management process, by following our notes on Team Collaboration and Secret-Free Source.
- Sign up for OpenShift Online
- Interested in a private Platform As a Service (PaaS)? Register for
an evaluation of OpenShift Enterprise
- Need Help? Post your questions in the forums
- Follow us on Twitter