Featured image for "Improving CI/CD in Red Hat OpenShift."

Red Hat recently conducted a Customer Empathy Workshop series that included two virtual workshops focused on continuous integration and 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.

During each 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.

Problems and pain points with CI/CD

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 the workshop. After everyone got the chance to share, we dove into the first step of design thinking: Empathize. 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.

Figure 1: Themes from design workshop.
  • Tekton limitations: "Passing data through a Tekton Pipeline is cumbersome and chatty. Tekton also lacks the capability for human confirmation in pipelines."
  • Argo CD: "We need better integration of Argo CD, 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 override default parameters of pipelines."
  • Delivering secrets: "There is no secret handling in Argo CD 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 Argo CD and synching of multiple clusters, along with configuration as code."

How might we improve CI/CD?

The next step in the design thinking process is to define the problem. In this step, we grouped our issues into different themes 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 to opportunities. Figure 2 shows the problem statements we created and groups some participant observations within each statement.

Figure 2: Pain points and projects that can address them.

The statements are as follows:

  • How might we make it easier to onboard and use Tekton Pipelines effectively?
  • How might we make it easier to learn how to leverage Argo CD 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 information about what Red Hat thinks is the right way to use the tools?

Ideas for improving CI/CD

The final step of the design thinking process in these workshops was to ideate new solutions to the problem statements we created. We used the "Yes, and" technique to facilitate brainstorming. The phrase "Yes, and" encourages active listening, positive thinking, and building on each other’s ideas. It 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, as summarized in Figure 3.

Figure 3: Suggestions resulting from ideating.

Let's look at our findings from each of the problem statements.

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

Participants generated the following ideas for making Tekton Pipelines onboarding easier:

  • Provide additional information 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.).
  • Create a pipeline template that generates pipelines based on each folder.

How might we make it easier to learn how to leverage Argo CD effectively?

Ideas for learning how to leverage Argo CD were:

  • Integrate better with external vaults (e.g., HashiCorp).
  • Document complex use cases.
  • Write guided docs to achieve use cases (after setup).
  • Implement secrets via Argo CD or Vault.

How might we share parts of pipelines more easily?

For sharing parts of pipelines, participants had the following suggestions:

  • Use a simpler syntax (e.g., GitHub actions).
  • Make sure that every time you have a new branch, the pipeline stays the same and certain tasks are skipped based on the branch.
  • Save users from having to think about the technical details of where the pipeline is running, and how many resources it is using.

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

Ideas for providing more flexible pipeline-metric customization were:

  • Allow custom metrics to be defined at certain author-defined thresholds that will fail the pipeline.
  • Make results of performance scans processable: if they are above a certain value they should block or break the pipeline.
  • Provide a yes-or-no button: Should I proceed with the next step?

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

Participants suggested the following:

  • Define a reference architecture.
  • Publish ideas from Red Hat about how to use the tools—we don’t want to search the internet.

Finally, we voted on the solutions participants most wanted to see implemented. This information will help the OpenShift team prioritize new features and enhancements for CI/CD tooling in the console.

What’s next

The User Experience Design team will continue to explore the customer ideas that came from these workshops. We will 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.

Are you interested in being a user research participant? Sign up today.

Comments