Feature Branches & Toggles in a Post-GitHub World • Sam Newman • GOTO 2017

[@thecomputingchronicles]

What a fun project Dixons was. I was involved in it up to I think 2004 when Dixons branched off from the core project run by the company I worked for at the time. That and some similar projects helped shape my approach today. I also 100% agree with Sam that developing software is a social not an isolated activity and certainly every team/project I've run, runs this way.

[@GhazanfarNaqvi]

I prefer trunk development but the problems lie within the developer. Some of them don't know how to do proper abstraction branching and make a mess of everything.

[@karelsmutny7038]

Very nicely explained, kudos!

[@ArchimedesTrajano]

I think if the R4 team is smallish enough, they should "rebase daily" and work with the R3 team to see if some of the R4 code can be merged into R3 then rebase to "remove the commit in R4

[@GP-ez5ms]

Teams should be independent

[@andrealaforgia]

Rebasing daily, in general, does not help one bit. If two developers branch from master and keep working on their branches for days, rebasing daily does not bring any benefits (as no changes have landed into master yet). They won't be able to see each other's change for days.

[@krish264u]

Feature toggle though solve problem and make trunk code releasable but most likely some features are not done-done but partially working which means dead code in production. It's good talk though but continuous delivery is much more complex in enterprise

[@bartekpran]

I saw companies that had trunk-based development and moved to feature branches because they wanted to have a sensible code review process. How do you do code review in projects when you are doing trunk-based development? I've seen a few solutions, but they weren't as sensible as PR code review (for example reviewing code in every commit separately). Thanks for the talk!

[@kobac8207]

by doing Pair Programming :) Or by inviting person to come to your computer and do the code review together. That's why it's important to have collocated teams. DVCSs and Git were created because of open source distributed development. That's the only reason.

[@andrealaforgia]

Pair programming does not exclude code-reviewing though. If A and B pair up, their changes should be reviewed by C and D. IMO you need at least 2 reviewers who are not the directly involved in the original development. Moreover, informal code-reviewing is really imperfect and not as effective as a pull-request based one. I've experienced both and totally prefer pull requests. What very often happens when inviting your colleague to your desk for a code review is that he/she might suggest changes and you might take for granted that the way you apply them is okay with them - therefore excluding them from further reviews. Things get complicated when part of your team is co-located and part is somewhere else on the planet (maybe with such a time gap to prevent daily interaction). Trunk-based development is an interesting idea, but I think that having short-lived feature branches is totally necessary at times.

[@kobac8207]

yup, I agree that code reviewing complements pair programming and I'd agree that having a guy who coded the part that is reviewed by you can have an impact on your perception and on ability to be unbiased when reasoning about the code. But, if the goal is to be objective/unbiased when doing code review, I don't think that you have to have Pull Request functionality of your source control in place in order to do this. You just need to be alone or not interrupted by the guy who coded, when reviewing and this can be done in place. For me CR with PR is too heavy for a team and introduces a process that I'm questioning if it's needed and believe that slows down the team in the end. As for the distributed teams, if they're working on the same code base and thus we cannot sit with them and be able to review the code on the spot, I'd pose a question if the code has been modularized in the right way. Perhaps, we don't have feature teams where features are aligned with business capabilities and instead of that have component teams where each team is responsible for a single technical "layer" of application.

[@andrealaforgia]

It's not just being unbiased/objective. It's more like you need someone who was not involved in the original development to look at your changes from a different perspective. I think a team need a formal way to perform code reviews and PRs offer that. If a colleague is sitting next to me and reviewing my code, what am I supposed to do? Look at him/her? :) PRs are also a way to optimize everybody's time. I can do something else while they review my code. In my experience, they don't slow down a team's performance but every situation is different. The problem we've experienced with PRs is their size. PRs have to be short in order to be effective and guarantee a true continuous integration. As for distributed teams, unfortunately it's not always possible to modularize your code so that modules reflect the geographical distribution, but that would be a good thing to aim for.

[@kobac8207]

We'll if she looks nice, why not invite her to do a review of your code while you stare at her :D Now seriously :) Yeah, I understand a need for asynchronicity in the process and yup not having to block your computer while someone is reviewing your code can be a convenient thing to do. The thing that worries me is that the lack of fluency in the work. E.g. I code some feature (while having to be careful that commits/PR is not too big), then I create a pull request, assign someone and then I have to wait for him to review the code, which can, and usually takes some time. Not because the PR is too big, but because (s)he's busy currently. I'd like to have a feedback as soon as possible and I'd like to not have to create a process around it, since all of us are sitting in the same room and collaborating. But ok, I can understand that that is my perception and I'm more on the lightweight approach when it comes to this.

[@ChristianMilesOnLine]

