6 ms·

> Trunk Based Development is a key enabler of Continuous Integration, and by extension Continuous Delivery. Quite false. How do you expect developers to take y

by vemv 10y ago

> Trunk Based Development is a key enabler of Continuous Integration, and by extension Continuous Delivery. Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Trunk-based development seems to rely heavily on feature flags, which are a huge source of complexity and inconsistency. Even when useful, they're liabilities; not assets. git-flow (and variations) is simple, enables consistent codebase state, makes no assumptions about your codebase/infrastructure, and allows you to know the exact state of production/staging. Finally, as it happens so often with open source projects and initiatives, first thing I should see is a big "Why". Why do I want this? Why are the alternatives inferior?

hashkb 10y ago
I'm on your side but my comment (yours is better) faced opposition so: They redefine CD and then say nothing else is it, and you aren't doing it.
- mbrock 10y ago
  It seems like many people are unaware that "continuous integration" since its inception has meant pretty much the same thing as "trunk based development." Wikipedia's definition: "In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day."
  - hashkb 10y ago
    That sounds like it allows for feature branches to me. Edit: anyway, isn't that extremely pedantic? I've known literally hundreds of companies that say "we are using CI" when what they mean is "master is continuously tested + deployed"... is there a name for that we should all start using? I'm not trying to diminish the awesomeness of "real" CD that some of you out there appear to be doing and proud of preserving the term for.
    - qwer 10y ago
      It does, but feature branches become pretty useless at that point. It makes a lot less sense to have a branch for something you plan to merge immediately after the first commit (though my team actually does this just to take advantage of github's PR functionality).
    - lotyrin 10y ago
      TBD as described here also allows for feature branches (but they must be short lived and owned/worked on by a single developer -- which seems reasonable to me). I think people are seeing TBD as "no-branches ever" and that is not it's goal or design.
whyileft 10y ago
Because any long running feature branch can just live in a different repo until its ready to merge. There is a reason they are called branches not trunks. Except for rare exceptions developers should be able to break up features in a way that they can be continuously integrated during development.
Walkman 10y ago
git-flow is anything but simple.
- vemv 10y ago
  It's simple but it requires effort and habits. Many developers work using the opposite mindset, they prefer to trade short-term easiness for long-term complexity (which is kinda valid), instead of battling complexity upfront.
  - daenney 10y ago
    > It's simple but it requires effort and habits. That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not to say there aren't any benefits to it or that developing those habits are a waste, but it's not simple. Changing existing or developing new habits is not without difficulty, it takes time, patience and perseverance.
    - nilliams 10y ago
      > That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not a great definition of 'simple' to apply to software dev. Simple != easy, because easy is inherently about familiarity. See Rich Hickey's excellent talk on the subject [1]. [1] https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy
      - daenney 10y ago
        That talk doesn't relate to the whole discipline of software development though. He's mostly arguing that if you chose ease over simplicity in your programming/code it can heavily effect the output of your work and its long term viability. It's about not introducing complexity in the design and your product. But this is about the process and workflows of collaboration on code, not the code or the product itself. Some of these concepts certainly apply but just because it is in the realm of software development doesn't mean that particular definition always applies.
simula67 10y ago
I have worked at organizations that followed TBD and git-flow. TBD is much better for software that is delivered to the end user as a package ( not as a SaaS ), ones that does not require a staging branch > Why are the alternatives inferior? This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time. With this model, all changes are always present on trunk first and are cherry-picked onto the release branch. Release owners can selectively choose to include whatever changes they are comfortable with onto their releases. This dramatically signifies communication and management of releases.
- whack 10y ago
  > "This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time." If you're doing git-flow right, your PRs shouldn't be blocked at any time. You should have a dev branch, which everyone is working off of. Any feature branches should be branched off of dev, and any approved PRs should be merged back into dev asap. Developers concerned about conflicts can also merge dev into their feature branches, on a regular basis, in order to catch and resolve conflicts early on. Creating a new release is then as simple as creating a snapshot of the dev branch. https://datasift.github.io/gitflow/IntroducingGitFlow.html https://datasift.github.io/gitflow/IntroducingGitFlow.html Gitflow and TBD are more similar than people think; TBD is essentially gitflow with the requirement that feature-branches can only live for <24 hours. Short-lived feature branches does reduce the potential for conflicts, which sounds great, except that 1) By forcing people to create multiple PRs every single day, people are spending a ton of time dealing with the PR review/discuss/update process. 2) Because many features require multiple days to develop, you're going to have a bunch of half-finished code littered all over your codebase, gated behind temp flags. If TBD was tweaked with the requirement that developers should merge commits into trunk every 7 days, I'd be all for it. 24 hours sounds to me like death by a thousand papercuts.
paul_h 10y ago
Publications promoting Trunk Based Development include the best-selling book called Continuous Delivery - https://trunkbaseddevelopment.com/publications/ https://trunkbaseddevelopment.com/publications/
qwer 10y ago
> Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Quite true actually! : https://en.wikipedia.org/wiki/Continuous_integration#Everyone_commits_to_the_baseline_every_day https://en.wikipedia.org/wiki/Continuous_integration#Everyon...
- dursk 10y ago
  If you learn how to break features down into small chunks, you can commit to master near-daily while still doing git flow.
  - pdonis 10y ago
    > If you learn how to break features down into small chunks If that's possible. What if there are some features for which it isn't?
    - yeukhon 10y ago
      You try by testing. Take big software like Firefox as an example. There are hundreds of commits landing on a good day and to merged into moz central you need to submit the patch for review and testing. Once the code is merged there are more testing and if something broke along the way the release team will figure out ans backout the bad commits or get someone add a fix asap. It is important to not be afraid to merge but also be responsible for your code. Take major refactoring as an example - don't create a patch which is partially implemented with breakage. You can ask for review but don't request a merge knowing it will break - actually your tests should tell you that. Finally, it is important to communicate changes regularly. Developers shouldn't be suprised to see their changes broken because someone else decised to refactor all the sudden.
      - pdonis 10y ago
        > You try by testing. I understand that testing tells you you broke the trunk, so you didn't break up the feature into small enough merge-able pieces. My question is what happens if you can't break it up any smaller--do you just throw up your hands and say you can't implement the feature because there's no way to break it up into small enough pieces?
SideburnsOfDoom 10y ago
> Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Do you not understand that the "Integration" in continuous integration literally means "merge to master". Please read the first paragraph https://en.wikipedia.org/wiki/Continuous_integration https://en.wikipedia.org/wiki/Continuous_integration What you do might work well for you, but if you build long-lived branches then it's not CI. Let's not call it something that it's not: words have meaning if we are to communicate, and we're not doing post-truth software development.
- vemv 10y ago
  These days CI vastly means test-on-commit over anything else. Please google "CI platform" and see how Codeship, Circle, Travis etc self-advertise as CI platforms. None of them require TBD (not even nearly).
  - SideburnsOfDoom 10y ago
    > These days CI vastly means test-on-commit over anything else. Quite false. That is a miscommunication. I know what those "CI servers" do, I have worked with a few of them them daily for years and had this exact same issue come up. These tools enable the continuous integration workflow, and lately they also enable other workflows such as "build and test the branches but don't integrate". If that's what you do fine, but let's not confuse it with something that it is not. Words have meaning. CI is not a tool, it's in how you use the tools. But if you still think that wikipedia is wrong, I suggest that you edit it. Good luck.
  - paul_h 10y ago
    Quite correct. Snap-CI is configurable to test every active branch, on first commit/push - https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-per-commit-speculative-mergability-verification-2013 https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-p... Of course doing that will expose problems that lead the dev team to reconsider Trunk Based Development.

by vemv 10y ago

hashkb 10y ago

I'm on your side but my comment (yours is better) faced opposition so: They redefine CD and then say nothing else is it, and you aren't doing it.

mbrock 10y ago
It seems like many people are unaware that "continuous integration" since its inception has meant pretty much the same thing as "trunk based development." Wikipedia's definition: "In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day."
- hashkb 10y ago
  That sounds like it allows for feature branches to me. Edit: anyway, isn't that extremely pedantic? I've known literally hundreds of companies that say "we are using CI" when what they mean is "master is continuously tested + deployed"... is there a name for that we should all start using? I'm not trying to diminish the awesomeness of "real" CD that some of you out there appear to be doing and proud of preserving the term for.
  - qwer 10y ago
    It does, but feature branches become pretty useless at that point. It makes a lot less sense to have a branch for something you plan to merge immediately after the first commit (though my team actually does this just to take advantage of github's PR functionality).
  - lotyrin 10y ago
    TBD as described here also allows for feature branches (but they must be short lived and owned/worked on by a single developer -- which seems reasonable to me). I think people are seeing TBD as "no-branches ever" and that is not it's goal or design.

whyileft 10y ago

Because any long running feature branch can just live in a different repo until its ready to merge. There is a reason they are called branches not trunks. Except for rare exceptions developers should be able to break up features in a way that they can be continuously integrated during development.

Walkman 10y ago

git-flow is anything but simple.

vemv 10y ago
It's simple but it requires effort and habits. Many developers work using the opposite mindset, they prefer to trade short-term easiness for long-term complexity (which is kinda valid), instead of battling complexity upfront.
- daenney 10y ago
  > It's simple but it requires effort and habits. That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not to say there aren't any benefits to it or that developing those habits are a waste, but it's not simple. Changing existing or developing new habits is not without difficulty, it takes time, patience and perseverance.
  - nilliams 10y ago
    > That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not a great definition of 'simple' to apply to software dev. Simple != easy, because easy is inherently about familiarity. See Rich Hickey's excellent talk on the subject [1]. [1] https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy
    - daenney 10y ago
      That talk doesn't relate to the whole discipline of software development though. He's mostly arguing that if you chose ease over simplicity in your programming/code it can heavily effect the output of your work and its long term viability. It's about not introducing complexity in the design and your product. But this is about the process and workflows of collaboration on code, not the code or the product itself. Some of these concepts certainly apply but just because it is in the realm of software development doesn't mean that particular definition always applies.

simula67 10y ago

I have worked at organizations that followed TBD and git-flow. TBD is much better for software that is delivered to the end user as a package ( not as a SaaS ), ones that does not require a staging branch > Why are the alternatives inferior? This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time. With this model, all changes are always present on trunk first and are cherry-picked onto the release branch. Release owners can selectively choose to include whatever changes they are comfortable with onto their releases. This dramatically signifies communication and management of releases.

whack 10y ago
> "This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time." If you're doing git-flow right, your PRs shouldn't be blocked at any time. You should have a dev branch, which everyone is working off of. Any feature branches should be branched off of dev, and any approved PRs should be merged back into dev asap. Developers concerned about conflicts can also merge dev into their feature branches, on a regular basis, in order to catch and resolve conflicts early on. Creating a new release is then as simple as creating a snapshot of the dev branch. https://datasift.github.io/gitflow/IntroducingGitFlow.html https://datasift.github.io/gitflow/IntroducingGitFlow.html Gitflow and TBD are more similar than people think; TBD is essentially gitflow with the requirement that feature-branches can only live for <24 hours. Short-lived feature branches does reduce the potential for conflicts, which sounds great, except that 1) By forcing people to create multiple PRs every single day, people are spending a ton of time dealing with the PR review/discuss/update process. 2) Because many features require multiple days to develop, you're going to have a bunch of half-finished code littered all over your codebase, gated behind temp flags. If TBD was tweaked with the requirement that developers should merge commits into trunk every 7 days, I'd be all for it. 24 hours sounds to me like death by a thousand papercuts.

paul_h 10y ago

Publications promoting Trunk Based Development include the best-selling book called Continuous Delivery - https://trunkbaseddevelopment.com/publications/ https://trunkbaseddevelopment.com/publications/

qwer 10y ago

> Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Quite true actually! : https://en.wikipedia.org/wiki/Continuous_integration#Everyone_commits_to_the_baseline_every_day https://en.wikipedia.org/wiki/Continuous_integration#Everyon...

dursk 10y ago
If you learn how to break features down into small chunks, you can commit to master near-daily while still doing git flow.
- pdonis 10y ago
  > If you learn how to break features down into small chunks If that's possible. What if there are some features for which it isn't?
  - yeukhon 10y ago
    You try by testing. Take big software like Firefox as an example. There are hundreds of commits landing on a good day and to merged into moz central you need to submit the patch for review and testing. Once the code is merged there are more testing and if something broke along the way the release team will figure out ans backout the bad commits or get someone add a fix asap. It is important to not be afraid to merge but also be responsible for your code. Take major refactoring as an example - don't create a patch which is partially implemented with breakage. You can ask for review but don't request a merge knowing it will break - actually your tests should tell you that. Finally, it is important to communicate changes regularly. Developers shouldn't be suprised to see their changes broken because someone else decised to refactor all the sudden.
    - pdonis 10y ago
      > You try by testing. I understand that testing tells you you broke the trunk, so you didn't break up the feature into small enough merge-able pieces. My question is what happens if you can't break it up any smaller--do you just throw up your hands and say you can't implement the feature because there's no way to break it up into small enough pieces?

SideburnsOfDoom 10y ago

> Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Do you not understand that the "Integration" in continuous integration literally means "merge to master". Please read the first paragraph https://en.wikipedia.org/wiki/Continuous_integration https://en.wikipedia.org/wiki/Continuous_integration What you do might work well for you, but if you build long-lived branches then it's not CI. Let's not call it something that it's not: words have meaning if we are to communicate, and we're not doing post-truth software development.

vemv 10y ago
These days CI vastly means test-on-commit over anything else. Please google "CI platform" and see how Codeship, Circle, Travis etc self-advertise as CI platforms. None of them require TBD (not even nearly).
- SideburnsOfDoom 10y ago
  > These days CI vastly means test-on-commit over anything else. Quite false. That is a miscommunication. I know what those "CI servers" do, I have worked with a few of them them daily for years and had this exact same issue come up. These tools enable the continuous integration workflow, and lately they also enable other workflows such as "build and test the branches but don't integrate". If that's what you do fine, but let's not confuse it with something that it is not. Words have meaning. CI is not a tool, it's in how you use the tools. But if you still think that wikipedia is wrong, I suggest that you edit it. Good luck.
- paul_h 10y ago
  Quite correct. Snap-CI is configurable to test every active branch, on first commit/push - https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-per-commit-speculative-mergability-verification-2013 https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-p... Of course doing that will expose problems that lead the dev team to reconsider Trunk Based Development.