3 ms·

I’m not entirely sure if I got this right, but this system sounds a bit … weird. Everything is “tested” in production and then, at some arbitrary time, another

by max-m 4y ago

I’m not entirely sure if I got this right, but this system sounds a bit … weird. Everything is “tested” in production and then, at some arbitrary time, another team does a code review of the code that’s already in production and possibly broken? It just seems completely backwards.

wahnfrieden 4y ago
Sounds like real innovation toward actual continuous integration and continuous deployment! Indisputably better for the typical DORA DevOps metrics, the trick being relying on other quality controls and not treating code review as a quality control for regressions outside of feature flags. We operated this way back in the day building Canv.as and DrawQuest but without the snapshotting, that's a nice development Wish more teams would explore this type of development. Everyone is stuck in the git kernel dev model practices. It probably sounds weird because it's unusual, not because it's a DevOps bad practice (it's quite on the leading edge).
- deleted 4y ago
  [deleted]
- x3n0ph3n3 4y ago
  It also won't pass a SOC 2 audit if people can just commit anything and ship it to production with no oversight.
  - wahnfrieden 4y ago
    https://news.ycombinator.com/item?id=32697298 https://news.ycombinator.com/item?id=32697298
jdlshore 4y ago
It sounds like they’re using XP, or something similar. In XP, the code is reviewed and tested as it’s written, using pairing or mobbing for the review and TDD for the testing. (XP also uses frequent pair switching and collective ownership to get more eyes on the code, but it’s not clear to me whether they are or not.) So when the code is deployed, it’s already been reviewed and tested. The review they’re talking about here comes later, as a way of keeping the team in sync. It’s not the main code review mechanism.

3 ms·

I’m not entirely sure if I got this right, but this system sounds a bit … weird. Everything is “tested” in production and then, at some arbitrary time, another

by max-m 4y ago

wahnfrieden 4y ago
Sounds like real innovation toward actual continuous integration and continuous deployment! Indisputably better for the typical DORA DevOps metrics, the trick being relying on other quality controls and not treating code review as a quality control for regressions outside of feature flags. We operated this way back in the day building Canv.as and DrawQuest but without the snapshotting, that's a nice development Wish more teams would explore this type of development. Everyone is stuck in the git kernel dev model practices. It probably sounds weird because it's unusual, not because it's a DevOps bad practice (it's quite on the leading edge).
- deleted 4y ago
  [deleted]
- x3n0ph3n3 4y ago
  It also won't pass a SOC 2 audit if people can just commit anything and ship it to production with no oversight.
  - wahnfrieden 4y ago
    https://news.ycombinator.com/item?id=32697298 https://news.ycombinator.com/item?id=32697298
jdlshore 4y ago
It sounds like they’re using XP, or something similar. In XP, the code is reviewed and tested as it’s written, using pairing or mobbing for the review and TDD for the testing. (XP also uses frequent pair switching and collective ownership to get more eyes on the code, but it’s not clear to me whether they are or not.) So when the code is deployed, it’s already been reviewed and tested. The review they’re talking about here comes later, as a way of keeping the team in sync. It’s not the main code review mechanism.