9 ms·
The suggestion that feature branches hinder CD is just untrue, at least in my experience. To me, this seems like a silly restriction to put on such a critical t
by hashkb 10y ago
The suggestion that feature branches hinder CD is just untrue, at least in my experience. To me, this seems like a silly restriction to put on such a critical tool (the scm) which is designed to support unlimited flexibility.
- nhumrich 10y agoYou must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery when I am ready"
- geocar 10y agoCD is not impossible with feature branches. My live system looks up the branch name in the URL or in a (signed) cookie and checks out the appropriate branch then and there. This is possible because my development system is integrated into my live system.
- nhumrich 10y agoSo your delivering all commits on all branches to prod? That sounds hairy
- geocar 10y agoHow many commits do you do in a day? The hardest part is figuring out how to do this without a map.
- nhumrich 10y agoOn a big team, potentially 100's. But if your delivering all commits regardless of branches, why even have branches?
- geocar 10y agoBecause they're still useful? A branch is a useful tool for the developers who know their development process includes pushing to and pulling from branch "xyz" while they develop whatever feature they're tasked to develop. That they don't solve every problem doesn't bother me.
- perlgeek 10y agoIf push to two feature branches, A and B, which one lands in production? both? if so, how? or the last one you pushed? Or the one that finished its build later?
- geocar 10y agoMy specific implementation uses the git commit id. Only the tool for signing cookies actually knows about branches.
- joneholland 10y agoWe deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.
- hashkb 10y agoYes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.
- nhumrich 10y agoThe gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.
- hashkb 10y agoRebase early and often and this isn't an issue. Some see this as a chore, but I view it as taking advantage of the tool's power. You resolve the same set of conflicts as you would merging, but (as you say) earlier. Edit: I don't think anyone was trying to imply a single allowed feature branch at a time; we can probably all easily agree that's basically no different than working on master.
- nhumrich 10y agoYes, rebase early and often works great. But if your branch includes a major refactor, your going to find yourself editing others code to get your rebase to work. That just increases your own scope. But yes, rebase often is often a very viable strategy. In practice though, I find very few that actually do it because it becomes painful when your branch lives too long simply because business isn't ready to ship something
- notarealdoctor 10y ago
- hashkb 10y agoAnyway the article mentions Continuous Delivery, not Continuous Deployment. Neither means what you say, according to a Puppet Labs blog post, but the latter sometimes does to some people. But that's not what the article says, and so it's not what I'm countering in my comment.
- jessaustin 10y agoSo write the tests first; isn't that what we're supposed to do anyway? That way the branch doesn't move to prod on commit, because it isn't passing the tests yet. BTW "commit" is also a "manual step".
- nhumrich 10y agoI'm kind of lost by your comment. > Write tests first What does this have to do with TBD vs branch based? Should be that way either way. In fact TBD breaks down if you don't write your tests. > A branch doesn't move to prod on a commit Are you saying your shipping branches to prod regardless as to if it's on trunk or not? Or perhaps your whole comment is just saying how TBD is supposed to work and your agreeing with me?
- jessaustin 10y agoAh, never mind, I was confused.
- hamandcheese 10y agoHow does code review fit in to such a workflow? That's also a manual step, but one I and many others consider good and necessary.
- nhumrich 10y agoAccording to the article, and my personal experience, you don't commit directly to trunk. Trunk based means that you don't "collaborate" on a branch. So you write your code based off of trunk, once it's ready you commit in a branch, simply for purpose of code review. It gets reviewed, and probably runs an automated build. Once both pass, you merge and it goes through your deployment pipeline. Yes the merge/code review are manual, but your not merging to say, "I'm ready for this feature to be on prod now" your simply saying it looks good. The biggest difference is that if developer B wants to use your new method, he has to wait for it to be on trunk rather than branching off of your branch, etc.
- notarealdoctor 10y ago> 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.
- dpark 10y agoBecause 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.
- alkonaut 10y agoSo the person that has an opportunity to misunderstand the specification (the developer) is given the task of writing the tests to OK them, even though the test is based on the same misunderstanding? 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.
- dpark 10y agoWhere do you work that software engineers write code and then hand off their code to non-software-engineer "experts" for testing? That sounds like a really broken process.
- alkonaut 10y agoI implement a program used by structural engineers. So basically the user is a structural engineer and I'm a software engineer. They typically find nuances of program behavior that I never thought of because I'm not an expert in structural engineering. I think the same would be true if I made a trading platform, an x-ray machine UI or whatever. When the expert uses it to do what they are experts in, they will invariably find issues (bugs, omissions, simple improvements) that weren't obvious to begin with. One can argue that if the spec was 100% perfect then I can always test it myself and hopefully even do so with automated tests - but I have never seen a spec like that (perhaps more importantly - if you have in house "end user like testers" for expert software then it's likely more economical to have expert testing and iterate than spend the time on more detailed upfront specs)
- clusmore 10y agoWhy do we have this obsession with religiously following methodologies rather than focusing on the goals they attempt to achieve? >CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. In my experience one of two things happen with this approach. Either the functionality is hidden behind flags and intentionally doesn't impact prod, in which case there's no point in it being there. Or you only commit when the feature is complete, which is effectively the same "delivery when I am ready" as with merges. The goal of CD is not to push every commit to prod -- this is merely the process. If the goal achieved by the process of pushing every commit to prod can be achieved via a different process, we shouldn't be so quick to criticise the other process. We should instead discuss the tradeoffs between the two, because in reality there is no best option, only tradeoffs.
- UK-AL 10y agoWhat do you think unpushed/uncommited changes on your local machine. They are basically feature branches.