I guess this may be standard, but I’m running unit tests as part of my CI. Integration tests that can’t be mocked go in the CD pipeline. For automated UAT, I have a branch on the CD pipeline that runs on the agent after a deploy, but in order to make the agent more agnostic I am toying with the idea of running the tests on a VM or on the deployed location.
I am a major advocate of keeping CI as simple as possible, and letting build tools do the job they were built to do. Basic builds and unit/component testing. No need for overcomplicating things for the sake of “doing it all in one place”.
CD is where things get dirty, and it really depends on how/what/where you are deploying.
Generally speaking, if integration testing with external systems is necessary, I like to have contract testing with these systems done during CI, then integration/e2e in an environment that mimics production (bonus points if ephemeral).
I guess this may be standard, but I’m running unit tests as part of my CI. Integration tests that can’t be mocked go in the CD pipeline. For automated UAT, I have a branch on the CD pipeline that runs on the agent after a deploy, but in order to make the agent more agnostic I am toying with the idea of running the tests on a VM or on the deployed location.
I prefer a similar workflow.
I am a major advocate of keeping CI as simple as possible, and letting build tools do the job they were built to do. Basic builds and unit/component testing. No need for overcomplicating things for the sake of “doing it all in one place”.
CD is where things get dirty, and it really depends on how/what/where you are deploying.
Generally speaking, if integration testing with external systems is necessary, I like to have contract testing with these systems done during CI, then integration/e2e in an environment that mimics production (bonus points if ephemeral).