Comments by "Michael Stover" (@michaelrstover) on "Git Flow Is A Bad Idea" video.

@davidboeger6766 Most of the time people think it's necessary to isolate their work in a long-term branch, it's not. People need to learn the techniques in programming that make it possible to work that way, but I don't see much interest in most developers to change how they think about coding in this way. Encapsulation is a primary design principle that can help work this way. When things are adequately encapsulated, making incremental changes gets a lot easier.
4
@andrealaforgia5066 I want to work with you!
2
"The CI builds on their feature branches represent effectively a dry run continuous integration while ensuring that work in progress code does not pollute the ecosystem." -> this is not true because if you only pull in develop, you aren't pulling in all the other developers current feature branch work. You are delaying the point when you find out whether your changes work with the other 10 developers changes. Delay in feedback slows us down.
1
I think one big question Dave would have for you is, what are you sending to the test environment for testing that takes a long time? If you're sending all the feature branches, then you are not testing "the truth" - ie the version that gets deployed, so why do that? ESPECIALLY if it takes hours to run. I think, but am not sure, that the CI solution is different kinds of tests that run at different points in the workflow. Unit tests run on the devs local machine before pushing to trunk. This is the bulk of tests that catch regressions. After integration to master, each change kicks off any further integration tests that need to happen - which would include pushing the build to your test environment, automatically, and running a test suite there if necessary. Delivery doesn't happen if those tests fail. If they fail, everyone finds out right then and then work to fix it ASAP.
1
@Resurr3ction If there are 8 PRs, each one runs a test of it + main. They all pass. Then they all merge. Then master is broken! You didn't test master + all the PRs merged all together. Of course, you could. You could run all your PRs serially, testing only one at a time, merging it, then testing the next, and that might work or it might be a bottleneck. When I push my PR up, I might not find out it doesn't work with someone else's changes until many hours, or even days go by. What didn't work might have been something simple and stupid that the unit tests covered, but I couldn't discover that except by waiting hours and hours. Meanwhile, I had to move on to other things. I can't really speak for Dave, but if I try, I'm guessing the attitude is, the tests we run locally have to be a very good, thorough, and fast test suite. We run them before we push to trunk. Then, after every such push to trunk, the more expensive suite is run. If that fails, we stop and go fix it, and the reality is this is not such a problem because we found out about it very quickly, and since we only ever make small incremental changes, fixing is not such a problem. The fast feedback is worth more than the occasional small breakage that 99% time are easy to fix.
1
Oh, well, let me know when you get some more experience.
1
@aurelienrb how does a branch help run a test?
1
@aurelienrb If one is doing trunk-based dev, one would run the tests locally before pushing. Mr Farley uses Pair programming for reviewing, so the code is already reviewed.
1
@aurelienrb We do pair programming remotely. I actually like it better than in person pairing. And I do gradual, incremental changes without the sandbox of a branch. There are other ways to sandbox.
1
I suppose the "huge surface for security vulnerabilities" maybe refers to the idea that you're goal is to make a new REST endpoint or something, and your first step was to activate the end point and then get busy over the next few weeks making it work.... Well, maybe don't do that. Make an encapsulated module/package/whatever with a testsuite that does the work the business logic. Connecting it up to an active endpoint might be the last step you do. Also, feature flags can turn such things on/off. So, it's in the code, but it's "released" until ready.
1