I really wish I'd seen this earlier. We are still using feature branches and it's not working for us. I immediately shared this with my team and we are already in the process of adapting our processes.
@danielcooke3243 Жыл бұрын
Feature toggling is something i've never considered doing - wow, it really does solve the problem of long lived feature branches
@jamiemchugh3279 Жыл бұрын
From my experience feature toggling adds complication and overhead. If you don’t schedule clean up of feature toggles once a feature has settled, you end up with repeated forking of your business logic. If there’s overlap in different parts of the system, this can have a multiplier effect that violates Clean Code principles. Furthermore, clean up is a challenge as you’ve weakened your tests by introducing ambiguity of truth, and you don’t know when a feature will settle, so those cleaning up in the future may not have the context to effectively remove redundant code. Maybe I’ve done it wrong though… happy to hear arguments for it…
@TheEVEInspiration Жыл бұрын
Feature toggling is a terrible idea for anything that has some real complexity in it. There is so much that can and will go wrong with that, its a massive no no! And for the love of ***, stop thinking about code, think about data(-models), states and state changes/information flows. Any data-structure that changes or different ways in which a state is kept or how different parts of code interact, cannot be thought of as just code that one can toggle on or off. It becomes a whole different thing and having half finished stuff in the codebase will be confusing AF and cause many errors in one way or another. The examples of big changes that require months to implement, are most likely those kind of changes, so plan them right. It will not be brand new functionality that is just glued on like a new data-entry screen of some sort (kid stuff). It really becomes maintaining N different variations of the same product in the same codebase (includes database). How is one to deal with performance issues when some new solution gets introduced? How much of the unfinished code is in the way or also needs untestable changes? It is hilariously stupid. In a way it is the same as only using global variables.
@ForgottenKnight14 ай бұрын
Feature toggling is NOT a solution for long lived branches - YIKES ! STOP ! :)))
@chrisalexthomas2 жыл бұрын
ok, 2 minutes in I can already say that the first mistake was that if you need to have a long lived branch like this, you need to constantly sync master->branch and take all the low hanging changes and in addition to that, possibly refactor into the long lived branch things from the master branch that are not 100% compatible. You can't let them diverge for months and expect good results at the end
@samuelmothwa17202 жыл бұрын
My thought exactly, why don't you keep up with master.
@tiagodagostini2 жыл бұрын
Pulling from master is something that MUST be done daily .
@andrealaforgia76992 жыл бұрын
@@tiagodagostini Not if Continuous Integration is what you aim for. In the case of CI, you must integrate into master multiple times a day. It's a much simpler and effective model than feature branching.
@tiagodagostini2 жыл бұрын
@@andrealaforgia7699 That is the point where I completely disagree. COntinuous integration doe snot mena continuous deployment. The place where I worked with the best quality results (Huge software, bigger than photoshop and we kept under 3 bugs detected by clients per YEAR) we used feature branches, and every branch had to pull from master every day. When a smart ass came with this new model the company FAILED hard and the number of bugs and problems on clients skyrocketed to over 200 per year.
@andrealaforgia76992 жыл бұрын
@@tiagodagostini Not sure what you are disagreeing with, exactly. The definition of Continuous Integration is "the practice of merging all developers' working copies to a shared mainline several times a day", so exactly what I said. It is NOT merging trunk into the branches multiple times a day. Also because, if two developers branch off trunk and work independently on their branches for days, merging trunk into each branch daily has absolutely no effect. No matter how successful the company where you worked was, feature branching is a Continuous Integration antipattern and I have witnessed many situations where feature branching was creating problems. If CI is what you aim for - and you should aim for - then feature branching is the WRONG way of working. Equally, the fact that the person you call a "smart ass" was unable to implement proper CI does not mean anything. Continuous Integration is not at all a "new model". Officially, Grady Booch talked about it in 1991, but there are fundamentally equivalent practices being implemented at least 30 years before then. I suggest reading "Accelerate" (Kim, Humble, Forsgren), "Modern Software Engineering" (Farley) and the "State of DevOps" reports.
@jankinsics9 ай бұрын
Love this talk. So far the best I have watched here. I used to use git flow(the very first version). Caused lots of problems. One of the big problem is the long lived branches. It’s a nightmare. Finally, we ditched that. Our way is similar to trunk based development model with minor differences, it’s been working great.
@davidknoernschild6053 Жыл бұрын
This is the best case I have ever seen made for trunk-based development and CI. Great talk.
@CuriousCyclist2 жыл бұрын
Thanks for uploading all the good videos. You deserve more subscribers.
@JerreMuesli8 ай бұрын
Git workflow, when using short-lived branches and rebases, isn't an issue. Trunk-based development is handy at the start of a project when you both need to e.g. extend the domain model or you both need to work on the same modules (records/classes) I don't like feature toggles as it instantly creates technical debt in both code and unit/integration tests and also it increases complexity. I don't say I hate trunk-based but saying that it is a silver bullet when using git, and git workflow is bad is just ridiculous
@skipodap12 жыл бұрын
Great video and presentation.
@ramdenze2 жыл бұрын
The examples of feature branching are maybe not the full story. The most used way of doing feature branches right is called git flow. If you know how to use it you would not end up in situations like the ones illustrated. For example: You are creating a mobile app. Trunk / master has version 1.0 and you already work on 2.0 on develop branch. Now suddenly, something bad happens and you make a hotfix 1.0.1, master will be on 1.0.1 and develop branch will have 2.0 WITH fixes for 1.0.1. Works pretty well
@krajekdev2 жыл бұрын
I upvoted, that is what I was doing and still do. I do, however, start to see the advantages of trunk-based development. In ideal world feature flags of course give you more flexibility than feature branches.
@peterpopov29372 жыл бұрын
I would recommend that you watch Dave's commentary on GitFlow and why it's a bad idea that goes against CD principles. Here's the video: kzfaq.info/get/bejne/ld1mh9qfsamqp3U.html
@xXxDiukexXx2 жыл бұрын
Git flow is considered deprecated
@andrealaforgia76992 жыл бұрын
GitFlow is a CI antipattern. Look at the videos Dave Farley has published about it.
@JamesJansson Жыл бұрын
Trunk based dev is always premised on a lot of good tooling being deployed, a minimum level of employee competence which is quite high, a strong belief in honesty of the employees that they aren't malicious actors. This is why it works well at big companies.
@user-gm4he1yo8l Жыл бұрын
You said a benefit of Trunk based development is that it "encourages refactoring" but never explained how that could be so. From everything I've seen and experienced, smaller and quicker prs to the main branch do exactly the opposite. All in all, though, I found this talk very informative.
@ForgottenKnight14 ай бұрын
22:30 - It should be obvious - Darkly is super easy to implement in code and super easy to use, not to mention the other stuff.
@RikiPoon2 жыл бұрын
9:08 by branching out here, does it introduce one extra commit (the blue one right before the branch) to production? for i assume after creating R1.0 the production just need 2 yellow bug fixes, this seems to be a problematic setup to me
@danielcooke3243 Жыл бұрын
Yeah - what he says he is not possible. If you tried to merge that feature branch back into master, you would have to merge it with the 2 missing commits, therefore introducing new features to production
@ok-it4li7 ай бұрын
yes, its a vague diagram.
@ono482 жыл бұрын
So, you actually need to work on a branch forked from main trunk and merge back to it via pull requests. We just want to avoid long lived branches, call it a feature branch or a topic branch, it’s just semantics. Working directly on main trunk implies no Code review / pull request, which is a terrible practice. Main trunk needs to be protected with a branch policy
@crushingbelial2 жыл бұрын
Pair program or use PRs. Yes don't break trunk always have it ready to go but use trunk for your lowest level environments for fast feedback then prep release for controlled environments
@LeviNotik Жыл бұрын
This is a fantastic talk.
@tiagodagostini2 жыл бұрын
I am so against the concept of integrating continuously if the objective is to release fast as hell. As a costumer I hate when a company does that to me, as a software development company I hate the concept of so much entropy in the system. As I developer I am amazed by the drugs people take to have the idea that ANY practice can be said as the CORRECT way to develop.
@matthewgreen31072 жыл бұрын
100% Code quality, tests and regular merging not overdoing the tickets and work is the key. We tried this with over 100 devs it fell apart very fast as people kept breaking master and holding others up and issues being spread across others unrelated like a virus as people start fixing things. Utter headache especially when people start adding feature flags and expect a database or API still to be the same.
@tiagodagostini2 жыл бұрын
@@matthewgreen3107 One of the things that did not work for me is... you do nto knwo if what you are doing is what is really wanted or will be accepted. To know it you need a trough and detailed pass of the product department/owner and the result is.. that is the most anti agile thing ever. Notice , I am talking about software that is really developing something new that cannot be simply described as "make me a new form to insert new registries of this stuff". If the feature is "we need a new polygon split and subdivide interface that can combine the method X and Y " you are NOT going to do it correctly the first time, and therefore it should NOT be in master. As I said I would , as a costumer, drop ON THE SPOT that product if they start releasing stuff like that to me. No development branch should ever deviate too much from master, but you achieve that by everyone PULLING from master every day! I would FIRE any of my developers if they pushed to master a NEW IDEA without first presenting it in another branch to see if it is approved.
@matthewgreen31072 жыл бұрын
@@tiagodagostini spot on reply. You only have to pull from master whenever you feel you are deviating and need something. Making it a hard set rule is also not good as you may not want to integrate features from other devs and are simply demonstrating a concept feature. I have always promoted feature branches being properly tested and demonstrated to the clients as we go and when they feel they are happy they go into master. A proper feature should have tests and so when two features or more get merged into master the tests will pick up any merge issues and most of the team should have work planned to not step on each others work or they should be working on the same feature branching off it and pushing to it regular this is called quality sprint planning months ahead and understanding the product roadmap. We have NEVER had any issues and had code thrown out by clients after a sprint which would have been a real headache trying to take it out of a master merge as they went along. All this nonsense of feature flags as well introduces masses of potential for issues. Sure if it is a shopping cart go for it on a shops website but if it is a hospital system you want that rolling out with experimental stuff in it with flags for paths that people have been throwing into master?... crazy. Life and death do it right anything else is dangerous. If you want to design software for the local chip shop selling fries and it crashes sure go for main line. Also have you seen that they are now trying to advocate not doing code reviews as it takes too long and everyone should be able to review and fix as they go! wow crazy. It's like they don't want to do quality anymore and just want to be hippie devs playing with tech imho! Scary tbh that the standards are dropping in todays devs rushing to release constantly as if that is the answer to giving a client quality when all it does is introduce risk. As an aside I work on life / death systems often so perhaps this is why this scares the crap out of me also given the quality of the code some devs produce as well and the bugs they introduce even on features and having at times multiple code reviews and refixing.
@matthewgreen31072 жыл бұрын
@@tiagodagostini 100% would work in your team as you sound like you understand the real world.
@tiagodagostini2 жыл бұрын
@@matthewgreen3107 That seems to be the standard.. peopel that support that are mainly WEB stuff. People that work on defense, energy or Helathcare would put fire on you if you said to commit on main/master.
@aayushiagarwal806310 ай бұрын
When we are committing in main trunk, is it necessary to create tags for every commit. When we are going for a release, shall we cut a branch out of it or just tag??
@saikrishnasiliveru43503 жыл бұрын
Thanks Jacob
@Olga-pc3bm Жыл бұрын
Also, feature toggles makes code unclear at all. It breaks a lot of common programming rules like don't create zombie code or zombie comments. What will happen if 3-5 developers left the company and their features are in the intermediate, non-working state? Nobody can understand what they were trying to do and what was the idea. Or the implementation way could be wrong. And all this code we have in master branch! Each reader of this branch should spend time on trying to understand fired developers' thoughts until he comes to the idea that it was a wrong implementation of smth.
2 жыл бұрын
I think all the problems you're exposing arise because of a bad architecture and a lack of strategy when planing the work in parallel rather than the version control flow.
@tothestars395810 ай бұрын
Yeah I'm starting to feel like the issue the trunk-based crowd has is with their code, not with their git strategy. If your code is designed reasonably, there won't be these massive conflicts, OR these major integration issues.
@gpzim9813 жыл бұрын
This approach as well have sooo many problems
@berkes2 жыл бұрын
There are always tradeoffs and downsides. The question is, are the 'many problems' you see, worse than the benefits that trunk based development offers? Can you find solutions for them, or for most?
@MasterTrollazo2 жыл бұрын
@@andrealaforgia5066 * Expensive all the system and automation around this for most of the projects do not worth it. * The logic of versions moved from git to feature toggle, you are maintaining all the possible combinations of all features toggle. If you have 5 features toggle. 2^5 versions = 32 (If I remember maths correctly) * Unused code in the main version, you need to clean and reduce your artificial incremented codebase. In the feature branch, you can discard completely the change or incorporate it, but is not going to generate unused code. * Many big companies with a lot of concurrent users are using it. However, not in all of their products. Also, we are still suffering a lot of bugs in their products.
@casper0at0ease2 жыл бұрын
@@MasterTrollazo you use TBD for SaaS and therefore only have one version, which makes your whole argument moot
@MasterTrollazo2 жыл бұрын
@@casper0at0ease if they behave different for the same circumstances for different users, are different versions.
@lauyuhin2 жыл бұрын
Agree. Fixing bug in master could cause problem as well.
@tarankaranth87822 жыл бұрын
can we do without release branch with feature toggle?
@VictorMartinez-zf6dt Жыл бұрын
yes
@andrecampbell7365 Жыл бұрын
I only know trunk based development.
@SM-ok3sz2 жыл бұрын
Why is it always assumed branches are always out of sync with the parent branch? Does your git pull not work? Sounds like a case of poor development practices.
@emyrulz2 жыл бұрын
This! Also, it seems to me that there is this assumption that people are working on stuff that 100 other people are working on at the same time and that is being changed hourly somehow. This is nuts. Part of it stems form misunderstood practices where features are broken down way too much and too many developers work in parallel on them. What happened to one dev working on something from start to end, alone?
@lauyuhin2 жыл бұрын
Total agree. If everyone git pull frequently in their feature branch, feature won't be out of sync.
@andrealaforgia76992 жыл бұрын
It's not continuous integration.
@VictorMartinez-zf6dt Жыл бұрын
Do you pull your colleague's changes from their branches as well?
@lcppproductions79102 жыл бұрын
4:42 "You haven't really tested this combination of features yet" umm... Pull from master incrementally, so you get the previously Merged feature, and then test it before you integrate? Is that not a thing?
@bsuperbrain3 жыл бұрын
feature branching is great, you just need to rebase often
@berkes2 жыл бұрын
Do you rebase all your colleagues' open feature branches "often"? How do you know what feature branches you must rebase on? Do all your colleagues push their feature branches often? And can they then still push them --forced?
@TommasoLumare2 жыл бұрын
@@berkes I think @bsuperbrain was meaning that it would be better to *rebase your feature branch onto master often* to pull in all the bugfixes and the features that your colleagues bring into the master which is not a bad idea if you think carefully.
@carabouzouklis2 жыл бұрын
Feature Flags are better
@rc30432 жыл бұрын
@@carabouzouklis I think rebasing often during a day and then merge your current work daily to the master branch from that feature branch is behind a feature toggle is a good middleground for this kind of work :)
@m.x.2 жыл бұрын
Rebasing is not continuous integration.
@zerohecks48642 ай бұрын
Flavor of the month shit
@agile2academy2 жыл бұрын
I guess Linus Torvalds is not a real programmer.
@TheEVEInspiration Жыл бұрын
Its always possible to do trunk based changes, even when using feature branched for other stuff. So that negates any argument in favor of CI, let alone CD. Really I hate these videos made by amateurs, trying to solve problems that already have working solutions. Just because they stumbled and messed up in obvious ways before using one method, does not mean another is somehow superior. I only see downsides to CI, let alone CD, not even customers want it (they hate constant change). It simply cannot work for most kinds of projects, every showcase is about an existing product undergoing insignificant changes. Not because they are broken up in small pieces, but because they really are that insignificant.
@m.x.2 жыл бұрын
Problem: young generations reinventing the wheel again and again.
@matswessling6600 Жыл бұрын
feature branches simply periodically merge main back into it. problem solved.
@VictorMartinez-zf6dt Жыл бұрын
no, not really.
@matswessling6600 Жыл бұрын
@@VictorMartinez-zf6dt yes, really.
@ddanielsandberg Жыл бұрын
@@matswessling6600 No, not really. The point is that when you have 30 developers, each working on their own branches for days (or worse, weeks) on end, what does it help rebasing from master? You still won't know if anyone else's changes conflicts with all other changes until they're merged into master.
@jamiemchugh3279 Жыл бұрын
@@ddanielsandbergyou will once they request a PR, or further on, push to master, then those changes are pulled to the feature branch. Then conflicts can be resolved in the isolation of the feature branch, rather than on master? I remain unconvinced here that the problem trying to be solved is due to a combination of messy code / architecture and a lack of coordination/communication between different teams. That said, I never advocate for long lived branches. I just like the temporary isolation and PR mechanism.
@redhotbits Жыл бұрын
we used trunk based and our new boss forced us to use gitflow
@tommcannally1895 Жыл бұрын
Bummer
@howardh685711 ай бұрын
And what’s your opinion now
@redhotbits11 ай бұрын
@@howardh6857 i see many teams do not practice feature flags, some boses do not like that... thats an issue and prevents trunk based to be used
@jankinsics9 ай бұрын
We switched from gitflow to trunck based.
@redhotbits6 ай бұрын
@@howardh6857 trunk based ofc, even on atlasian page it states that trunk based is the best practice. But practices are evil, sometimes you need to unlearn the old best practices and learn new best practices.
@tiagodagostini2 жыл бұрын
I will give you a single example why real development teams do not commit to trunk as you say. ON the field I operate, it is REGULATORY BOUND that every single feature must be tested and must be available in a state that is the exact previous released version of the product PLUS the feature itself. If you MIX 2 features development release cycles, you lose your license and your company is SHUT DOWN . That is how healthcare operates in several countries. You CANNOT effectively have 2 teams comiting to the same branch because you violate these rules.
@haraldhacker2 жыл бұрын
so what concept you follow? Thanks
@xXxDiukexXx2 жыл бұрын
That law says nothing about branches, with feature toggles you are not releasing an active feature therefore is not available in that release, unless activated either remotely or in a future release
@tiagodagostini2 жыл бұрын
@@xXxDiukexXx The thing is I must have specific versions with EACH new feature separate from all other new versions. That is unfeasible in a single branch and alarge team that is working on several teams at same time. That law does not care if the feature is active or not, but the feature existing in the artifact of software or not.
@JonathanYee2 жыл бұрын
The principles of trunk base is the big take away. He did mention about release branch + cherrypicking. That would be best suit to your architecture.
@VictorMartinez-zf6dt2 жыл бұрын
Two words, continuous integration.
@vickmackey24 Жыл бұрын
"master"?! 😱🤯
@FudgeYeahLinusLAN Жыл бұрын
You must be an absolute joy to work with...
@israelterorisprikopat27 күн бұрын
❤❤❤❤
@julianosouza83822 жыл бұрын
real devs commit to master and deploy stuff in friday night N O T
@chrisalexthomas2 жыл бұрын
You clearly have never worked a day in your life! 🤣🤣🤣 (just kidding)