Really interesting talk... Much I agree much, I was actually semi involved as a developer with this project.

[@thecomputingchronicles]

I think at the time I described the Dixons project as a software project death march.

[@statequest]

Lol. Gitflow. Because if there's something worth doing, it's something worth doing complicatedly. Ok. He's got a point. Merges can get messy.

[@964tractorboy]

A very good presentation which deserved a more "responsive" audience.

[@SetMyLife]

We used GitLab's Merge Requests with great success in my last job. It was an entirely closed team with no external cooperation. For me a successfully finished Merge Request came with a significant portion of satisfaction. The burnout issue mentioned seems counter intuitive.

[@redhotbits]

you doing it wrong

[@neoplumes]

Watching this actually makes me feel physically ill. I know that this is the right way to do things AND that I will never be able to influence my company to use small batches 😢. That scar tissue runs too deep.

[@theticofacous]

The developer suggests inserting an abstraction so that you have two branches of code in the same project which can be toggled in one or two places via a flag. Suppose the original team did this. Most of the application would be duplicated. There would be no merge conflicts, but half the team would be working on one branch and the other would be working on the other branch in the code. When it came time to remove the abstraction they would be in the same hell. So the argument that branching by abstraction is easier/better is superficial. The solution seems obvious to me. The team working on the new version, should be aggressively rebasing their work on top of the other teams work. They get all the bug fixes, and handle the merge conflicts as they come, in the end the new version will easily merge.

[@andrealaforgia]

>Most of the application would be duplicated. It's a better duplication, cause you duplicate only the stuff that differs. With branches, you duplicate everything. At least that duplication happens in the same shared mainline, so it's visible to everyone. >When it came time to remove the abstraction they would be in the same hell. Nope. If you have two versions of tax calculation, you can apply a strategy pattern. You can have one tax calculation strategy for when the feature toggle is one and another for when the feature toggle is off. Removing the feature toggle merely means removing one strategy, which leaves every other logical branch unaffected. With some languages/frameworks (e.g. Java + Spring Boot), leveraging dependency injection and proxy objects allows to have a seamless way of injecting conditional behaviour, which works very well. >The team working on the new version, should be aggressively rebasing their work on top of the other teams work. Rebasing frequently, in general, does not help one bit. If two teams branch from master and keep working on their branches for days, rebasing frequently does not bring any benefits (as no changes have landed into master yet). They won't be able to see each other's change for days. Rebasing frequently DOES NOT equate to Continuous Integration.

[@nyxzbg]

2024 and trunk based development is still the most controversial topics I discuss with fellow developers.

[@danilopianini]

Thank you for your talk. Pity there was no time for questions. You end up having to change your code do adequate it in order to support the partial features, and all that just because we don't want to use branches. You need to abuse of tags or equivalent systems to de-facto emulate branches, and this also requires some times using external tools. It frankly seems to me that, when the point is reached that you need to have a tagging tool beside your VCS, it's time to switch to branches. A more scalable approach in my opinion is to keep using branches, but force those working on features to continuously pull from trunk/develop. Integration is done feature-side, and it is responsibility of the feature-developing team to keep up-to-date with trunk/develop. I'm using the technique in several projects, where there is both a "core" team, which de facto directly commits on develop, and several "feature teams", which work on their own changes. I find this technique pretty nice on CVS/SVN environments, and/or with a single team with people working together; but looks not so great in git/Mercurial-enabled environments, and moreover it does not scale with teams that get scattered around the world (as the speaker correctly points out).

[@curiosull]

Changing architecture and keeping a branch for months is not feature, it's a new project, you were doing it wrong.

[@verytiredname76]

Sure anything long lived is an issue when it comes to software development. Keep batch sizes small; keep merges frequent is the answer in any situation. While gitflow looks complicated; most teams could do with a simplified version of gitflow philosophy. Keeping a release and develop branch to do most of the work should suffice for most teams.

[@bepkororoti8019]

Committing is War 😂

[@martine.bruggemann98]

Great stuff, but wow he talks fast... I was like reducing playback speed to .75 to be able to follow ^^

[@BurstRay]

Guys... please... for once.... stop spreading false information... SVN branches are NOT a "full copy". They are not even symlinks. SVN actually uses hardlinks to create a branch, making it EXTREMELY efficient. (I created a branch the other day on a ~3GB codebase and it was created instantly). Git is better for different reasons. Get them right. The branch operation is not one of them.

[@kdakan]

If a new feature is critical or hard to test or is part of a larger story that cannot be tested alone, feature branch would be helpful. Trunk based development is helpful until you you live, then it's too risky imho. And not every organization has good automated test coverage and has even good testers. This speech is highly opinionated and not that much of help to the general audience.

[@dpring777]

Anti-pattern.