Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trunk-Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

151–160 of 210 posts

Re: Trunk-Based Development

#151

Post by sydd »

alkonaut wrote: post #148

In subversion the only way I can possible develop with sanity is in an "unstable trunk". Branch off releases N weeks before shipping, and have only the requirement that trunk passes automated tests while release branches are manually tested. Obviously you don't release more than say once every month or two, but that's more than enough for most. I'm honestly not sure if the site is satire? No one develops in long live…

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the clean code book, read about modern organisation practices (e.g. Github releases several times a day). Releasing every month or so is (thank God) a relic of the old waterfall development times.

Re: Trunk-Based Development

#152

Post by sydd »

whack wrote: post #145
simula67 wrote: post #50

Earlier quoted context omitted.

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 g…

> "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,…

But if feature branches can live less than a day then why not get rid of them altogether? They are just extra bueurocracy that just slow you down.

Re: Trunk-Based Development

#153

Post by nilliams »

daenney wrote: post #134
nilliams wrote: post #122

Earlier quoted context omitted.

> 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

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…

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'.

Re: Trunk-Based Development

#154

Post by viraptor »

alkonaut wrote: post #148

In subversion the only way I can possible develop with sanity is in an "unstable trunk". Branch off releases N weeks before shipping, and have only the requirement that trunk passes automated tests while release branches are manually tested. Obviously you don't release more than say once every month or two, but that's more than enough for most. I'm honestly not sure if the site is satire? No one develops in long live…

It's not satire. In your case the automated tests are just weak. You call the trunk unstable, because you need extra manual testing. What the page describes is an improvement on that. The CI system should have good enough tests to guarantee your trunk is never considered unstable. Then it doesn't really matter when you make a release - it's not a big deal. (Just choose a commit you like)

Re: Trunk-Based Development

#155

Post by rabidrat »

sydd wrote: post #151
alkonaut wrote: post #148

In subversion the only way I can possible develop with sanity is in an "unstable trunk". Branch off releases N weeks before shipping, and have only the requirement that trunk passes automated tests while release branches are manually tested. Obviously you don't release more than say once every month or two, but that's more than enough for most. I'm honestly not sure if the site is satire? No one develops in long live…

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the clean code book, read about modern organisation practices (e.g. Github releases several times a day). Releasing every month or so is (thank God) a relic of the old waterfall development times.

I would say this must be satire but you seem sincere. You are promoting a thin slice of modern "best practices" which are not the only way to do software development. And it doesn't sound like you've ever worked on a major software project if you think that a month is a prohibitively long development timeframe. A mid-size architectural refactor of a large codebase can and maybe should take a month. When you get into the 200k+ SLOC range, no one person understands the entire thing, and most of us don't want to 'move fast and break things' when a little forethought, communication, and analysis can avoid it. I think this 'growth at all costs mentality' is ruining a lot more than our software, too.

Re: Trunk-Based Development

#156

Post by diek »

sydd wrote: post #151
alkonaut wrote: post #148

In subversion the only way I can possible develop with sanity is in an "unstable trunk". Branch off releases N weeks before shipping, and have only the requirement that trunk passes automated tests while release branches are manually tested. Obviously you don't release more than say once every month or two, but that's more than enough for most. I'm honestly not sure if the site is satire? No one develops in long live…

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the clean code book, read about modern organisation practices (e.g. Github releases several times a day). Releasing every month or so is (thank God) a relic of the old waterfall development times.

No, they're not. Is IntelliJ "doing it wrong" to release every three months[1] ? Absolutely not. A release can change things about a product, and you want to ensure you are pushing those changes (UI, behavior, plugin APIs) at a pace that matches the users. You don't want to be pushing changes to a plugin API every day. The surface area of stability that has to be maintained at that point is insane.

In the interim, you should definitely be able to build off master. Your CICD server should build and run tests on every commit to master. Then a release gets a tag in version control and you should be able to issue bug fix releases for only that specific version. Telling customers, "There is a critical security bug in version X, but in order to fix that bug you need to upgrade completely to version X+2" is not an acceptable answer.

Note that the description above works best in my experience for products that push a release artifact (like IntelliJ) versus a service like GitHub. Release management approaches will vary based on the product.

[1] https://www.jetbrains.com/idea/download/previous.html

Re: Trunk-Based Development

#157

Post by iatanasov »

kosma wrote: post #68

This workflow, like all others, is just a formalization of some reality. The reality is that many organizations and teams run on nothing but trunk - and it more-or-less works on them. Some teams work by building blocks separately and then joining them together; other prefer to hammer away on a problem all together. Both approaches work. What worries me are emotional claims that the other approach is fundamentally fla…

In other words there is no size fits all there is even no size fit two . All those workflows are based on the management o the organization it self .

Re: Trunk-Based Development

#158

Post by paulddraper »

qwer wrote: post #137
paulddraper wrote: post #127

Earlier quoted context omitted.

You can have long lived release branches in "trunk-based development"?!? In that case, I guess I haven't ever seen a branching strategy that wasn't "trunk-based." What would that even be?

Anything involving long-lived feature branches especially ones with multiple collaborators, eg git-flow.

If I understand git-flow correctly, it's a trunk (develop) with a release branch (master).

Re: Trunk-Based Development

#159

Post by dpark »

alkonaut wrote: post #150
dpark wrote: post #77

Earlier quoted context omitted.

Because you should be able to automate that OK. There is generally no verification that a human can do on a computer system that cannot be automated. The only question is whether you're willing to invest enough to fully automate the go/no go decision.

So the person that has an opportunity to misunderstand the specification (the developer) is given the task of writing the tests to OK them, even though the test is based on the same misunderstanding? That's terrifying. After 15 years in the same field I still don't have half the business knowledge as those writing the specs I implement. I would never ever want a nontrivial feature I wrote to hit a customer without ma…

Where do you work that software engineers write code and then hand off their code to non-software-engineer "experts" for testing? That sounds like a really broken process.

Re: Trunk-Based Development

#160

Post by [deleted] »

icebraining wrote: post #131
whyileft wrote: post #70

Yup, as the other comment stated, this is par for the course in modern quality software development. Its actually rather shocking to me to see my comment get downvoted. The quality of the HN audience is declining dramatically. Feels like all we have is a bunch of web agency lifers at this point.

Feature flags are used by essentially every major software company. Hell, the browser you're using to post this has quite a few. A bunch of major software companies use them heavily as well. You may disagree and think they're terrible, but calling their users just "web agency lifers" is objectively incorrect.

[deleted]
Post reply on HN