Elevating Your Development Pipeline to the Cloud with OpenShift - Archived

Picturing Deployment Environments on OpenShift

Moving your application development pipeline to the cloud might require some tweaks to your deployment process but you can still have environments such as development, test, and of course, production.

In this blog post, I will discuss ways you can manage your deployment environments on the open-source OpenShift Platform as a Service.

Every team’s process is different, so the methods described may not be an exact fit for you, but this post should give you a fair idea of some options.

Introducing the A-Team

To assist with the discussion, it is helpful to have an example scenario in mind.

Let’s imagine a development team at Open Sorcerer Co. working on the Awesomesauce web app. The team has a Jenkins server for continuous integration.

The Open Sorcerer crew’s environments are called Dev, Test, Stage and Production, and new code progresses through them in that order.

They are currently deploying their application to servers provided by an Infrastructure as a Service vendor.

Defining Environments

When a team decides to move to OpenShift, one of the first considerations to tackle is how the existing deployment environments should appear in the new set-up.

The easiest way to map environments on to the platform is to create an OpenShift domain for each one.

Application access can be managed via these domains, sometimes also referred to as namespaces. An application’s domain is part of its URL; on OpenShift Online, these have the form {appname}-{domain}.rhcloud.com.

Users on OpenShift Online’s free tier can only create a single domain; you must have a higher level of access to create multiple domains.

New application domains can be created in the OpenShift Web Console or on the command line with RHC, as shown below. The following example demonstrates how to list your domains and create a new one.

$ rhc domain list
Domain opensorcerer (owned by techlead@opensorcererco.com)
Created:            Feb 1, 2014 10:00 AM
ID:                 25646f305873ca65bb0c025f
Allowed Gear Sizes: small, medium, large

You have access to 1 domain.

$ rhc domain create dev1opensorcerer
Creating domain 'dev1opensorcerer' ... done
You may now create an application using the 'rhc create-app' command

The Open Sorcerer team would create further domains this way until they had one for each of their Dev, Test, Stage and Production environments. Their production domain may well have a custom URL.

Sharing Domains

Once the domains for each environment have been established, each team member needs to be granted the appropriate level of domain access.

Each person on the team should have an OpenShift account. While it is possible to grant access to the source of an OpenShift application using SSH keys, the platform’s domain management features offer more control and are the preferred approach.

Domains can have many members, and each member can have one of three roles: view, edit or admin. These roles are described in the user guide. The roles dictate the access the member has to applications within the domain, and to management of the domain.

Domains can be managed via the Web Console or the command line. Here is an example of adding a member to a domain with the view role.

$ rhc member add projectmanager@opensorcererco.com -n dev1opensorcerer --role view
Adding 1 viewer to domain ... done

Controlling Deployments

Domain membership management, as described above, can be used to control which team members can push code to certain environments.

For example, Open Sorcerer Co. may only grant their operations people access to the Stage and Prod domains, so only those team members can push code live for those environments.

Another control measure that can be taken is to disable automatic deployments.

By default, when new code is pushed to an OpenShift Git repository, this triggers a build and the new code is deployed. That is probably not the desired behavior for a production application. This feature can be disabled with the command shown below, which applies to the application awesomesauce in the domain opensorcerer.

$ rhc app-configure --no-auto-deploy -n opensorcerer --app awesomesauce

Once automatic deployments have been disabled, code can be deployed manually with the rhc app deploy command, which can reference a Git commit, tag or branch.

$ rhc app deploy b932ea3 -n opensorcerer --app awesomesauce
Deployment of git ref 'b932ea3' in progress for application awesomesauce ...

It is also possible to do binary deployments, as described here.

Continuous Integration

Another element of the new set-up the team is going to need to consider is continuous integration.

OpenShift can integrate with CI solutions such as Jenkins and Travis CI.

There is an OpenShift cartridge for creating a standalone Jenkins server on OpenShift, and an embedded cartridge that can be added to OpenShift applications. Doing so will prompt OpenShift to build applications on the Jenkins server and only deploy them when a build has completed successfully.

The Open Sorcerer team could create a Jenkins server on OpenShift with the following command.

$ rhc app create jenkins jenkins-1 -n dev1opensorcerer

To then add the embedded Jenkins cartridge to the awesomesauce app in the Dev domain, they would use the following command.

$ rhc cartridge add jenkins-client-1 -n dev1opensorcerer --app awesomesauce

Now, any code pushed to the Dev environment will automatically build on Jenkins.

Possible Workflow

The Open Sorcerer team members now have all the pieces of the puzzle in place, but you may still be wondering about their new workflow. The team uses Git remotes to push code between environments. Here is how it might look.

  • The developers are all members of the Dev domain (dev1opensorcerer) and have edit rights. There is one main version of the awesomesauce app hosted in this domain, however, the developers each also have their own versions under different names that they can use to try changes before they integrate them into the main version. When a developer is happy with a change, they use a Git remote to push the new commits to the main awesomesauce app, which triggers a Jenkins build. Once a day, the Dev code for the application is pushed to the Git remote for the Test domain.

  • When code is pushed to the Test domain, it triggers a different Jenkins job that runs the complete automated functional test suite. The testers are all members of this domain and use it to run further tests. They may host their own applications, consisting of automated tests, in this domain. When the testers are happy with new code, they use a Git remote to push it to the Stage environment.

  • Only the operations team members have access to the Stage and Production environments. The version of the application in Stage is used for demonstrations for the product owners and customers. Once it is time for a release, the ops person creates the Git tag for the release and pushes the code to the Git remote for Production.

  • The new release has reached Production, but it has not yet been deployed. Only certain operations personnel have access to the Production domain. At the agreed time, an ops person manually deploys the new release to Production.

The above workflow is just one example; there are many possible variations.


In this blog post, I discussed how deployments and environments can be managed on OpenShift. An example scenario was given, but there are many other configurations in which the techniques covered could be used.

It is advisable to create an OpenShift domain for each deployment environment. Automatic deployments should generally be disabled for production environments and access to the production or other sensitive domains should be restricted. Continuous integration can be added to the pipeline where appropriate. Git remotes can be used to push code between environments/domains.

Next Steps

Jenkins, OpenShift Container Platform, OpenShift Online
, , , , , , , , , , ,
Comments are closed.