Unhinged Engineering

johnforstmeier.com

4 pointsforstmeier2 comments

Are you suggesting with 'Anti-conveyor belt' and 'Reverse QA bottleneck' that the only one testing the code is the person who wrote it? That seems off in my opinion.

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?

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.

Reply on news.ycombinator.com