Get comfortable designing cloud apps in Red Hat OpenShift

OpenShift will make cloud developers using Git and Jenkins feel right at home. But for others, there are a few things to know.

Red Hat OpenShift is a PaaS that combines the benefits of popular source code management and automated build and...

test tools. And while this design works for some cloud developers, it's not for everyone.

If you're comfortable using Git to manage your code and Jenkins for continuous integration, OpenShift will make you feel right at home. If you've been working with other source code repositories and are considering a switch to Red Hat OpenShift, there are a few things to know about a Platform as a Service (PaaS) designed to streamline application development.

Understanding the basics of Red Hat OpenShift


OpenShift is based on Red Hat Enterprise Linux running on bare-metal machines, virtualized servers or a cloud. Applications run in nodes in the Platform as a Service, which are managed by brokers that also run within the same PaaS. Nodes can run multiple environments using gears -- Red Hat's term for Linux containers. Containers isolate processes and function with control groups to allocate compute resources, providing services similar to those of virtual machines (VMs) but with less overhead.

Developers can build their code in an integrated dev environment, such as Eclipse, and then deploy it to run in a gear. As part of this process, you need to choose the programming language you will use, along with other components, such as databases and Web servers. A local Git repository manages application code; when it's time to deploy, you simply push (a Git command) the code to the appropriate environment (e.g., test, development or production).

Automated testing in OpenShift with Jenkins

Unit-testing your code locally is important; however, run integrated tests that exercise many execution paths through code for any nontrivial software development effort. This process can be time-consuming and tedious -- and subject to errors if you depend on too many manual steps. Automated testing is built into Red Hat OpenShift for Jenkins to help.

When you use Jenkins in your Red Hat OpenShift development, you commit code to the Git repository as usual. When Jenkins detects new code in the repository, it builds the application and runs a set of customized tests. If the tests are successful, the code is deployed. Otherwise, the code that is already deployed continues to run. This can help you prevent inadvertently deploying code with errors that might not be discovered until a user runs into a problem with your application.

Applying best practices to Git, Jenkins

Because Git and Jenkins are so tightly integrated into Red Hat OpenShift, best practices for using them apply to managing your code within this service.

A commit tip:

Include a brief comment about why you're making a commit. This bit of metadata can be helpful when tracking down the source of broken code.

Git best practices start with a commit, which saves the state of your code but does not deploy it. A commit is a way to create a checkpoint you can fall back on if you break your code. With multiple commits, you have a better chance of having a small set of changes between the last working version and the first broken version of your code.

Consider how you will manage branches of code in the Git repository. One popular model is to have a master branch that includes all code released to production and alternate branches, such as development and testing. In some projects, it helps to have topic branches: short-lived branches containing code for a single feature. When the code is stable, it can be merged into other branches.

Establish procedures for pushing code to production. These should include naming conventions for tagging branches and rules for not updating a branch once it has been released.

When you use Jenkins, it is recommended that you build applications completely from source code. To completely build from source, other libraries and support code have to be under source control as well.

Jenkins jobs should be configured to build and test code. Testing integrated code can find bugs that may not be apparent during unit testing. Use separate jobs to build and test different branches, allowing you to customize tests and actions to the specific needs of each type of branch.

About the author:

This was first published in April 2014

Dig Deeper






Forgot Password?


Your password has been sent to: