Customer suggestions for improved CI/CD in Red Hat OpenShift

Red Hat recently conducted a Customer Empathy Workshop series that included two virtual workshops focused on continuous integration/continuous delivery (CI/CD) tooling within Red Hat OpenShift. The Red Hat User Experience Design team partnered with Product Management and Engineering to engage 22 OpenShift customers from seven different companies. This article reports the participants' top requests and how Red Hat could address them.

During each two-hour workshop, we used digital whiteboards and video conferencing to virtually engage customers in hands-on activities. We used the first three steps of the classic design thinking—empathize, define, and ideate—to identify and understand problems as well as suggest solutions. Let’s take a look at what we learned.

Current needs for CI/CD (Design thinking, step 1:  empathize)

We began the workshops by asking participants to introduce themselves in order to help break the ice and get to know each other. Each customer shared their role and responsibilities, the CI/CD tools they use, and what they were looking forward to in this workshop. After everyone got the chance to share, we dove into design thinking. Although we couldn’t use sticky notes and Sharpies as we do in person, participants were able to use digital whiteboarding to write down their problems and pain points when they use CI/CD tooling within OpenShift. We reviewed the participants’ pain points to find similarities and identify common themes.

Figure 1 lists some of those themes, followed by a list that includes paraphrased responses from customers.

• Tekton limitations: "Passing data through a Tekton Pipeline is cumbersome and chatty. Tekton also lacks the capability for human confirmation in pipelines."
• ArgoCD: "We need better integration of ArgoCD, Helm, and Tekton."
• Multitenancy: "Multitenancy and Kubernetes RBAC should be enforced in tools."
• Pipeline as code: "Our developers would like simple pipeline definitions, such as GitHub Actions or Travis. It is difficult to share pipelines or parts of the pipeline."
• Metrics and gates: "We are unable to track test results across consecutive runs. OpenShift lacks the ability to set up gates for the pipeline."
• Best practices: "What is Red Hat's ideal CI/CD architecture? How could we get feedback from OpenShift in our CI/CD tooling?"
• Triggers: "Tekton EventListeners are not protected with authentication or OAuth. EventListeners also can't optionally override default parameters of pipelines."
• Delivering secrets: "There is no secret handling in ArgoCD or OpenShift GitOps and integrating with an external vault is not easy. Secrets do not work well in resource-constrained clusters."
• Multicluster management: "We need Git repo management for ArgoCD and synching of multiple clusters, along with configuration as code (CaC)."

Finding opportunities for improving CI/CD (Design thinking, step 2: define)

The next step in the design thinking process is to define the problem. In this step, we looked at the different themes into which we had grouped our issues and selected a few to focus on for the remainder of the workshop. We used these key themes to define problem statements in the format of "How might we" statements. Reframing the problem into a "How might we" statement helped to shift our perspective from challenges into opportunities. Figure 2 shows the problem statements we created, and groups some of the participant observations within each statement:

• How might we make it easier to onboard and use Tekton Pipelines effectively?
• How might we make it easier to learn how to leverage ArgoCD effectively?
• How might we share parts of pipelines more easily?
• How might we offer a flexible way to customize pipeline metrics and react to them?
• How might we get more info about what Red Hat thinks is the right way to use the tools?

Proposed projects (Design thinking, step 3: ideate)

The final step of the design thinking process that we covered in these workshops was to ideate new solutions to the problem statements we created. We used the "Yes, and" technique to facilitate brainstorming, which encouraged active listening, positive thinking, and building on each other’s ideas. The phrase "Yes, and" reminds people not to criticize other people's ideas, but to use the ideas as inspiration for more suggestions.

This process generated many possible solutions to the problems we were exploring. Finally, we voted on the solutions participants most wanted to see implemented, which will help the OpenShift team prioritize new features and enhancements for CI/CD tooling in the console.

Problem statement: How might we make it easier to onboard and use Tekton Pipelines effectively?

• Provide additional info from elsewhere (secrets, registry, etc) during the pipeline creation process
• Provide an out-of-the-box way of protecting Triggers and EventListeners
• Provide additional metrics on a per-pipeline level (success ratio, run duration, etc.)
• A pipeline template that generates pipelines based on each folder

Problem statement: How might we make it easier to learn how to leverage ArgoCD effectively?

• Better integration with external vaults (eg., HashiCorp)
• Document complex use cases
• Guided docs to achieve use cases (after setup)
• Secrets via ArgoCD or Vault

Problem statement: How might we share parts of pipelines more easily?

• Simpler syntax (e.g., GitHub actions) 
• Every time you have a new branch, the pipeline stays the same and certain tasks are skipped based on the branch
• Not have to think about the technical details of where the pipeline is running, and how many resources it is using

Problem statement: How might we offer a flexible way to customize pipeline metrics and react to them?

• Allow custom metrics to be defined at certain author-defined thresholds that will fail the pipeline
• Results of performance scans should be processable: if they are above a certain value  they should block or break the pipeline
• Should I proceed with the next step?—Yes or no button (manual approval)

Problem statement: How might we get more information about what Red Hat thinks is the right way to do things and use the tools?

• Reference architecture
• Get ideas from Red Hat about how to use the tools—don’t want to search the internet

The highest-voted solutions to each problem statement appear in Figure 3.

What’s next

The User Experience Design team will continue to explore the customer ideas from the workshop and complete the design thinking process by prototyping designs and testing them with users. The information that we gathered from these two workshops helped us to identify five main focus areas that will inform decisions and enhancements to the OpenShift CI/CD tooling.

Community feedback helps us continually improve the OpenShift Developer Experience. We want to hear from you, too. Attend one of our office hours on the OpenShift Twitch channel, or join the OpenShift Developer Experience Google Group to share your Web Console tips, get help with what doesn’t work so well for you, and shape the future of the OpenShift Developer Experience.

Ready to get started? Try OpenShift today.

Interested in being a user research participant? Sign up today.