*When a project first starts, CI/CD pipelines are usually simple.
*
Build the application.
Run a few tests.
Deploy somewhere.
Done.
Then six months pass.
Another test gets added.
Then another deployment step.
A security scan.
Performance tests.
Notifications.
More environments.
Before long, a pipeline that once took five minutes now takes forty-five.
I’ve seen this happen more than once, and it’s rarely because Azure DevOps is the problem.
It’s usually because nobody ever stops to ask one simple question:
Does this step still belong here?
Everything Ends Up in the Same Pipeline
One of the most common mistakes I see is trying to make a single pipeline do everything.
Every Pull Request ends up running:
Every unit test
Every API test
Hundreds of UI tests
Security scans
Deployment steps
Report generation
The result?
Developers wait longer for feedback, releases become slower, and people eventually start ignoring failed pipelines because they happen too often.
Fast Feedback Wins
Not every test needs to run on every commit.
A better approach is to think about the purpose of each pipeline.
For a Pull Request, I want answers quickly.
That usually means:
Build the application
Run unit tests
Run a small smoke test suite
Stop if something important fails
Everything else can happen later.
Long-running regression tests, cross-browser testing and other expensive checks are often better suited to scheduled or nightly pipelines.
Pipelines Should Evolve
A pipeline isn’t something you build once and forget about.
Every few months it’s worth reviewing it.
Ask yourself:
Which step takes the longest?
Which tests fail most often?
Are there any tasks nobody remembers adding?
Are we getting useful feedback, or just more output?
Removing unnecessary work is just as valuable as adding new automation.
Final Thoughts
Azure DevOps is an incredibly powerful platform, but even the best tools become frustrating if they’re overloaded with unnecessary work.
The goal isn’t to build the biggest pipeline.
It’s to build one that gives your team confidence as quickly as possible.
I’m a Technical Test Manager with over 10 years in QA and test automation. I recently put together a practical handbook covering Azure DevOps, CI/CD, enterprise testing strategies and software delivery from a QA perspective. If you’d like to take a look, you can find it here:
답글 남기기