Deploying applications in the OpenShift 4.3 Developer perspective

In this article, we take a look at user flow improvements for deploying applications in Red Hat OpenShift 4.3's Developer perspective. You can learn more about all of the developer-focused console improvements in the OpenShift 4.3 release article here. Since the initial launch of the Developer perspective in the OpenShift 4.2 release, we’ve had frequent feedback sessions with developers, developer advocates, stakeholders, and other community members to better understand how the experience meets their needs. While, overall, the user interface has been well received, we continue to gather and use the feedback to enhance our flows.

The Add page

Added in OpenShift 4.2, the +Add option in the left navigation portion of the Developer perspective, as shown in Figure 1, is the entry point for developers to add an application or service to their OpenShift project.

Figure 1: Add an application or service to your OpenShift project using these six user flows.">

As you can see, the Add page offers six user flows:

• Adding components from Git.
• Deploying container images.
• Adding an item from the developer catalog.
• Importing your Dockerfile from a Git repo.
• Importing YAML.
• Adding a Database.

OpenShift 4.3 user flow improvements

The release of OpenShift 4.3 brings improvements to the Import from git and Deploy Image flows. Let's take a look at each.

Builder image detection for Import from git

The Import from git flow has been enhanced to help users easily create applications by auto-filling in the details, making the process more automated. This improvement comes from introducing auto-detection for the builder image, which provides assistance in determining the right build strategy.

In 4.3, as soon as the user enters a Git Repo URL, URL validation takes place. Once the URL is validated, the builder image detection process starts. The recommended builder image is indicated with a star and is selected by default, as shown in Figure 2.

Figure 2: Importing from Git triggers builder image detection.">

By suggesting a builder image, we try to reduce the number of steps it takes users to build their application. However, the user is free to select a different builder image manually. To further increase the flow's efficiency, the Application and Name fields are populated with smart defaults based on the Git Repo URL entered. These fields can also be edited if they are not what the user wants. Providing the user with optional suggestions in these form fields helps the user proceed faster without mandating what they enter.

Deploy an image from an image stream

The Deploy Image flow now offers the ability to deploy an image using an image name from an internal registry, as shown in Figure 3. This option was present in the 3.11 release of OpenShift and is being reintroduced in 4.3 with enhancements.

Figure 3: Deploy an image using an image name from an internal registry.">

When choosing this option, the user identifies the container image to be deployed by selecting the associated project, image streams, and tag in the Image section of the form, as shown in Figure 4.

Figure 4: An example internal registry deployment.">

To improve this flow from 3.11, upon project selection, we verify that there is proper access to pull images from this project. When there isn’t proper access, the user can choose to grant that access via a checkbox, which is selected by default.

The new Resources section

In the 4.2 initial release of the Developer perspective, the Import from Git, Import from Dockerfile, and Deploy Image user flows created deployment configs by default. When the Serverless Operator was installed, a Serverless section was displayed allowing the user to select a checkbox indicating that they wanted a Knative service to be created.

In 4.3, we added a Resources section to these flows that allows the user to select what type of resource to create, as shown in Figure 5. The default is a Kubernetes Deployment. Other resource types available for selection are Deployment Config and Knative Service. The Knative Service option is only available when the OpenShift Serverless Operator is installed. Because these forms are dynamic and change based on user selections, the Advanced Options available will differ depending on the resource that is selected.

Figure 5: Choose the type of resource to create in the new Resources section.">

Learn more

Interested in learning more about application development with OpenShift? Check out the Red Hat resources for application development on OpenShift.

Provide feedback

Want to give us feedback? Join our OpenShift Developer Experience Google Group, participate in discussions, or attend our Office Hours Feedback session. Or, drop us an email with your comments about the OpenShift console user experience.

Last updated: June 29, 2020