Pipeline Setup

UI & UX Design | User Research

SAP SE

Setting up a deployment pipeline took days, and most of that was reading.

The problem

To ship code at SAP, a team needed a CI/CD pipeline. Building one meant finding the right tools and wiring them together: source control, a secret store, an orchestrator, a build system, a deployment target. Finding the right tools and the right settings meant working through documentation, page after page. A developer read it, worked out what applied, and configured each piece by hand. It took days. Not every team had people who did this often, and the smaller ones had no one at all.

Who it was for

Everyone. Some teams had their own DevOps people. Some were three engineers with a product to ship. The bar was the same for both: the small team gets a clean, running pipeline without becoming an expert first, and the large team isn't slowed down to get there.

The decision: a guided path, not a blank file

The hard call was to make templates and best practices the default way through, instead of handing everyone a blank configuration.

Each template asked a few plain questions. Which build tool, which orchestrator, where it deploys. It filled in the rest from a setup that already worked.

The price was real. Edge cases got scaled back. A fully custom pipeline could do things the templates couldn't, and we chose not to support every one of those up front. Special cases drove the cost up fast, and most teams never needed them. A guided path served far more people than a flexible one nobody could navigate. That was the trade.

Compliance, built into the path

Compliance lived inside the standard path. Follow a template and you got the compliant setup by default: the right storage, the right authorizations, tied to a cost center and a named owner.

Teams could still go custom and skip all of it. We didn't block that. We tracked it instead. When enough teams hand-built the same thing, that pattern became the next template. The workaround fed the system instead of fighting it.