this post was submitted on 27 Jul 2023
14 points (100.0% liked)
DevOps
1624 readers
1 users here now
DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.
Rules:
- Posts must be relevant to DevOps
- No NSFW content
- No hate speech, bigotry, etc
- Try to keep discussions on topic
- No spam of tools/companies/advertisements
- It’s OK to post your own stuff part of the time, but the primary use of the community should not be promotional content.
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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).