Unhinged Engineering(johnforstmeier.com)
johnforstmeier.com
Unhinged Engineering
https://johnforstmeier.com/notes/unhinged-engineering/
2 comments
For manual testing, QA is a separate person/team but I'm recommending the developer observe in real time as they review since they're "shuttling" the change into production. QA should also basically be adding in automated tests for their manual evaluations so yes, I'd have them cycle through the development team.
On #6, yes, I'd say squash merge into single commits so single commits going out would be the enforcement measure. And deploys to production occur immediately on merge to `master` which would be blocked on tests passing with additional pushes to that branch triggering test reruns.
On #6, yes, I'd say squash merge into single commits so single commits going out would be the enforcement measure. And deploys to production occur immediately on merge to `master` which would be blocked on tests passing with additional pushes to that branch triggering test reruns.
Also, does your QA team cycle through the dev side to write tests?
With 6) does that mean squash merge? rebase? otherwise how do you enforce?
Also how do you ensure you deploy something that is tested, vs creating a new version of the code at the time of merge?