3 ms·

The problem with CD is not so much that you might break production (though that's definitely an issue, even if you have comprehensive tests). The problem is th

The problem with CD is not so much that you might break production (though that's definitely an issue, even if you have comprehensive tests). The problem is that you're constantly disrupting users with new features, changes to existing ones, and usually resetting or invalidating any open sessions. I think CD is most useful to integrate into a 'staging' branch that is effectively the 'trunk' branch as far as developers are concerned. And that branch is them deployed to production on a schedule, say weekly, etc. Development should stil happen on feature branches though IMHO, just keep them small.

robertlagrant 3y ago
Not if you use feature toggles as well?
- jacknews 3y ago
  It seems like a tall order if not impossible to put every potentially breaking change or fix behind a feature toggle, and even if were possible to map the effects of every change, why bother deploying code that has no effect? It's fair enough if you're going to switch on complete features for a subset of users, but if it's just to hide incomplete parts of a feature? The practice seem like all risk for no gain.
  - williamdclt 3y ago
    It's a pretty common use of toggles, really! It has many upsides: decoupling deployment of code from feature release (useful for many reasons eg giving PMs control over the feature release), gradual feature rollouts, fast feature rollbacks, breaking up big features over multiple small PRs (eg each implementing a different part of the logic/UI), deploying "risky" code knowing you can enable/disable it instantly... We use this extensively at work, and wouldn't go back. You call it "just hiding incomplete parts of a feature", but for us that was a huge improvement in workflow. The real downside is that these flags tend to outlive their purpose; they don't get cleaned up as soon as they should.
    - doabitnormalman 3y ago
      I would like to introduce feature toggles at my place of work as well, but I'm worried we will get massive amounts of if-statements everywhere. Is there a smart way of implementing (many) feature toggles?
    - jacknews 3y ago
      Yes I agree about staged rollouts, ability to 'unrelease' features, and so on. But let's say you're part way through implemeting a new feature, and you need to alter a db table. How do you know that won't affect existing code (apart from tests)? How do you put that behind a feature flag anyway? As I said, deploying a change like this, without it being used for anything, seems like all risk and no gain.

robertlagrant 3y ago

Not if you use feature toggles as well?

jacknews 3y ago
It seems like a tall order if not impossible to put every potentially breaking change or fix behind a feature toggle, and even if were possible to map the effects of every change, why bother deploying code that has no effect? It's fair enough if you're going to switch on complete features for a subset of users, but if it's just to hide incomplete parts of a feature? The practice seem like all risk for no gain.
- williamdclt 3y ago
  It's a pretty common use of toggles, really! It has many upsides: decoupling deployment of code from feature release (useful for many reasons eg giving PMs control over the feature release), gradual feature rollouts, fast feature rollbacks, breaking up big features over multiple small PRs (eg each implementing a different part of the logic/UI), deploying "risky" code knowing you can enable/disable it instantly... We use this extensively at work, and wouldn't go back. You call it "just hiding incomplete parts of a feature", but for us that was a huge improvement in workflow. The real downside is that these flags tend to outlive their purpose; they don't get cleaned up as soon as they should.
  - doabitnormalman 3y ago
    I would like to introduce feature toggles at my place of work as well, but I'm worried we will get massive amounts of if-statements everywhere. Is there a smart way of implementing (many) feature toggles?
  - jacknews 3y ago
    Yes I agree about staged rollouts, ability to 'unrelease' features, and so on. But let's say you're part way through implemeting a new feature, and you need to alter a db table. How do you know that won't affect existing code (apart from tests)? How do you put that behind a feature flag anyway? As I said, deploying a change like this, without it being used for anything, seems like all risk and no gain.