Red Hat's Peter Larsen, the OpenShift Domain Architect, gave a talk at DevNation, "Developing on OpenShift without the build waits". Developing with the OpenShift Platform-as-a-Service can be very compelling: developing and deploying software without having to worry about the infrastructure. When you first try OpenShift, it's quite impressive to see how easy it is to develop and deploy software using the built-in templates that include preconfigured components such as databases and application servers. This allows developers to start coding right away.
The one thing that mars the great first impression of OpenShift is how long the first build takes. Fortunately, subsequent builds are faster than the initial build but can still take longer than you'd like for edit, build, and test cycles during active development. Peter presented three ways that developers can dramatically shorten those cycles.
First, Peter walked through "the why", covering how OpenShift works in order to understand what the contributing factors are. It's important to remember that OpenShift 3 is container based, it uses docker and kubernetes under the hood. When you build on OpenShift, the base docker images for your template that contain the software components, for example the app server, need to be pulled to the node that your build is running on. Your build could be scheduled on any available node. Every image can't be present on every node. The build creates new container images. Those container images need to be pushed back to OpenShift container registry. This needs to be done so that your application's containers are available to run on any of the available OpenShift nodes.
It's also worth remembering that containers, by design, are immutable. Any changes need to be written to a new layer, which in order to be persistent, generates a new container image that needs to be pushed back to the container image registry. If you need to change one line of code, the container image holding your code needs to be rebuilt. The immutability of containers can be a challenge when developing, but it is the foundation of what makes containers so attractive for deployment: namely isolation and making things reliably reproducible.
The three strategies Peter presented:
$ oc rsync
This OpenShift command lets you copy (rsync) files into a running container. This can be extremely handy for debugging and other quick testing. The drawback of this approach is that any changes you make are NOT persistent. When that container restarts it will be back in its original pristine state from the build. This also means you can't use ocrsync if your changes require restarting a component such as the application server.
Incremental builds
There is a new feature in OpenShift 3.2, incremental builds, which can dramatically speed up your cycles by not rebuilding everything all of the time. The feature is new enough that it isn't an option in the web console yet. You need to edit a config file to enable it. It will be in the web console in the next release. Peter did a live demo, the first build took 2 minutes and 14 seconds. Then he changed a line of code after enabling incremental builds. The new build was ready in just 13 seconds. An audience member asked Peter to turn incremental builds off again so we could see the difference between the first build and subsequent builds. The result without incremental was 43 seconds. So, the speed up from incremental builds in this case was 3.3X faster.
Peter pointed out that you'd only want to use incremental builds on your development system. Incremental builds will not be the default, because it's possible a dependency could be changed without being detected. For the sake of keeping things 100% reproducible, your build system should build from scratch every time.
Direct build instructions from the command line or API
The final strategy Peter presented is using OpenShift command line arguments or the API to take more control over how your builds are done. The options are:
- --from-build
- --from-dir
- --from-file
These will let you short circuit some of the build steps when you know how your application is being built, know what you are changing, and can specify the starting point to save steps.
Eclipse tooling for OpenShift: JBoss Developer Suite
The final point of Peter's talk and a key take away was that for the best experience, developers should be using the latest Eclipse-based tooling: Red Hat JBoss Developer Suite. The Developer Suite allows you to develop in Eclipse, and deploy on OpenShift Enterprise 3, all running on your desktop. The developer suite installs Red Hat Container Development Kit, which gives you a complete OSE 3 environment in a VM that you can control directly from Eclipse.
You can download Red Hat JBoss Developer Suite from developers.redhat.com today.