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 :)

Agree. I would definitely put any infrastructure thing on the CD side though, as it is longer indeed.

You can test your software faster in CI using Docker compose. Something along these lines: https://fire.ci/blog/api-end-to-end-testing-with-docker/

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?

I've worked on C++ codebases where linking modules took over 10 minutes with a trivial change. Per config. Granted, that was with BFD, and I sped it up a good bit by switching to gold where we could... which meant our Windows MinGW builds still spent 10+ minutes per config, since those were stuck with BFD. But at least our Android and Linux builds were a bit faster!

But I like to touch common headers - say to document logging macros, and printf-format annotations to catch bugs, or maybe to optimize their codegen - and those logging macros are in our PCHes for good reason - so that still means rebuilding everything frequently. Which ties up a lot of build time (30-60 minutes per config per platform, and I typically have a lot of configs and a lot of platforms!)

Sometimes that can help, but don't forget that you still need to run integration tests on the whole thing.

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.

Hmm, seems like the workflow you've described is a bottleneck leading to this. Wouldn't you have some kind of test/staging environment that is accessible for this purpose?

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.