141–150 of 210 posts
Perforce provides something with the same effect. If you periodically get the most recent revision, you can see files with collisions in your change sets, then merge them in.
If you need to hide feature work behind a flag on prod you're probably doing it wrong. There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. And learning to work like that also has the benefit of aggressively fighting features that drag on forever. There are definitely exceptions, but 9 times out of 10 learning to develop featu…
Oh, so this is what ageism looks like? I see.
Earlier quoted context omitted.
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…
We don't put hard limits on our branch lifetime, but we groom stories with a goal to make them small enough so that the feature branch is very short lived.
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…
My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for.
As always: context. The above approach is only going to work well, when there is convenient high bandwidth communications between teammates. (Not only for your version control, but also for communication between people.)
I've seen trunk-only developers not knowing how to merge a branch back to trunk.
Well of course. If they never had constant practice at merging, they wouldn't be very good at it. Merging isn't trivial.
I've seen trunks brought into a state of disarray and never fixed again.
Can't they roll back? This strikes me as a sign of badly designed process, or developer incompetence. This should be seen as something like breaking the build. (In a CI environment, it would be breaking the build, yes?)
> 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…
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…
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
Gitflow and TBD are more similar than people think; TBD is essentially gitflow with the requirement that feature-branches can only live for 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.
Earlier quoted context omitted.
We don't put hard limits on our branch lifetime, but we groom stories with a goal to make them small enough so that the feature branch is very short lived.
Based on the quote, it sounds like the authors of this submission might count what you do as a form of "trunk-based development" then.
"The core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours." Continuous integration is a means to an end, not an end in itself.
Having such a requirement also means that people can't undertake major refactorings/rewrites of significant subsystems, leading to long term tech debt.
I'm honestly not sure if the site is satire?
No one develops in long lived feature branches in svn (rather, everyone does, but most only try it once before they realize the pain of trunk based dev is much smaller than that of svn merging).
Earlier quoted context omitted.
With TBD you can reduce the overhead of coordination between committers. Edit for clarification: "Branching in code", á la Feature Toggles is much better, because everything around it can be automated. With CVS branches, you shift that process into an earlier development stage where you need more human collaboration. So TBD can shift the focus of collaboration to things that matter more: the code.
I am very concerned that feature toggles add unnecessary complexity to the code. With Lisp Macros, for example, that would actually be quite elegant but in a language like JavaScript, we'd end up with a bunch of if'a here and there, wouldn't we? One might simplify it a bit with a different architecture, though.
Whereas the alternative, feature toggles are much better: first you don't need one for every small thing, add them to bigger features that take weeks to implement. With a team of ~10 developers you should not need more than 2 at one time (if you have more the management is at fault). Then feature toggles enforce modularity: by principle you should use them in as few places as possible, this will make the interface between the new feature and your current app as small as possible. This is a good thing!
Earlier quoted context omitted.
> CD means every commit gets built and delivered all the way prod if it passes all tests. I always wondered why a company would allow code to go straight to production, live, affecting customers, without a human giving the OK to release.
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.
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 manual testing by an expert in the area.