> 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?
> 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.
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.
> 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.
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.
> "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.
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.
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."
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.
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.
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).
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.
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.
> 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].
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.
Hmm, not quite how I'd see it. You're right to point out different considerations are required for 'process and workflows', but I think Rich's simple/easy definitions still hold up in those situations, and are more useful than munging the two terms together.
So instead I'd say that when it comes to 'process and workflows' easiness becomes more important, because if it's an action you're literally doing everyday, you want that to be easy. In fact you might be willing to write more 'complex' underlying code/infrastructure (as we do when we setup CI) to make the process 'easy'.
> 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.
That's in a "Best Practices" section with this note at the top:
> This section contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity, Wikibooks or Wikivoyage. (May 2015)
I'm not an expert, and I've read no books on the subject, so I'll refrain from suggesting sources. The implication of my comment was that it's disingenuous to use that link as proof when it's marked with the equivalent of a FIXME.
First off, I have no motive to be disingenuous. I really don't care how you collaborate on software with your team.
Secondly, CI itself is considered a best practice. I don't know how you could expect wikipedia to mark it as anything else?
Here's the top link from google if you really care to learn and aren't just here to be a contrarian: https://www.thoughtworks.com/continuous-integration . There is a wealth of information on this subject that I promise all says the same thing. We can argue about whether or not CI is useful, but the practice of integrating continuously is in all the literature as well as the name itself.
Obviously if you can't break it up into smaller pieces, you can't regularly integrate smaller pieces. That's a tautology.
With that said, I've been doing this for over ten years and haven't come across that scenario. You can easily figure out all kinds of tricks to break things down, but usually only after you believe in the value of it.
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.
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?
You can bulk delete a bunch of functions and won't break anything. Your patch may require changes to 30 files but the change is minor. "Small enough pieces" is ambiguous I admit. I think a better way to put it to work is make your patch enough to get your code reviewed. If there are drastic changes, just let people know what you are planning to change (really, write out your plan). You may have to write wrappers or keeping the original function intact but write a my_api_function_2 for the newer version so people can start adopting it.
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.
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?