Comments by "" (@redtela) on "Why CI is BETTER Than Feature Branching" video.

I'm confused, why would any developer working on a team, be working in the dark, not being aware of other peoples changes? Sure, you can't have a large team, and all members know what each other are doing, and how they're doing it. But nothing stops people talking. You say yourself that team development is a social activity, so it feels a little bit of a straw man argument to suggest that developers working on feature branches are more in the dark than those following "continuous integration." A large part of my job is planning the workload of the team, such that we avoid collisions (even when working on the same codebase). I liken that to a choreographer at a ballet stopping the dancers bumping into each other, and by doing this, each dancer don't need to know any real detail about what another is doing, or where. Feature branches should be short lived, ideally less than a day, so at worst, if I've got things wrong, we lose a days work - which is exactly the same case as you make. With respect, I think you're a little too hung up on the word "continuous" in "continuous integration." Dark launching, branch by abstraction, and feature toggles are still possible with Feature Branching, just as integration (and appropriate testing is)... I wholly accept that Feature Branching isn't as "continuous" as your method of working, but I also don't see a slightly slower version of continuous as being a problem. In your words, feel free to explain to me why I'm wrong.
5
@tylerkropp4380 the situation you describe, the 3 developers that couldn't integrate until others had... isn't that just the choreography? Remove that from the equation, and both Trunk Development and Feature Branching fall down. I could make the counter argument that "if commits are every 5-mins, then conflicts are every 5-mins" Re the "ideal case" - I agree, in an ideal situation, we're effectively debating semantics. Sadly, the real world isn't ideal, so all I'm arguing, is that each team is free to work the way that they are most productive. FWIW, I like your reasoned approach to the whole debate. I actively look for people that disagree respectfully. I'm on Dev.to as 190245, and the same on Twitter. From there, it's a short hop to LinkedIn - if you want to have similar conversations in the future.
2
@CallousCoder "Good stuff takes time." Bingo. I think that succinctly answers the issue I have in my head with the over emphasis on "continuous."
2
@rosstempo3765 That is probably the most sweeping, most evocative argument I have ever seen, while promoting a false dichotomy. How many libraries are filled with books espousing to have THE ANSWER to great productivity? Yet all the answers are different. I learnt long ago not to jump on anyone's bandwagon, especially if they're selling a book on the topic. I'm yet to see (or read) anything that convinces me that Branch (Trunk) Development is THE ANSWER to THE BEST productivity possible, by all teams at all times. You're welcome to educate me though, I'm listening...
1
@rosstempo3765 I'm still confused (and I was also confused about where your previous reply went :D please don't worry about how wording might come across, if people can't speak freely, progress cannot be made). Trunk Development and Feature Branching, must both, at some time merge. I don't see how Trunk Development will make things easier, or more productive, than our current approach. We use small feature branches, but I push my feature branch, and it is automatically Dark Deployed to Production. My team looks after close to 150 different components, all different code bases in different repositories, thousands of lines of code. The ones that take the most time are based in Angular (compile time), but they can be in Production within 30mins of pushing a branch - automatically. I think our fastest record was simply due to the build environment being "quiet" - 3 seconds after pushing the commit (branch). We have a strategy, it works for us, I'm watching these videos from the angle of "if Trunk Development is ACTUALLY better, measurably, then maybe it's worth us switching" - I'm just yet to see something that isn't full of logical fallacies.
1
@UCtepZ7g3Am-OALBxTB3RP0A an additional thought here. If merging code is a problem, doesn't Trunk Development style CI posit that all developers should merge all the time, lest they be "in the dark?" That sounds to me like the "merge problem" would happen more frequently? For the record, I don't believe merging to be problematic, regardless of how anyone might be using VCS of any flavour.
1
@rosstempo3765 if I remove those feature branches, then I've got to change a whole lot of delivery pipeline... that sounds like a lot of work. If I keep them, then I `git cob <name>` ... do some work, `git acp <message>` and it's Dark Deployed. If we move to Trunk Development, to potentially gain some productivity in development, it sounds to me like we inherit a bunch of problems and make other teams in the business have to change the way they work. I wouldn't call what we do CI/CD, in the way these video's describe it - we stop at Dark Deploy. That is the end of the developer journey for us. That's where the test/risk mitigation cycle starts (for which, I'm also responsible, btw). We're probably about as fast as the business is willing to accept the risks for - which is the exact trade-off that each individual company needs to explore. I also wouldn't want to tell anyone on my team "Hey, you've got to be continuously delivering value" - because that sounds terrible to hear.
1
@tylerkropp4380 I don't think we can safely argue that one commit automatically is a small change. There is no limit in git for the number of files per commit, as just one example. It should be, yes, but we have no guarantees. I have known XP proponents that claim one line is one commit. That's a small change, but likely a breaking one. Equally, TDD to fix a bug, the test case could be a commit, and the fix another. The test should rightly fail, so I could be doing CI, but with a failed test, it shouldn't go to Production, so might not count as CD. I think I prefer Martin Fowler's take on all this. CI/CD means that you CAN, at request of the business, deploy a new version of any component within minutes. I think these videos are trying to over emphasise the "continuous" part. With Feature Branching, the way we do it, mainline is always merged into the feature, then tested, before the feature is merged into mainline. But all of that is done automatically in the delivery pipeline (another thing Fowler advocates for, automating all the things).
1
@tylerkropp4380 Again, I'm confused. Why would no-one be aware of different branches? Is `git fetch` really that hard? If you're in a Scrum team, Standups exist every day, so everyone should have some awareness of what others are doing. I personally see merge commits as a good thing - that is the point at which code was integrated. I'm also confused about why there would be duplicated effort - that sounds like a failure in planning. Lets assume as you say, we want to update a dependency to a new version, and multiple developers need to do that... lets be more specific and say that we're in Maven. All developers that need to update are following Trunk Development... and all, on the same day, modify pom.xml. First developer to push to origin wins, everyone else gets a merge conflict. So I posit that in this case, Trunk Development is no better than Feature Branching. Both styles need some type of choreography. That choreography should dictate one specific person to update the pom.xml, and then make sure everyone else is aware that it's done. For what it's worth, in the last 3 years, across 150 different components and different sized teams (from 2 people through to 40 people), following Feature Branching the way we do, I can count the merge conflicts on one hand. All of them have had maybe 2mins of brain space to work out the appropriate action, based on the history of the repository. Does this scale to development teams of multiple hundred people working on the same code base? Probably not. But that seems more like an architecture problem, and a monolith that should be broken into pieces. Continuous Delivery, being the name of the channel that produced the video we're talking about... it seems to me that the argument is being made that "Trunk Dev is better than Feature Branching in order to achieve CI"... if you're aiming for CI but not CD, what's the point of CI? If we don't always need to be in a releasable state, why do we care about "developers in the dark?" (and they are to some degree, in both approaches)
1
@seanknox7321 have I ever worked on a poorly managed (to paraphrase you) team? Sure. They have a tendency to be managed by someone that isn't technical, and believes that people are only productive while sitting in a chair in the office (in view). I hope you don't take this personally, but one of the best pieces of advice I was ever given was "if you don't like a situation, do something about it. Leaving counts as doing something." A close second is the old adage of "find something you enjoy doing, and find someone to pay you for doing it."
1
Well, at least you & I are on the same page. I'm actually verging on thinking that the implications of "continuous" are bordering on toxic. Managed sensibly, feature branching can be very quick. Whether it's better or worse code, is a test coverage debate, not a VCS strategy debate.
1
@michaelrstover - have a look around, feel free to read my other comments in several threads about this video. You might realise that I'm all for making things more efficient, regardless of the tactics employed to get the job done. It seems the part that you're missing, is that I dislike the over-emphasis of continuous. Sure, be quick, work in small chunks, follow best practices etc... but there's also no harm in going to get a coffee, or chatting about your weekend with the person sitting next to you, etc. I'm yet to meet a developer that MUST deliver value within X mins or someone will die. No-one writes good code under continuous pressure to deliver.
1