41–50 of 210 posts
> 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 whe…
There are definitely exceptions, but 9 times out of 10 learning to develop features in a way that they can be continuously integrated to production will dramatically reduce features dragging on, decrease bug heavy feature launches and increase velocity.
EDIT: The downvoting system on HN optimizes for older, over the hill developers as is shown here once again.
Earlier quoted context omitted.
We deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.
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.
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.
> 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 whe…
git-flow is anything but simple.
Trunk based development works well on any scm that sucks at branching. Perforce, subversion etc. But, on git, using GitHub-Flow is far superior. The two poster children for TBD do not use git. Don't cargo cult their process without understanding the unique problems they have that you don't. Edit: downvotes on HN? This isn't Reddit, and I'm advocating github flow, not git flow. GitHub flow is trunk based development b…
GitFlow and it's derivatives have very poor handling for continued bug fixes of old released versions. It might be great for a truly continuous model such as Facebook and Gmail where there is only "one true version", but in a case where there is a current version and three old versions requiring bug fixes, it fails miserably.
Earlier quoted context omitted.
You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…
So write the tests first; isn't that what we're supposed to do anyway? That way the branch doesn't move to prod on commit, because it isn't passing the tests yet. BTW "commit" is also a "manual step".
> Write tests first
What does this have to do with TBD vs branch based? Should be that way either way. In fact TBD breaks down if you don't write your tests.
> A branch doesn't move to prod on a commit
Are you saying your shipping branches to prod regardless as to if it's on trunk or not?
Or perhaps your whole comment is just saying how TBD is supposed to work and your agreeing with me?
The suggestion that feature branches hinder CD is just untrue, at least in my experience. To me, this seems like a silly restriction to put on such a critical tool (the scm) which is designed to support unlimited flexibility.
You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…
Trunk based development works well on any scm that sucks at branching. Perforce, subversion etc. But, on git, using GitHub-Flow is far superior. The two poster children for TBD do not use git. Don't cargo cult their process without understanding the unique problems they have that you don't. Edit: downvotes on HN? This isn't Reddit, and I'm advocating github flow, not git flow. GitHub flow is trunk based development b…
From the page: Depending on the team size, and the rate of commits, very short lived feature/task branches are used for code-review and build checking (CI) to happen before commits land in the trunk for other developers to depend on. This allows and engage in eager and continuous code review of contributions before they land in the trunk. This sounds roughly like what you are advocating. The resources about GitHub-fl…
Aside from that, in my opinion the whole centralised version control vs. decentralised version control, and all the variants thereof, miss the bigger issue. Keeping track of the history of a file, and the authors of the changes, is trivial for any version control system. The real challenge is in resolving merge conflicts, and it's the low level of sophistication in merge tools that is the real bottleneck here. That's why I think tools like Semantic Merge are far more important to a development workflow than SVN vs Git vs Mercurial. It relies on the merge tool understanding the structure of code rather than treating it as an ordinary text file. Similar tools could be built for any language that offers a 'compiler as a service' (such as RLS for Rust).
> 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 whe…
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.