Start with Classic: Why UI-Based Pipelines Are the Smart First Step

In government IT, the goal is not just delivery, but understanding. Transformation efforts—especially around DevOps—tend to stall when teams feel left behind. That’s why when it comes to Azure DevOps pipelines, I always recommend starting with classic, UI-based pipelines instead of jumping straight into YAML.

This might seem controversial in tech circles where “YAML everything” is the trend. But the reality is that DevOps isn’t about chasing trends. It’s about enabling teams to ship with confidence, understand what’s happening under the hood, and adapt to change. And for that, the classic pipeline designer is a far better teacher.

Visual Learning Is Real Learning

When you’re introducing pipelines to developers or sysadmins new to build automation, a visual tool helps demystify the process:

• They can see the stages.
• They can drag and drop tasks.
• They can hover and explore parameters.

It’s not just about convenience—it’s about how humans learn. Visual learners can connect the dots between “what happens” and “why it happens” without being overwhelmed by indentation, syntax errors, or the intimidating structure of a YAML document.

Once the concepts sink in—triggers, agents, artifacts, variables—exporting the pipeline to YAML becomes a natural next step. In fact, Azure DevOps has a built-in feature to do just that. So you’re not throwing away your progress; you’re building on it.

Why Everyone Should Learn Pipelines

Here’s the often-ignored truth: the build pipeline is part of the application architecture.

It knows:

• How the code is structured
• What dependencies need restoring
• How secrets are managed (Key Vault, variable groups, etc.)
• How front-end and back-end components are stitched together
• Which version of .NET, Node.js, or Java you're targeting
• What tests need to run—and when

Any change in those areas—adding a project, upgrading a framework, restructuring folders—often requires pipeline updates.

That’s why the build should be owned by the team who owns the application. Outsourcing it to a separate "DevOps" team introduces friction, slows down iterations, and creates knowledge silos.

This is where YAML shines: version-controlled, peer-reviewed, and part of the repo.

But YAML comes with a learning curve—and that’s exactly why classic pipelines are the bridge.

Classic First, YAML Next

You don’t need to choose between classic and YAML. You can use both strategically:

1. Start with classic to onboard teams.
2. Teach concepts through the UI.
3. Export to YAML once teams are ready.
4. Commit YAML to the repo and evolve from there.

It’s a win-win: better learning, smoother transition, and ultimately, more autonomy for development teams.

Final Thoughts

DevOps is not about enforcing tools; it’s about building understanding. In government organizations—where talent often spans a wide range of backgrounds and experiences—meeting people where they are is not optional. It’s the only way transformation sticks.

So yes, YAML is the future. But don’t start there. Start with classic pipelines—because understanding is what powers real DevOps.