[blowski]

You're right that if your team is filled with people that either don't know or don't care about quality, then no amount of automation is going to help. If corporate thinks an automated CI/CD managed by a separate operations team is going to bring quality, then, yeah that's always going to fail. But that doesn't mean all and any automated CI/CD pipeline is not going to help.

I've both worked with and implemented CI/CD pipelines, as in a Jenkins script that builds a number of build artefacts and then promotes them to run in a particular environment. As part of the build process, it runs automated tests and static analysis on things like type checking, code style.

What it doesn't do is tell us which tests we forgot to write so there's no 100% cast iron guarantee that everything is correct, and I think that's what you're referring to as "improved code quality". But by having that automated step, our human QAs can spend their time on manual exploratory testing (which humans are very good at) rather than manual regression testing (which is extremely slow and inefficient). And our devs can focus code reviews on questions like "is this code clear to me?" rather than "did you meet the in-house code style?" or "have you forgotten about potential nulls?". And we can bring in contractors (who might not care so much) or juniors with a fast onboarding time, since a lot of mistakes will get picked up automatically.

If you're working in a sufficiently large organisation, one where independent auditors look at development processes, then you must have a CI/CD pipeline - either a slow, manual one or a fast, automated one. I know which one I'd prefer.

[eru]

> What it doesn't do is tell us which tests we forgot to write [...]

There are actually techniques available that help with that.