I plan to spend an afternoon getting an ISV application to run on the public PaaS version of OpenShift—to allow direct comparison with a fruitless afternoon spent on the public PaaS version of Cloud Foundry. In this post, I explain the radical difference in approaches I am taking in the two environments to deal with real-world issues in the application lifecycle.

In this post I’m not going to document my actual experiences on OpenShift—that will come soon. Rather, I am going to explain my differences in approach and the thought processes behind those approaches. It’s actually very revealing.

This application has a build process that runs in Jenkins, then runs various tests, creates a WAR file, and deploys to a Tomcat instance on a nightly basis. It’s Groovy/Grails/Hibernate/MySQL with JavaScript at the front end. Source code is in a Subversion (SVN) instance that is tightly coupled with the build server. The build creates a WAR file via a packaging process that involves some external JavaScript libraries and some other bits and bobs. One key issue is that the WAR file needs traceability between the version that runs on the PaaS and the version that is deployed on-premises. In other words, whatever drops out of the Jenkins build process needs to run unmodified in either environment.

In both Cloud Foundry and OpenShift, I follow a “path of least resistance,” which means that I do not try to replicate the steps that I took on one platform if those steps don’t make sense on the other platform.  Rather, I try to work within the “grain” of the way the PaaS wants me to work, based on a deliberately naive reading of the available documentation and forum postings. No help from the vendor at this stage.

In Cloud Foundry, the approach I took was to try to push the WAR file from the existing build server up to Cloud Foundry at the end of the existing Jenkins job.

The first thing you notice when you start thinking about using OpenShift, in comparison with Cloud Foundry, is that there are some extra pieces to the platform that you are strongly encouraged to use. One of these is a GIT repository for your source code. This is an issue for ISVs. There isn’t really anything massively different from use of a hosted server to run SVN, but it does feel very different in that you are putting source code into a more multi-tenanted space.

The next thing that is different is that there is a Jenkins server available within the PaaS itself, so you get the same close coupling between source code and build server as is present within the current hosted build server setup, plus you get close coupling between the build server and the OpenShift deployment environment. So, in the spirit of “going with the grain,” I bit the bullet and made the decision to use both the OpenShift GIT and Jenkins, and was left with the following technical questions:

  1. How do I push to GIT from the various development environments?
  2. Do I want to replace my existing SVN environment with GIT, or can I get them to coexist?
  3. If they coexist, where is the version of record?
  4. Should I synchronize SVN and GIT, or just get rid of SVN?
  5. Can I transfer my existing Jenkins job to OpenShift and the various bits and bobs it needs to build the application?
  6. If the build runs on OpenShift, how do I get the WAR file off, and will it run on-premises?
  7. The build server doesn’t cost a lot of money to run, but once all of this is in place, why do I need a separate build server and source code management system for on-premises?

The final question is very interesting. When I started this thought process, I had no expectation that I would use OpenShift as the primary build server and source code repository for generating artifacts for on-premises deployment, but at the end of the day that starts to make sense. OpenShift becomes a hosted GIT/Jenkins environment that happens also to have a deployment platform attached to it.

Finally, a compelling reason to use the PaaS. Now, that is a bit weird. I’ll tell you if it works out.