jpdel

Also using Azure DevOps and it is indeed very well structured.

As for CI/CD differences: how many commits can actually affect code and infrastructure? I think this is part of the engineering problem at the end of the day.

I think this is a business trend unfortunately. Tools tackling the CI space wanted a piece of CD and then boom. Things became the same :)

Is this doing anything else than leveraging Docker multi layers caching?

We have a large Java monolith application. Builds ran for 30 minutes. Then we said let's only run the unit tests and critical smoke tests. The build time went down to 7 minutes ... on 12 CPU and 32 GB of RAM build slaves :) There's always a way.

What about splitting it in smaller parts? And apply the CI process to each module?

Agree. CI=3-7 minutes. CD can be 30-60 if needed.

Agree. Some faulty commits may go through. But then you strengthen your test suite to prevent similar issues to happen again, and so on.

> There's no need to as I mentioned that you're going to be hosting it somewhere during development anyway.

You will probably host 1 version which is infrastructure heavy and not very flexible. Take 10 developers working on the API. They all need to test their changes. Automatically if possible. Hosting external elements like the database and others is a pain eased by Docker.

nock will intercept http requests in the same node process it is used in. Here the test (and the mock) are in a different container and thus process. It won't catch them. Unless it is possible to actually spin up a server using nock and I've missed it? In which case I agree, custom code is not needed.

I didn't know about dotmess. I'll check it out. Thanks for the tip.

What tests are which kind depend on your use case. And is an infinite debate. I don't really care how you call them :)