We are going waaaay out of topic hereIt shouldn't surprise me that there are lots of people from the software industry in a Tesla forumI may have dragged this topic off-track.
Sadly I'd have to agree. Anyone that doesn't do at least test-first development, and ideally test-driven development, should not be allowed to write production systems consumed by members of the public. If digital infrastructure was physical, there's no way authorities would let it be built the way that large enterprises generally tend to.
I'm not, although I should have been more clear that I was referring to feature flags to disable unfinished functionality and prevent those code paths from being used in production. I'd expect this to be used to allow WIP to be committed to master/main when practicing continuous delivery. Between process boundaries is a bit different, you can get around that with different minor/patch releases of services being available concurrently, and rely on the routing layer to ensure clients get the behaviour they're expecting.
You pull out the feature flags once the code has been enabled in production. I'd agree that long-lived feature flags are bad; they should exist as long as is necessary and no longer for exactly the reason you mention.
Reminds me of a gambling company that I worked with, where the testers got a bonus dependent on the number of passing tests they had. Would you believe that their tests didn't find many bugs?
I absolutely, categorically disagree on this in the strongest possible terms
Some continuous deployment purists would argue that testing before deployment isn't even necessary, and it's better to have very responsive rollback mechanisms and progressive rollouts. The weakness of this approach is that causality becomes hard to track in large, distributed systems, and doesn't protect against emergent phenomena.
Git Flow and feature branch-based workflows work for open source projects contributed to by unknown, untrusted and uncontrollable third parties - this should not be an aspiration for an enterprise working on a product. They delay feedback (discovery of merge conflicts, semantic conflicts) increasing lead-time-to-production and increasing the risk of rework being needed. This is in addition to incentivising isolationist approaches from developers working solo, and a lack of shared vulnerability allowed by developers rebasing the heck out of their feature branch before raising a PR, so that no-one else on the team ever saw all the mis-steps they made on the way to getting the perfect commit.
If you don't trust trunk-based development, that's a smell that your processes, tests and monitoring aren't good enough.
I agree with you; however, you describe development of non-critical systems. I have not heard of anyone doing continuous deployment in medical, financial, aeronautics, energy, etc. Especially, deploying without testing, relying on “fall forward” or “quick rollback”.
Continuous deployment is good for non-critical, consumer-grade systems. Certainly not for cars. You cannot “rollback” a dead person.
