You can now deploy existing workspace projects to OpenShift 3 instances. You can either create a new OpenShift application, using an OpenShift 3 connection and then select the workspace project to deploy, or you can start by right-clicking on a project and use the Configure…​ > Deploy to OpenShift…​ menu.

The project needs to be shared with git and declared a remote git repository using the HTTP(S) protocol. That repository needs to be accessible from the target OpenShift instance. Once a project is selected, a selection of compatible templates will be displayed, matching the type of the project. The remote git URL is injected as a value for the SOURCE_REPOSITORY_URL (or legacy GIT_URI) template parameter.

A prototype for a new OpenShift 3 server adapter is now available. Its goal is to allow incremental deployment of workspace resources directly into the deployed node on OpenShift, bypassing the build step. Its capabilities are currently limited and require a number of manual steps to set up, but the usage will be streamlined in subsequent releases. Currently only Node and PHP based applications are supported.

To create a new OpenShift 3 server adapter, ensure that you have:

From the Servers view, create a new Server, select OpenShift 3 Server Adapter and click the Next button to reach:

Select the workspace project to deploy and this updates the Source path to synchronize from. For Node.js and PHP projects, that means the root of the project will be deployed. Other types of projects could use different source folders (for example, an exploded WAR folder for web projects, but this is currently not heavily tested/working). The Pod Deployment Path is the target location where the files will be copied on the OpenShift pod. The current value is set to work for Node.js and PHP applications, but that could potentially be some place else for other kind of projects. Finally, you need to select the target OpenShift service. You can click finish directly once you’re set.

Now, every time you want to push your local changes directly to OpenShift without having to commit and push them to git first, right-click on your new OpenShift 3 server, in the Servers view, and click Publish. The content of Source path will be automatically synchronized to the deployed pod. The initial deployment might take several seconds to perform, but subsequent deployments will be much faster. If the deployed application support resource updates (for examples, Node.js supports html updates, but needs to be restarted for JS ones, unless it’s started in debug mode), then you should be able to see your changes by simply refreshing your browser.

In future releases, this will become more streamlined. Server creation should be more automatic, changes will be automatically published (and faster) without having to manually hit the Publish menu every time, we should also be able to better support incremental deployment of JavaEE applications.

A new server adapter has been added to help start and stop the Red Hat Container Development Kit (CDK), a set of tools meant to quickly set up an OpenShift instance inside a Docker container running inside a virtual machine. While the server adapter itself has limited functionality, it is able to start and stop the CDK virtual machine via its Vagrantfile. Once started, Docker and OpenShift connections should appear in their respective views, allowing the user to quickly create a new Openshift application and begin developing their AwesomeApp in a highly-replicatable environment.

This plugin is still experimental, mainly due to the rapidly changing, fast-paced development going on in the underlying CDK. It’s also worth noting that several features will not work with the raw Red Hat CDK, and depend on the presence of a .cdk file in the same folder as your Vagrantfile. This .cdk file is included alnog with the Vagrantfile available at the openshift-vagrant github repository. Instruction to install and use this enhanced CDK Vagrantfile can be found at https://github.com/redhat-developer-tooling/openshift-vagrant.