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
If you're comfortable using Git to manage your code and Jenkins for continuous integration, OpenShift will make you feel right at home.
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:
Dan Sullivan holds a Master of Science degree and is an author, systems architect and consultant with more than 20 years of IT experience. He has had engagements in advanced analytics, systems architecture, database design, enterprise security and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail and education. Dan has written extensively about topics that range from data warehousing, cloud computing and advanced analytics to security management, collaboration and text mining.