5 ms·

We deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.

hashkb 10y ago
Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.
- nhumrich 10y ago
  The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.
  - hashkb 10y ago
    Rebase early and often and this isn't an issue. Some see this as a chore, but I view it as taking advantage of the tool's power. You resolve the same set of conflicts as you would merging, but (as you say) earlier. Edit: I don't think anyone was trying to imply a single allowed feature branch at a time; we can probably all easily agree that's basically no different than working on master.
    - nhumrich 10y ago
      Yes, rebase early and often works great. But if your branch includes a major refactor, your going to find yourself editing others code to get your rebase to work. That just increases your own scope. But yes, rebase often is often a very viable strategy. In practice though, I find very few that actually do it because it becomes painful when your branch lives too long simply because business isn't ready to ship something
    - notarealdoctor 10y ago
      Rebase is evil.
  - angry_octet 10y ago
    Can you explain how a repo with dozens of feature flags triggering greatly different code paths, and invisible to the source code management system, is an improvement on feature branching? How would I use git bisect with a bunch of flags to a composite of build systems?
nhumrich 10y ago
By "short lived", how short lived? Is the branch only for one developer? Or is it shared? How do you enforce "short lived"? If the branches are not collaborated on, you might be doing trunk based without realizing it.
- hashkb 10y ago
  >you might be doing trunk based without realizing it. Then trunk based is poorly named and apt to start a fruitless holy war. Nobody wants too many people on a feature branch, or for one to live too long. (But it happens, like rebranding an entire app or rewriting all the auth code, which is a good thing to be able to do. ) Is there a threshold of time/collaboration that makes it not-CD?
  - nhumrich 10y ago
    My point is that the article says that branches for the purpose of WIP and code review is OK as long as you don't share the branches. Trunk based is trunk "based" as in your git "base". Your based on trunk, not a branch. It's not called "commit directly to trunk only" development.
- joneholland 10y ago
  Holy shit. Just admit that TBD is a fad instead of trying to define every successful methodology into it. Branches tend to be solo devs and tend to live less than a day. But nobody develops in master. It's actually locked down to just merges from pull requests.

hashkb 10y ago

Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.

nhumrich 10y ago
The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.
- hashkb 10y ago
  Rebase early and often and this isn't an issue. Some see this as a chore, but I view it as taking advantage of the tool's power. You resolve the same set of conflicts as you would merging, but (as you say) earlier. Edit: I don't think anyone was trying to imply a single allowed feature branch at a time; we can probably all easily agree that's basically no different than working on master.
  - nhumrich 10y ago
    Yes, rebase early and often works great. But if your branch includes a major refactor, your going to find yourself editing others code to get your rebase to work. That just increases your own scope. But yes, rebase often is often a very viable strategy. In practice though, I find very few that actually do it because it becomes painful when your branch lives too long simply because business isn't ready to ship something
  - notarealdoctor 10y ago
    Rebase is evil.
- angry_octet 10y ago
  Can you explain how a repo with dozens of feature flags triggering greatly different code paths, and invisible to the source code management system, is an improvement on feature branching? How would I use git bisect with a bunch of flags to a composite of build systems?

nhumrich 10y ago

By "short lived", how short lived? Is the branch only for one developer? Or is it shared? How do you enforce "short lived"? If the branches are not collaborated on, you might be doing trunk based without realizing it.

hashkb 10y ago
>you might be doing trunk based without realizing it. Then trunk based is poorly named and apt to start a fruitless holy war. Nobody wants too many people on a feature branch, or for one to live too long. (But it happens, like rebranding an entire app or rewriting all the auth code, which is a good thing to be able to do. ) Is there a threshold of time/collaboration that makes it not-CD?
- nhumrich 10y ago
  My point is that the article says that branches for the purpose of WIP and code review is OK as long as you don't share the branches. Trunk based is trunk "based" as in your git "base". Your based on trunk, not a branch. It's not called "commit directly to trunk only" development.
joneholland 10y ago
Holy shit. Just admit that TBD is a fad instead of trying to define every successful methodology into it. Branches tend to be solo devs and tend to live less than a day. But nobody develops in master. It's actually locked down to just merges from pull requests.