4 ms·

This is the worst process I've probably ever seen. Only one person (or pair) can work on the code (in main) at a time for this to work. It's more effort than ju

This is the worst process I've probably ever seen. Only one person (or pair) can work on the code (in main) at a time for this to work. It's more effort than just making a branch and merging it to main, and it buys literally nothing. What is wrong with just creating feature branches and PRing them to main? It's literally the default workflow. Then when you merge to main you run the CI/CD just like this, but without having to go back and create a "snapshot branch" of main before you started. Also, as you scale you almost certainly have commits from multiple people in main by the time you do this breaking the whole "reverse PR" process.

wahnfrieden 4y ago
You're misreading it, you review in batch and in retrospect after it's been put into production (with associated incremental/canary rollout, feature flag etc safety controls) and trunk progresses freely
- x3n0ph3n3 4y ago
  Good luck passing a SOC 2 audit with that kind of workflow!
  - wahnfrieden 4y ago
    What happened to curiosity for finding secure ways to push workflows forward? People said the same things before continuous deployment caught on and now that's common enough and definitely SOC 2 capable. I believe it's doable with production rollout controls that limit customer exposure to the code changes and the code's access to data (possible these days with things like pg row level security controls, and blue/green routing etc. - already valuable practices), and ensuring the batch code reviews happen before customer rollout. Even with these controls and incremental rollout, there is tremendous benefit to getting the code deployed into production environments and enabling this review workflow. The point then is to satisfy remaining security controls while in production, under these type of controls.
  - jdlshore 4y ago
    Because the code is written in pairs, there’s two pairs of eyes on all code. I’m not familiar with SOC 2 specifically, but that’s sufficient for other security controls I’ve seen. The purpose of this review is to create consistency across their large number of services. It’s really just a convoluted way of using GitHub’s PR system rather than doing a diff and talking it over. Personally, I think it’s overly complicated, but I think the root cause of that complexity is having over 40 microservices owned by a single team, each in its own repo. It’s resulted in a lot of boilerplate, aka duplication, that they might be able to factor out if they used a monorepo. (Or a modular monolith.)

wahnfrieden 4y ago

You're misreading it, you review in batch and in retrospect after it's been put into production (with associated incremental/canary rollout, feature flag etc safety controls) and trunk progresses freely

x3n0ph3n3 4y ago
Good luck passing a SOC 2 audit with that kind of workflow!
- wahnfrieden 4y ago
  What happened to curiosity for finding secure ways to push workflows forward? People said the same things before continuous deployment caught on and now that's common enough and definitely SOC 2 capable. I believe it's doable with production rollout controls that limit customer exposure to the code changes and the code's access to data (possible these days with things like pg row level security controls, and blue/green routing etc. - already valuable practices), and ensuring the batch code reviews happen before customer rollout. Even with these controls and incremental rollout, there is tremendous benefit to getting the code deployed into production environments and enabling this review workflow. The point then is to satisfy remaining security controls while in production, under these type of controls.
- jdlshore 4y ago
  Because the code is written in pairs, there’s two pairs of eyes on all code. I’m not familiar with SOC 2 specifically, but that’s sufficient for other security controls I’ve seen. The purpose of this review is to create consistency across their large number of services. It’s really just a convoluted way of using GitHub’s PR system rather than doing a diff and talking it over. Personally, I think it’s overly complicated, but I think the root cause of that complexity is having over 40 microservices owned by a single team, each in its own repo. It’s resulted in a lot of boilerplate, aka duplication, that they might be able to factor out if they used a monorepo. (Or a modular monolith.)